Μια σύγχρονη διαχείριση διεργασιών για την επιφάνεια εργασίας

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

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

Το πρόβλημα

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

Υπήρχε μια εποχή όπου ένας αριθμός PID == μία “εφαρμογή”. Για παράδειγμα η διεργασία kwrite αντιπροσωπεύει την εφαρμογή Kwrite, η διεργασία του firefox αντιπροσωπεύει τον Firefox, απλά πράγματα. Αλλά αυτό έχει αλλάξει. Σαν ένα ακραίο παράδειγμα: Το Discord σε ένα flatpak είναι 13 διαφορετικές διαδικασίες!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Η λύση

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

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

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

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

Παράδειγμα

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

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

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

Φετούλες από κέικ (Slices)

Ένα άλλο βασικό μέρος της χρήσης των cgroups είναι η έννοια των φετών (slices). Τα cgroups σχηματίζουν μια ιεραρχική δομή (σαν τα αρχεία στο δίσκο με φακέλους και υποφακέλους). Οι φέτες είναι τα μέρη που θα ζητήσουμε να γίνει διαχείριση της χρήσης πόρων του υπολογιστή (μνήμη, cpu, πρόσβαση στο δίκτυο και τον δίσκο). Κάνοουμε την διαχείριση των πόρων όχι καθολικά, αλλά προσαρμόζουμε τους πόρους σε κάθε slice μας, αυτό στη συνέχεια παρέχει τις χρησιμές πληροφορίες και μεταδεδομένα στον task manager.

image

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

Περισσότερες πληροφορίες για τις φέτες θα βρείτε εδώ: Παγκόσμια κυριαρχία με τα cgroups

Προεπιλεγμένες φέτες (Του σπιτιού, του ξένου, του εργάτη)

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

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

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

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

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

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

Είναι οι φέτες ευγενικές;

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

Επίσης, δεν έρχεται σε αντίθεση με τις τιμές nice που ορίζονται ρητά από την κάθε εφαρμογή. Εάν ορίσουμε το kdevelop να έχει μεγαλύτερο βάρος CPU, το clang δεν θα κλέψει ξαφνικά όλη την CPU κατά την μεταγλώττιση.

Το κερασάκι στο κέικ

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

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

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

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

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

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

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

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

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

… ακολουθούν τεχνικές οδηγίες για χρήστες και προγραμματιστές η δουλεία που έχει γίνει τα προβλήματα που προέκυψαν και κατευθυντήριες γραμμές. Ανατρέξτε στο αρχικό άρθρο …

Τι γίνεται αν έχω ένα λειτουργικό με αυτές τις δυνατότητες;

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


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

Το αρχικό κείμενο υπάρχει εδώ:

Διαβάστε επίσης:

https://wiki.gnome.org/ThreePointThirteen/Features/SystemdUserSession
https://lists.debian.org/debian-user/2014/10/msg01409.html

3 «Μου αρέσει»

Απ’ ότι βλέπω τα cgroups είναι μια δυνατότητα που παρέχει ο Linux Kernel. Σε περίπτωση που κάποιο σύστημα δεν τρέχει systemd, υπάρχουν εργαλεία τα οποία θα μπορούσαν να τα διαχειριστούν;

Η διαχείριση των χρηστών, της συνεδρίας ενός χρήστη (login session) αλλά και των θέσεων εργασίας (seats) το κάναμε με την βιβλιοθήκη ConsoleKit που παρείχε ένα dbus api πάνω στο pam.

Μια θέση εργασίας είναι μια κάρτα οθόνης+οθόνη μαζί με συσκευές εισόδου. Όχι ένα τυπικό παράδειγμα χρήσης. Αλλά μπορεί να γίνει και με τέτοια κόλπα Plugable. Δες [1], [2], [3].

To ConsoleKit δεν υποστήριζε cgroups και ο διάδοχος του ConsoleKit2 μόνο την πρώτη έκδοση των cgroups. Και τα δυο είχαν σταματήσει να αναπτύσσονται και τα ψευτοσυντηρούσασταν οι ίδιοι που έφτιαξαν το systemd αλλά και το udev. Κάποια στιγμή μάζεψαν τα project τους σε ένα κοινό αποθετήριο.

Το consolekit έγινε logind, απέκτησε υποστήριξη για cgroups και δεν είναι συμβατό με το παρελθόν.

Αυτή την στιγμή δεν υπάρχει τίποτε άλλο από όσο γνωρίζω. Κανένα εναλλακτικό init δεν έχει ασχοληθεί με καν το πρόβλημα. Προσπαθούν ακόμα από όσο ξέρω ακόμα να τα χρησιμοποιήσουν για τα services. Αυτά με βάση τουλάχιστον όσα γνωρίζω. Αν υπάρχει κάποια εναλλακτική υλοποίηση ή αν κάποιο άλλο init έχει κάτι να βάλει στο τραπέζι, διορθώστε με.

Εκεί που έχει γίνει ελάχιστη δουλεία είναι στην χρήση systemd user units για την διαχείριση των depedencies των υπηρεσιών του desktop environment και τις διαχείρισης τους. Μια γραφική συνεδρία μοιάζει πολύ με μια συνεδρία στον υπολογιστή.

Το μόνο άλλο εναλλακτικό είναι το elogind που ρητά λέει :

elogind is the systemd project’s logind , extracted to a standalone package. It’s designed for users who prefer a non-systemd init system, but still want to use popular software such as KDE/Wayland or GNOME that otherwise hard-depends on systemd.

Δηλαδή είναι κώδικας του systemd ακριβώς ο ίδιος κώδικας, κατάλληλος για διανομές που λένε πως δεν έχουν, ενώ στην πραγματικότητα έχουν. Κάτι σαν το μεγάλο μας τσίρκο :stuck_out_tongue:. Και το μόνο που αποδείχθηκε είναι πως το systemd δεν είναι στην πραγματικότητα τόσο μονολιθικό όσο λένε.

Η χρήση του elogind απαιτεί την υποστήριξη cgroups (άρα ξεχνάμε το άλλα Unixes) και περιμένει να βρει την οργάνωση του systemd.

Η χρήση του systemd σήμερα είναι μονόδρομος. Τίποτα δεν εμποδίζει βέβαια κάποιον να φτιάξει καινούργιο κώδικα και να επαναχρησιμοποιήσει τα ίδια dbus interfaces.

Τίποτα δεν μπορεί να κάνει κανένα πρόγραμμα αν δεν μπορεί να το κάνει ο πυρήνας του Linux. Το θέμα είναι να χρησιμοποιείς βιβλιοθήκες ώστε να επαναχρησιμοποιείς κώδικα και να μην ξαναανακαλύπτεις τον τροχό. Καθώς και για να προστατευτείς από αλλαγές και να παίρνεις τις τελευταίες δυνατότητες. Το api του kernel για τα cgoups έχει αλλάξει και έχουμε πλέον τα cgroups2. Αν το είχες κάνει με το χέρι θα έπρεπε να ξανακάνεις την δουλεία από την αρχή :stuck_out_tongue: Και κάτι ακόμα καλύτερο από μια βιβλιοθήκη είναι ένα dbus api.

Στα καλά νέα της εβδομάδας, το KDE χρησιμοποιεί το systemd για την διαχείριση της συνεδρίας του χρήστη

3 «Μου αρέσει»

Μια νέα εφαρμογή για παρακολούθηση πόρων στο KDE

1 «Μου αρέσει»