Διαχείριση διεργασιών στο Desktop και ο ρόλος των cgroups

Οι εποχές που μια εφαρμογή στο desktop δημιουργούσε και μια αντίστοιχη διεργασία στο παρασκήνιο, πέρασε ανεπιστρεπτί. Τι γίνεται όμως με τις εφαρμογές προβολής αυτών των διεργασιών; Εκσυγχρονίστηκαν; Ποιος ο ρόλος των cgroups στο σύγχρονο Desktop Linux;

Ο μοναδικός ρόλος ενός περιβάλλοντος επιφάνειας εργασίας είναι η σύνδεση των χρηστών στις εφαρμογές τους. Αυτό περιλαμβάνει τα πάντα, την εκκίνηση εφαρμογών και την εμφάνιση τους στην οθόνη, αλλά και τη διαχείρισή τους και τη διασφάλιση της σωστής λειτουργίας τους.

Όλοι γνωρίζουν την έννοια του “Task manager” (όπως το ksysguard του KDE). Αλλά με την πάροδο του χρόνου τα προγράμματα αυτά δεν συμβαδίζουν ούτε με τον τρόπο με τον οποίο αναπτύσσονται οι εφαρμογές, ούτε με τις τελευταίες εξελίξεις από το Linux.

Το πρόβλημα

1. Διαχείριση των εκτελούμενων διεργασιών

Υπήρχε μια εποχή όπου ένας αριθμός PID ισούτο με μία “εφαρμογή”. Για παράδειγμα η διεργασία kwrite αντιπροσωπεύει την εφαρμογή Kwrite, η διεργασία του firefox αντιπροσωπεύει τον Firefox, απλά πράγματα.

Αλλά αυτό πλέον έχει αλλάξει. Σαν ένα ακραίο παράδειγμα: Το Discord σε ένα flatpak είναι 13 διαφορετικές διεργασίες!

Αυτό κάνει την λίστα των διεργασιών που δείχνει ο “Task manager” ουσιαστικά άχρηστη. Όλα τα ονόματα είναι τυχαίες ασυναρτησίες. Το να προσπαθήσεις να «σκοτώσεις» μια εφαρμογή ή να ορίσεις κάποια επίπεδα χρήσης των πόρων του υπολογιστή είναι σαν ένα τυχερό παιγνίδι. Μάντεψε και κέρδισε. Η οργάνωση των διεργασιών σε δεντρική δομή βοηθάει κάπως, αλλά όχι αρκετά.

Ο τρέχων τρόπος για μένα είναι άχρηστος, και πιθανότατα είναι επίσης άχρηστος και για οποιονδήποτε χρήστη που αισθάνεται πως χάνει τον έλεγχο του υπολογιστή.

Είναι φανερό πως χρειαζόμαστε κάποια μεταδεδομένα σε αυτήν την λίστα.

2. Μια δίκαιη κατανομή πόρων

Όπως αναφέρθηκε παραπάνω, το discord σε flatpak είναι 13 διαφορετικές διεργασίες. To krita είναι μια διεργασία. Κάποιο προγραμμα θα επιβαρύνει τον επεξεργαστή επειδή είναι μια πολύ εξελιγμένη εφαρμογή που κάνει πολύ περίπλοκες γραφικές λειτουργίες. Κάποιο άλλο θα ξεζουμίσει την CPU επειδή είναι γραμμένο σε electron (βλέπε discord).

Ο πυρήνας του υπολογιστή όμως το μόνο που θα δει είναι 14 ξεχωριστές διεργασίες. Δεν γνωρίζει ότι ομαδοποιούνται ως δύο διαφορετικά πράγματα. Δεν θα μπορέσει να βρει κάποια δίκαιη μοιρασιά των πόρων.

Χρειαζόμαστε πάλι κάποια μεταδεδομένα.

Προφανώς οι περισσότερες διεργασίες είναι αδρανείς και έχω αγνοήσει τα threads για να κρατήσω τα πράγματα σε ένα κατανοητό επίπεδο

3. Είναι δύσκολο να αντιστοιχίσεις πράγματα

Σήμερα, τα μόνα μεταδεδομένα μιας “εφαρμογής” βρίσκονται στο παράθυρο της. Για να δείξουμε ένα φιλικό προς το χρήστη όνομα και εικονίδιο στο ksysguard (ή οποιαδήποτε άλλη οθόνη συστήματος) πρέπει να πάρουμε μια λίστα με όλες τις διεργασίες, να πάρουμε μια λίστα με όλα τα παράθυρα και στην συνέχεια να κάνουμε ένα mashup. Ο μόνος τρόπος είναι με αυθαίρετες ευρετικές για τον χειρισμό γονικών PID, κάτι που όμως είναι ασταθές και ακατάστατο.

Ας δούμε κάποια υπαρκτά παραδείγματα:

Στον διαχειριστή εργασιών του plasma δείχνουμε μια ένδειξη ήχου δίπλα στο σχετικό παράθυρο. Αυτό το καταφέρνουμε αντιστοιχίζοντας τα PID της διεργασίας που παίζει έναν ήχο με το PID ενός παραθύρου. Εύκολο για την απλή περίπτωση … ωστόσο, μόλις προχωρήσουμε σε πολλαπλές διεργασίες, πρέπει να παρακολουθούμε το γονικό PID και κάθε “επιδιόρθωση” κάποιου bug θα φέρει με την σειρά της κάποιο άλλο bug.

Με το PID namespaces οι εφαρμογές δεν μπορούν πλέον να αναφέρουν σωστά τα PID των clients. Χάνουμε πληροφορίες σχετικά με την “εφαρμογή” που ξεκινήσαμε. Έχουμε αναφορές σφαλμάτων όπου οι άνθρωποι έχουν δύο διαφορετικές καταχωρήσεις taskmanager για το “Firefox” και το “Firefox (nightly)”, ωστόσο, όταν η διεργασία δημιουργηθεί, οι πληροφορίες αυτές χάνονται αφού η εφαρμογή αναφέρεται ως ένα σταθερό όνομα και η γραμμή εργασιών χάνει τον μπούσουλα.

Χρειαζόμαστε πάλι κάποια μεταδεδομένα.

Η λύση στο πρόβλημα

Τα παραπάνω είναι ένα λυμένο πρόβλημα!

Ένα σύγχρονος sysadmin δεν ασχολείται πλέον με διεργασίες, αλλά με cgroups. Ο διαχειριστής cgroup (που συνήθως θα είναι είναι ο systemd) τρέχει κάθε υπηρεσία συστήματος σαν ένα cgroup. Χρησιμοποιεί τα cgroups για να ξέρει τι τρέχει, και ο πυρήνας μπορεί να δει εύκολα ποιες διεργασίες ανήκουν σε μια υπηρεσία συστήματος.

Ναι αλλά τι στο καλό είναι τα cgroups;

Τι είναι τα cgroups

Τα cgroups είναι ένας διαφορετικός τρόπος οργάνωσης των διεργασιών σε μια δεντρική δομή.

Η παραδοσιακή δομή υπάρχει, αλλά παράλληλα έχουμε και μια δεύτερη δομή. Δεν θα τα βρούμε σε άλλα λειτουργικά συστήματα τύπου UNIX αλλά μόνο στο Linux. Την πρώτη φορά δεν τα φτιάξαμε τόσο καλά, οπότε έχουμε αυτή την εποχή μια μετάβαση στην δεύτερη έκδοση τους. Μοιάζουν με τον φράκτη, συγνώμη την αυλή ήθελα να πω, ενός νηπιαγωγείου. Από την στιγμή που ο υπεύθυνος (που τον λέμε arbitrator βάλει μέσα στην αυλή μια διεργασία, δεν θα μπορέσει πότε να ξεφύγει. Στην δεύτερη έκδοση τους μόνο μια διεργασία μπορεί να το κάνει αυτό.

Τα croups είναι μια από τις βασικές τεχνολογίες πάνω στην οποία πατάνε πολλές τεχνολογίες, από το docker μέχρι και το flatpack. Η αρχική ιδέα ήταν να χρησιμοποιηθούν για να περιορίσεις τους πόρους που μπορεί να χρησιμοποιήσει μια διεργασία. Και όπου πόρους λέμε το δίκτυο, τον επεξεργαστή, την επικοινωνία με τον δίσκο, την μνήμη… Για να περιορίσεις τους πόρους σε μια διεργασία μπορείς να το κάνεις κάτι τέτοιο με εντολές όπως nice, ionice, ulimit κλπ αλλά είδαμε πόσο εύκολα μπορούν αυτά να τα παρακάμπτουν. Ε λοιπόν ποτέ ξανά!

Το systemd σκέφτηκε να τις χρησιμοποιήσει και με ένα νέο τρόπο. Όσο και αν ακούγετε απίστευτο πριν από αυτό ήταν δύσκολο και μπελάς να βρεις αν μια υπηρεσία συστήματος τρέχει, ή να την τερματίσεις σωστά. Μια υπηρεσία όπως το apache μπορεί να καλέσει κάποιο shell script που να κάνει τρελά πράγματα ακόμα και double forking. Να τις βρεις και να τις σκοτώσεις τερματίσεις δεν είναι καθόλου εύκολο. Να τις περιορίσεις και να μην ας πούμε κάνουν bitcoin minning και κλέψουν όλη την CPU εξίσου δύσκολο. Αλλά αν τις έχεις περιορισμένες σε μια αυλή είναι εύκολο, όπως επίσης εύκολο είναι να δεις αν υπάρχει κάποιο πρόβλημα.

Τα cgroups στην πράξη

Τους φακέλους των cgroups θα τους βρούμε σαν “κανονικούς φακέλους” στο ψευτοφάκελο /sys/fs/cgroup/ με την δομή να είναι διαφορετική ανάλογα με το αν χρησιμοποιούμε την πρώτη ή την δεύτερη έκδοση. Αλλά δεν είναι ανάγκη μιας και το systemd παρέχει μερικά ωραία εργαλεία.

Η πρώτη εντολή systemd-cgls μας δείχνει τους «φράκτες» και τα παιδιά που παίζουν μέσα σε κάθε φράκτη.

Στην εικόνα βλέπουμε πως υπάρχει μια σειρά από φράκτες μέσα σε άλλους φράκτες (στην ορολογία του systemd τους λέμε slice). Μέσα σε κάθε slice θα βρούμε service και scopes. Τα δεύτερα είναι για ποιο δυναμικά πράγματα όπως για παράδειγμα μια συνεδρία σε ένα γραφικό περιβάλλον. Γιατί όπως βολεύουν οι φράκτες το systemd έτσι βολεύουν και ένα γραφικό περιβάλλον να κρατήσεις και να περιορίσει την συνεδρία ενός χρήστη. Οπότε είναι πειρασμός να το χρησιμοποιήσει μέσω του λεγόμενου logind, όπως για παράδειγμα κάνει ήδη το Gnome.

Λίγο παρακάτω θα βρούμε και τις διεργασίες που τρέχουν στο γραφικό περιβάλλον μέσα σε ένα scope.

Μια άλλη εικόνα μας δίνει η εντολή systemd-cgtop

όπου βλέπουμε τους πόρους που χρησιμοποιεί κάθε φράκτης.

Ένας άλλος τρόπος είναι να έχουμε το παρακάτω alias

alias psc='ps xawf -eo pid,user,cgroup,args'

Υπάρχουν τρεις μεγάλοι φράκτες.

• Το system.slice για υπηρεσίες συστήματος,
• το user.slice για εμάς
• και το machine.slice για τις εικονικές μηχανές και τα system containers.

Η επιφάνεια εργασίας και τα cgroups

Στην επιφάνεια εργασίας, τα flatpaks τρέχουν τον εαυτό τους μέσα σε ένα cgroup που φτιάχνουν, ώστε να μπορούν να χρησιμοποιούν τις δυνατότητες του πυρήνα για τους “χώρους ονομάτων”.

Πιθανότατα στην διανομή σας χρησιμοποιείτε ήδη τα cgroups. Ως μέρος μιας προσπάθειας μεταξύ των διαφορετικών περιβαλλόντων εργασίας , θέλουμε να φέρουμε τα cgroups στην επιφάνεια εργασίας.

Παράδειγμα εμφάνισης του System Monitor / Task Manager

Πριν και μετά στο system monitor

αλλά αν γίνει χρήση των cgroups

Στην τελική τα ίδια δεδομένα βλέπεις αλλά ποια είναι ποιο εύκολο να καταλάβεις και να τα διαχειριστείς

Slices των cgroups

Ένα άλλο βασικό μέρος της χρήσης των cgroups είναι η έννοια των slices που αναφέραμε πιο πάνω.

Τα cgroups σχηματίζουν μια ιεραρχική δομή (σαν τα αρχεία στο δίσκο με φακέλους και υποφακέλους). Τα slices είναι τα μέρη που θα ζητήσουμε να γίνει διαχείριση της χρήσης πόρων του υπολογιστή (όπου πόρος θυμίζω είναι : μνήμη, cpu, πρόσβαση στο δίκτυο και τον δίσκο κλπ).

Κάνουμε την διαχείριση των πόρων όχι καθολικά, αλλά προσαρμόζουμε τους πόρους σε κάθε slice μας, αυτό στη συνέχεια παρέχει τις χρήσιμες πληροφορίες και μεταδεδομένα στον task manager.

Διαχειριζόμαστε δηλαδή τους πόρους σε κάθε κλαδί του δέντρου και ο πυρήνας θα αναλάβει μαγικά όλα τα άλλα.

Προεπιλεγμένα Slices

Αυτό σημαίνει ότι μπορούμε να δημιουργήσουμε ορισμένες προκαθορισμένα slices. Τα slices θα είναι μέσα στην slice που θα έχει κάθε ξεχωριστός ενεργός χρήστης. Μέσα σε αυτήν μπορούμε να έχουμε

• Slices για τις εφαρμογές
• Slices για το σύστημα (π.χ. kwin / mutter, plasmashell)
• Υπηρεσίες επιπέδου χρήστη (π.χ. baloo, tracker)

Σε κάθε slice μπορούμε να έχουμε προκαθορισμένες προτεραιότητες και χρήση των πόρων καθώς και ρυθμίσεις για τον OOM (Out of Memory Management – Διαχείριση συνθηκών με εξαντλημένη μνήμη RAM.)

Δυναμική κατανομή των πόρων

Τώρα που χρησιμοποιούμε slices και προσαρμόζουμε μόνο το σχετικό βάρος μας στη slice, μπορούμε να δώσουμε την προτεραιότητα στην χρήση των πόρων στην εφαρμογή που έχει το εστιασμένο παράθυρο.

Αυτό έχει αποτέλεσμα μόνο εάν το σύστημά σας λειτουργεί με τσίτα τα γκάζια, αλλά όμως θα δείχνει να μπορεί να προσφέρει μια πιο απαλή απόκριση χωρίς κανένα μειονέκτημα.

Είναι οι slices ευγενικές με τους πόρους;

Με την γνωστή εντολή nice μπορούμε να ζητήσουμε από μια διεργασία να είναι ευγενική με τους πόρους του υπολογιστή. Αλλά η τιμή της nice είναι μια μοναδική τιμή, καθολική για ολόκληρο το σύστημα.

Εξ αιτίας αυτού οι διεργασίες του χρήστη μπορούν μόνο να μειώσουν του επίπεδο nice, αλλά ποτέ δεν έχουν το δικαίωμα να την αυξήσουν. Με τις slices προσαρμόζουμε μόνο το σχετικό βάρος σε σύγκριση μόνο με τις υπηρεσίες εντός τις ίδιας της slice. Κατά συνέπεια, είναι ασφαλές να αποκτήσει ο χρήστης τον πλήρη έλεγχο εντός της slice του. Τυχόν προσαρμογές σε μια εφαρμογή, δεν θα επηρεάσουν τις υπηρεσίες συστήματος ή άλλους χρήστες.

Επίσης, δεν έρχεται σε αντίθεση με τις τιμές nice που ορίζονται ρητά από την κάθε εφαρμογή. Εάν ορίσουμε π.x. το kdenlive να έχει μεγαλύτερο βάρος CPU, το mlt media engine δεν θα κλέψει ξαφνικά όλη την CPU κατά τo rendering.

Η επίλυση είναι απλώς η κορυφή του παγόβουνου

Η διόρθωση των παραπάνω προβλημάτων είναι απλώς η κορυφή του παγόβουνου.

Επιπλέον χαρακτηριστικά CGroup

Το CGroup διαθέτει πολλές νέες δυνατότητες που δεν είναι διαθέσιμες σε επίπεδο ανά διεργασία.
Μπορούμε:

• Να ορίσουμε όρια έτσι ώστε μια CPU να μην μπορεί να χρησιμοποιεί περισσότερο από N%
• Μπορούμε να κλείσουμε ομαλά τις διεργασίες κατά την αποσύνδεση
• Μπορούμε να απενεργοποιήσουμε τη δικτύωση
• Μπορούμε να ορίσουμε όρια μνήμης
• Μπορούμε να αποτρέψουμε τα forkbombs
• Μπορούμε να παρέχουμε συμβουλές στον OOM όχι μόνο με βάρος αλλά και με αναμενόμενα εύρη τιμών που πρέπει να θεωρηθούν ως φυσιολογικά
• Μπορούμε να παγώσουμε ομάδες διεργασιών (κάτι χρήσιμο για για το Plasma mobile)

Όλα αυτά είναι εύκολο να προστεθούν από κάθε χρήστη / διαχειριστή συστήματος. Χρησιμοποιώντας το drop in’s μπορείτε απλά να προσθέσετε ένα αρχείο .service στο ~/.config/systemd/user.control/app-firefox@.service και να διαχειριστείτε οποιοδήποτε από αυτά.

Σημείωση του μεταφραστή:Τα αρχεία dropin είναι ο τρόπος του systemd για να πειράζεις τις ρυθμίσεις. Αντί να πειράζεις το αρχείο αρχείο (με ότι προβλήματα έχει αυτό) απλά φτιάχνεις ένα νέο με τις αλλαγές. Το αρχείο αυτό εύκολα το σβήνεις και επιστρέφεις στην αρχική κατάσταση.

προειδοποίηση: ίσως αξίζει να αναφερθεί – μερικές από αυτές τις λειτουργίες λειτουργούν για εφαρμογές που έχουν δημιουργηθεί ως transient services (παροδικές υπηρεσίες), όχι για την έκδοση lite χρησιμοποιώντας τα scopes όπως είναι τώρα συγχωνευμένα στο KDE / Gnome

Τα βήματα που έχουν γίνει μέχρι στιγμής

Τόσο το Plasma 5.19 όσο το πρόσφατο Gnome ξεκινούν σήμερα τις εφαρμογές μέσα σε αντίστοιχες ομάδες cgroup, αλλά δεν εμφανίζουμε ακόμη τα αποτελέσματα που μπορούμε να πάρουμε από αυτές. Για τους προγραμματιστές KDE η παροχή των μεταδεδομένων είναι εύκολη.

Τι γίνεται αν δεν έχω ένα λειτουργικό με αυτές τις δυνατότητες (π.χ. χρήστες BSD);

Καθώς προσθέτουμε απλά μεταδεδομένα, όλα όσα χρησιμοποιούνται τώρα θα συνεχίσουν να λειτουργούν ακριβώς όπως και πριν. Όλα τα υπάρχοντα εργαλεία λειτουργούν ακριβώς το ίδιο αν έχετε BSD με KDE.

Μέσα στον διαχειριστή εργασιών μας, θα διατηρήσουμε μια προβολή της διαδικασίας (εξακολουθεί να είναι χρήσιμη ανεξάρτητα) και δεν θα βάλουμε κώδικα που να βασίζεται στα υπάρχοντα μεταδεδομένα της ομάδας. Θα διατηρήσουμε τα υπάρχοντα ευρετικά στοιχεία για την αντιστοίχιση παραθύρων με εξωτερικά συμβάντα, τα μεταδεδομένα της ομάδας ομάδων θα ήταν απλώς ένας ισχυρός παράγοντας σε αυτό. Τα πράγματα δεν θα επιδεινωθούν, αλλά δεν θα μπορέσουμε να αξιοποιήσουμε τις νέες δυνατότητες που συζητήθηκαν εδώ.

Σχόλια του μεταφραστή: Tο systemd έγινε μέσω του logind μια εξάρτηση του gnome. Το μόνο πρόβλημα που βλέπω σε αυτό είναι πως δεν έγινε πλήρης χρήση, αν και βήματα σιγά σιγά γίνονται. Οι δυνατότητες που μπορεί να προκύψουν είναι υπέροχες. Το βλέπω να γίνεται το systemd εξάρτηση του kde σύντομα. Αν σε κάποιον δεν αρέσει η εξέλιξη φτιάχνει ανταγωνιστικά εργαλεία ή βιβλιοθήκες, και μετά δίνει διορθώσεις είτε upstream είτε downstream. Εναλλακτικά μπορεί να κάτσει να γίνει ο γκρινιάρης της παρέας και να του λένε όλοι OK boomer.

Systemd | Για την σειρά των άρθρων

Εδώ και λίγες μέρες έβαλα στόχο να δω γιατί το systemd έχει προκαλέσει τόσο θόρυβο και αν είναι τόσο κακό όσο λένε. Σε άρθρα εδώ παρουσιάζω ότι καλό ή κακό βρίσκω χωρίς φανατισμούς και ιδεοληψίες.

Δείτε τα άρθρα για το systemd, καθώς και άλλες γνώμες, άλλων αρθρογράφων ακολουθώντας το tag:

• Systemd Tutorials : https://cerebrux.net/tag/systemd-tutorials/

Παραπομπές:

• Bringing modern process management to the desktop
• Για τα cgroups και το systemd. Μια εικονογραφημένη ιστορία