Τώρα που και οι τελευταίες από τις λεγόμενες “μεγάλες” διανομές αρχίζουν σιγά-σιγά να υιοθετούν το standard, είναι μια καλή ευκαιρία να πούμε κάποια πράγματα γι' αυτόν το νέο που ήρθε στη γειτονιά ξεσηκώνοντας θύελλα αντιδράσεων. Χωρίς εμπάθειες, με όσο το δυνατόν περισσότερη αντικειμενικότητα. Και ίσως καταφέρουμε στην πορεία να αποκαταστήσουμε κάποιες αδικίες.

Ξεκινώντας την αφήγηση, πρέπει πρώτα να εξηγήσουμε τι είναι ένα init σύστημα. Το init λοιπόν (συντομογραφία του initialization) είναι η πρώτη από ένα σύνολο διεργασιών που τρέχουν στο παρασκήνιο κατά την εκκίνηση ενός Unix-based λειτουργικού συστήματος και προετοιμάζουν το έδαφος για την εμφάνιση του περιβάλλοντος εργασίας. Είναι υπεύθυνο για το ξεκίνημα απαραίτητων λειτουργιών, όπως η δικτυακή σύνδεση και ο διαχειριστής γραφικών. Λαμβάνει εντολή απευθείας από τον πυρήνα, εμφανίζεται αμέσως μετά από τον φορτωτή εκκίνησης (boot loader) και ολοκληρώνει το έργο του στην οθόνη login. Για όσους τυχόν δε χρησιμοποιούν το plymouth, το init είναι εκείνο το ωραίο κατεβατό από διεργασίες που βλέπουμε σε μαύρο φόντο όταν ανάβουμε τον υπολογιστή μας. Οι διεργασίες λαμβάνουν μία τιμή process identifier (PID), η οποία προσδιορίζει τη σειρά εκκίνησης. Το init καταλαμβάνει τη θέση PID 1.

Υπάρχουν κάμποσα init συστήματα, θα αναφερθούμε όμως στα πιο βασικά.

SysV
Ιστορικά, η πλειοψηφία των Linux διανομών χρησιμοποιούσε κάποια παραλλαγή του System V ή SysV. Το σύστημα αυτό δημιουργήθηκε το μακρινό 1983 από την εταιρεία AT&T και είχε τέσσερις εκδοχές, με την τελευταία να είναι και η πιο επιτυχημένη. Στα νιάτα του -όχι πολύ μακριά από τη γέννηση του όλου Unix- εκπροσωπούσε το ένα από τα δύο παρακλάδια αυτού, με το άλλο να είναι το BSD. Είχε την ατυχία να συμμετάσχει στην περίοδο που η ιστορία των υπολογιστών έχει καταγράψει ως Unix Wars. Διαθέτοντας όμως ευελιξία και με προσήλωση στα ανοιχτά πρότυπα, κατάφερε να συγκεντρώσει (και εμπορικό) ενδιαφέρον και να εξαπλωθεί, ενώ ο “αντίπαλος” περιορίστηκε (τότε) στον ακαδημαϊκό χώρο. Με την τελευταία εκδοχή (SVR4) να ενσωματώνει μεταξύ άλλων και στοιχεία από το BSD και το SunOS, αποτέλεσε μία από τις εμπνεύσεις για τη δημιουργία του Linux και επιζεί μέχρι τις μέρες μας.

Upstart
Το επόμενο μεγάλο init σύστημα είναι το Upstart. Τέκνο ενός πρώην εργαζομένου της Canonical, μπήκε στις ζωές μας κάπου το 2006, ως εναλλακτικό του SysV. Διατηρώντας προς τα πίσω συμβατότητα, προσέθεσε νέα χαρακτηριστικά που έλειπαν από το γερασμένο προκάτοχό του, όπως η ασύγχρονη (μη γραμμική) εκκίνηση διεργασιών, η ευκολότερη εποπτεία και διαχείριση αυτών αλλά και έναν πιο απλό τρόπο σύνταξης init scripts. Υποστηρίχθηκε από αρκετές Linux διανομές -Ubuntu, Fedora, openSUSE κ.ά.- αλλά και από άλλα λειτουργικά (βλέπε Maemo, WebOS). Το μοναδικό του ίσως σοβαρό μειονέκτημα είναι ότι, παρότι καλύπτεται από άδεια GPL, ως προϊόν της Canonical πρέπει υποχρεωτικά να φέρει και υπογραφή της σχετικής άδειας CLA, η οποία διαφοροποιείται ελαφρώς ως προς τις ελευθερίες που παρέχει. Πλέον, εφόσον ακόμα και η μητρική του διανομή έχει αποφασίσει να μεταβεί στο systemd, θα περάσει εν καιρώ στην ιστορική μνήμη.

Κάποια άλλα, μικρότερης απήχησης, init συστήματα είναι ενδεικτικά τα OpenRC (Gentoo), launchd (OSX) και runit.

Κι εγένετο systemd
Το systemd (εκ του system daemon, γράφεται πάντα με πεζά, ακολουθώντας τη λογική των daemons σε ένα Unix-like λειτουργικό) είναι ένα init σύστημα που δημιουργήθηκε για να καλύψει χρόνιες αδυναμίες τόσο του SysV όσο και του Upstart. Ένα στοιχείο που συνήθως ξεχνάμε στο ΕΛ/ΛΑΚ είναι ότι όλοι έχουν την ευκαιρία να δημιουργήσουν και η ευκαιρία αυτή παρουσιάζεται πιο έντονα όταν παλιότερα projects αδυνατούν να ανταποκριθούν στις απαιτήσεις των καιρών. Πρακτικά, όταν κάτι αποτυγχάνει να βελτιωθεί ή δεν επιδέχεται βελτίωσης, είναι φυσικό να ξεπηδήσει κάτι άλλο στη θέση του. Ως νέο αίμα στην πιάτσα, το systemd αντιμετωπίστηκε εξ αρχής με καχυποψία. Σ' αυτό βέβαια βοήθησαν αρκετά πράγματα· το προαιώνιο φαινόμενο της αντίδρασης στην αλλαγή, η καλλιέργεια άσχημων φημών, η “επιθετική” πολιτική του αλλά και ο χαρακτήρας των δημιουργών του.

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

Εν αρχή ην η περίφημη Unix φιλοσοφία και πιο συγκεκριμένα το κομμάτι εκείνο που ορίζει

κάνε ένα πράγμα και κάνε το καλά

σε συνδυασμό με το

τα πάντα είναι αρχεία

Το πρώτο είναι σαφές και δε χρειάζεται ανάλυση. Το δεύτερο εννοεί χοντρικά ότι κατά βάση το σύστημα θα αποτελείται από ρυθμίσεις στη μορφή αρχείων κειμένου, οι οποίες θα μπορούν να αναγνωστούν, να τροποποιηθούν και συνεπώς να ελεγχθούν εύκολα με οποιονδήποτε επεξεργαστή κειμένου, σε αντίθεση με τα δυαδικά (binary) αρχεία που χρειάζονται ειδική μεταχείριση. Ομολογουμένως, αυτή η λογική προσέφερε αρκετά στο ορθό χτίσιμο των Unix-based συστημάτων και λειτουργούσε καλά για αρκετά χρόνια. Οι καιροί όμως αλλάζουν και μαζί τους αλλάζουν και οι απαιτήσεις. Κι έτσι το systemd διαφοροποιείται από την πεπατημένη, κάτι που αρκετοί το θεωρούν αρνητικό.

Συγκριτικά με την εποχή του '70-'80, οπότε και διαμορφώθηκε αυτή η φιλοσοφία, τα σύγχρονα υπολογιστικά συστήματα συγκεντρώνουν απίστευτη επεξεργαστική ισχύ και τα προγράμματα είναι πολυσύνθετα, όπως και οι ανάγκες που καλύπτουν. Η εμμονή στην κυριολεκτικά μία και μοναδική λειτουργία ανά πρόγραμμα θα μπορούσε να αποτελέσει τροχοπέδη στην εξέλιξη. Φανταστείτε να είχατε μια Ferrari, που όμως θα μπορούσατε να οδηγείτε μόνο σε ταχύτητες LADA. Θα πήγαινε χαμένη τόση δύναμη. Συνεχίζοντας το παράδειγμα, η απόκτηση της Ferrari και των δυνατοτήτων της συνεπάγεται και πολυπλοκότητα κάτω από το καπώ, σε σημείο που να μπερδεύεστε και να είναι απαραίτητος ένας μηχανικός. Ίσως αυτό να μην είναι ιδανική κατάσταση, δεν είναι όμως ούτε αμιγώς κακό. Αποτελεί απλά συνέπεια της εξέλιξης.

Στο ίδιο κλίμα, το systemd σπάει (εκ προθέσεως) το POSIX. Για όσους ίσως δε γνωρίζουν, το POSIX (Portable Operating System Interface) είναι ένα σύνολο προτύπων που καθορίζουν τη διατήρηση συμβατότητας μεταξύ λειτουργικών συστημάτων και υιοθετήθηκε ως κανόνας από αρκετά Unix-like λειτουργικά αλλά και εφαρμογές. Και πάλι, είναι μια καλή πρακτική, η οποία όμως ενίοτε χρειάζεται να παραβιαστεί. Άλλωστε, η ελευθερία είναι υπέρτατη αρχή και στο λογισμικό, έτσι δεν είναι; Να τονιστεί εδώ ότι και το ίδιο το Linux σε αρκετά σημεία δε συμφωνεί απόλυτα ούτε με το POSIX αλλά ούτε και με τη φιλοσοφία του Unix. Μπορεί ορισμένοι να αγνοούν τη διάκριση αλλά είναι Unix-like και όχι fully Unix compliant. Ως εκ τούτου, δεν έχει κάποια “υποχρέωση” να ακολουθεί συγκεκριμένους κανόνες. Πιθανότατα (προσωπική άποψη του γράφοντος) το στοιχείο αυτό να είναι που του προσδίδει την ευελιξία που έχει.

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

Ένα άλλο αρνητικό στοιχείο είναι το γεγονός ότι απλώνεται πέρα από το σκοπό για τον οποίο δημιουργήθηκε αρχικά. Έχει πάψει να είναι ένα απλό init σύστημα και επεκτείνεται σε άλλα σημεία του λειτουργικού, αναλαμβάνοντας λειτουργίες που παλιότερα καθορίζονταν από διαφορετικά προγράμματα, όπως ενδεικτικά τα cron, at, inet, ConsoleKit, sethostname, modprobe. Αυτό οδήγησε κάποιους να ισχυριστούν ότι, ως κεντρικός κόμβος, συγκεντρώνει επικίνδυνα μεγάλη δύναμη (“εξουσία”) επί του συστήματος. Πώς μεταφράζεται αυτό πρακτικά με ένα παράδειγμα; Σε ένα ακραίο σενάριο όπου το systemd θα αντιμετωπίσει λειτουργικό πρόβλημα και θα καταρρεύσει, θα παρασύρει μαζί του ολόκληρο το σύστημα. Αν και δεν είναι ακριβώς το ίδιο, σκεφτείτε αναλογικά τι θα συνέβαινε αν εμφάνιζε πρόβλημα η registry των Windows.

Προσωπικά, θεωρώ το παραπάνω ορθό ως επιχείρημα κατά του systemd. Όχι τόσο στο θεωρητικό μέρος (της “εξουσίας”) αλλά στο πρακτικό. Ευσταθεί, ένας ασταθής θεμέλιος λίθος μπορεί να κρίνει την τύχη ολόκληρου του οικοδομήματος. Από την άλλη όμως, ένα από τα μειονεκτήματα των Linux-based διανομών είναι ότι δε διαθέτουν πραγματική συνοχή και ομοιογένεια αλλά είναι στην ουσία στρώματα επί στρωμάτων. Οι “ραφές” σε ορισμένα σημεία φαίνονται πολύ και είναι ένα από αυτά που προσπαθεί να καλύψει το systemd. Το αν θα το επιτύχει, μένει να κριθεί. Παρόλα αυτά, νομίζω θα ήταν προτιμότερο να προσπαθήσουμε να διασφαλίσουμε την εύρυθμη λειτουργία και τη βελτίωσή του (και όχι μόνο του systemd) από το να σκεφτόμαστε τι μπορεί να πάει στραβά κάθε φορά. Η πρόοδος εμπεριέχει και ρίσκο.

Το επόμενο αρνητικό δεν έχει να κάνει διόλου με τη λειτουργικότητα του systemd αλλά με τους δημιουργούς του. Ακολουθώντας ad hominem λογική (το να επιχειρείς να καταρρίψεις κάτι επιτιθέμενος λανθασμένα όχι στο ίδιο αλλά στο δημιουργό του), είναι πολλοί αυτοί που πιάστηκαν από τον -περίεργο, είναι η αλήθεια- χαρακτήρα ορισμένων εκ των συμμετεχόντων στην ανάπτυξη του και κάποια γεγονότα που σχετίζονται με αυτούς, ώστε να καταλογίσουν ένα ακόμα μειονέκτημα στο project. Όπως καταλαβαίνετε, η συγκεκριμένη διαμάχη στερείται ουσίας, την αναφέρουμε όμως ως μέρος της εικόνας.

Την τιμητική του είχε ο Lennart Poettering. Αυτός εδώ


Τι κακό έκανε το δόλιο παλικάρι ώστε να προκαλέσει το μένος μεγάλου μέρους της Linux κοινότητας; Ας τα πάρουμε ένα-ένα. Αρχικά, είναι υπάλληλος της Red Hat. Και όλοι γνωρίζουμε τη μοχθηρή φύση της εταιρείας αυτής (χωρίς να είναι εντελώς ανυπόστατο το παραπάνω, τολμώ να πω ότι πολλές φορές ξεπερνάει τα όρια της κακής συνωμοσιολογίας). Επίσης, εργάστηκε πάνω στο PulseAudio. Το δύστυχο αυτό project, παρόλο που πλέον βρίσκεται σε καλό δρόμο και είναι εγνωσμένης αξίας, ήταν ψιλοπροβληματικό όταν πρωτοεμφανίστηκε και -ενώ το ίδιο έχει τύχει να συμβεί με αρκετά άλλα έργα- συγκέντρωσε απίστευτα επίπεδα κακής κριτικής, η οποία μεταφράστηκε και σε προσωπικές επιθέσεις. Είναι που κατά βάθος αγαπιόμαστε μέχρι θανάτου στο open source. Έπειτα από όλα αυτά, ασχολήθηκε με διάφορα άλλα πραγματάκια. Στη συνέχεια τόλμησε (όχι μόνος του φυσικά) να σκεφτεί και να υλοποιήσει το systemd. Και τότε θυμήθηκαν κάποιοι ποιος ήταν και γιατί τον μισούσαν κάποτε. Συν το γεγονός ότι, φαινομενικά τουλάχιστον, μερικές φορές φέρεται (και φαίνεται) να ξεπερνάει κατά πολύ τα αρνητικά ή “αρνητικά” στοιχεία που περιλαμβάνει ο χαρακτήρας του Linus Torvalds (και δεν είναι εύκολο αυτό), δε θέλει και πολύ να δέσει το γλυκό. Εδώ όμως ταιριάζει γάντι η άποψη του ίδιου του Linus, ότι δηλαδή σημασία έχει ο κώδικας και κατ' επέκταση η τεχνολογία κι όχι οι αρεστές ή μη προσωπικότητες. Για τεχνολογία μιλάμε πρώτιστα κι όχι για καλλιέργεια συμπάθειας και ο κώδικας είναι που θα έπρεπε να ενδιαφέρει.

Ένα ακόμα αρνητικό που λέγεται είναι το ότι το systemd παραβιάζει την ελευθερία των χρηστών με την ιδιότητά του ως PID 1 και την επιβολή του κι ότι είναι αδύνατο να χρησιμοποιηθούν κάποια DE χωρίς αυτό (λέγε με GNOME). Εδώ να πούμε ότι, εκτός κι αν πιστεύει κάποιος ότι σχεδόν όλες οι μεγάλες διανομές -με τη διαφορετική φιλοσοφία και νοοτροπία που τις διακρίνει- αποφάσισαν να συνωμοτήσουν εις βάρος των χρηστών και να ενσωματώσουν κάτι κακό(βουλο) εν γνώσει τους, δεν υπάρχει κανενός είδους επιβολή. Απλά, στη θεωρία τουλάχιστον, το systemd είναι μέχρι στιγμής ό,τι καλύτερο υπάρχει στο είδος του. Όταν ακόμα και το Ubuntu, που είχε το Upstart, αποφασίζει να ακολουθήσει το Debian και να το εγκαταλείψει για χάρη του systemd, δε μπορεί, κάτι θα σημαίνει αυτό.

Και για να μην υπάρχουν σκιές, κανένα DE δεν είναι (προς το παρόν τουλάχιστον) απόλυτα δέσμιο του systemd. Υπάρχει τεράστια παρεξήγηση αναφορικά με το GNOME, το οποίο χρησιμοποιεί -αλλά δεν εξαρτάται από- ένα μέρος του systemd, το logind. Το logind πλέον έχει ως εξάρτηση το systemd (αρχικά δεν το είχε), η επιλογή της συνέχειας χρήσης του όμως ήταν καθαρά απόφαση του GNOME. Βέβαια, εδώ θα πει κάποιος ότι το GNOME συνδέεται με τη Red Hat, όπως και οι developers του systemd. Άρα, ίσως δεν είναι σύμπτωση. Αξίζει όμως να αναφερθεί ότι το GNOME προσανατολίζεται από την έλευση του GNOME 3 στη δημιουργία ενός νέου λειτουργικού, του GNOME OS κι αυτό έχει ως συνέπεια ορισμένες επιλογές του να ξεπερνούν αυτές ενός απλού desktop interface.

Αυτά είναι λίγο-πολύ τα βασικά σημεία της αρνητικής κριτικής που δέχτηκε το systemd. Με τον καιρό, κάποιοι αναθεώρησαν ή έστω επέλεξαν να χαμηλώσουν την ένταση και να το κρίνουν καλύτερα αφότου αποκτήσουν προσωπική εμπειρία. Μην ξεχνάμε ότι αρκετοί έβγαλαν χολή χωρίς καν να το έχουν χρησιμοποιήσει. Ορισμένοι μάλιστα το τράβηξαν στα άκρα, δημιουργώντας την -αθλιότητα, κατά τη γνώμη μου κι εφόσον μιλάμε για ΕΛ/ΛΑΚ- Boycott Systemd. Η αρχική σελίδα δεν υπάρχει πλέον, μπορείτε όμως να δείτε μέρος του περιεχομένου της εδώ (στα αγγλικά). Επίσης, υπάρχει και μια λίστα με Linux διανομές και άλλα λειτουργικά που δε χρησιμοποιούν το systemd, για όποιον τυχόν ενδιαφέρεται. Να αναφέρουμε ακόμα ότι μια ομάδα βετεράνων Unix admins, όπως οι ίδιοι αποκαλούνται, έκαναν κάτι που συνηθίζεται στο χώρο και αποφάσισαν να δημιουργήσουν ένα fork. Όχι όμως οποιοδήποτε fork αλλά ολόκληρη τη διανομή Debian, χωρίς το systemd. Ο γράφων αναρωτιέται αν είναι συνετή μια τέτοια κίνηση, δε μπορεί όμως παρά να τους ευχηθεί καλή επιτυχία στον εξαιρετικά δύσκολο δρόμο που διάλεξαν.

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

Τα δύο πρώτα αναφέρθηκαν νωρίτερα ως μειονεκτήματα, εντούτοις έχουν και την καλή πλευρά τους, ανάλογα με τη θέση του παρατηρητή. Όπως είπαμε, το systemd σπάει το POSIX και τη συμβατότητα που εγγυάται αυτό. Ένας από τους λόγους που το κάνει όμως, είναι για να προσφέρει καλύτερη συμβατότητα και περισσότερες δυνατότητες στο ίδιο το Linux. Όπερ μεθερμηνευόμενον εστί, σχεδιάστηκε από καταβολής του αποκλειστικά με βάση το Linux API. Αυτό σημαίνει ότι δε μπορεί να τρέξει σε μη Linux-based σύστημα, ταυτόχρονα όμως αυξάνεται η δυναμική του εντός του Linux οικοσυστήματος μέσω της στοχευμένης ανάπτυξης (ένα είδος πυρήνα, συγκεκριμένο εύρος διεργασιών κλπ). Στην πράξη, για διαφορετικές διανομές που το χρησιμοποιούν, οι σχετικές εντολές, οι τρόποι ελέγχου και γενικά ολόκληρη η λειτουργία θα είναι η ίδια επακριβώς. Εξαλείφεται έτσι ο πονοκέφαλος και το μπλέξιμο μεταξύ SysV, Upstart και οποιουδήποτε άλλου συστήματος. Είναι ίσως η πρώτη φορά που επιχειρείται με σοβαρές κινήσεις κάποιο είδος standardization στο Linux κι αυτό είναι κάτι που πολλοί επιθυμούν εδώ και αρκετά χρόνια.

Το δεύτερο αρνητικό που θα αναφέρουμε εδώ ως θετικό είναι η πολυδιάστατη φύση του systemd. Πολυθεσίτης κι ερημοσπίτης λέμε κι αυτό ισχύει πολλές φορές. Υπό διαφορετική οπτική όμως, η διαχείριση ολόκληρου του συστήματος γίνεται πιο εύκολη όταν, αντί για 10-20 διάσπαρτα και διαφορετικά μεταξύ τους μικρότερα προγράμματα, υπάρχει ένα κεντρικό σημείο. Σαν τον πίνακα με τις ασφάλειες του ρεύματος ένα πράγμα, όλα δίπλα-δίπλα. Για να μην υπάρξει παρεξήγηση, μιλάμε για ευκολία, όχι απαραίτητα για βολικότητα. Η πρώτη είναι, συνήθως, ζητούμενο. Η δεύτερη απλοποιεί (=χαζεύει) το λειτουργικό και συνάμα το χρήστη του.

Άλλο θετικό είναι ότι με το systemd χρειάζονται λιγότερες και πιο απλοποιημένες ενέργειες από το σύστημα για να εκκινήσει ή να τερματίσει κάποια υπηρεσία (service). Αυτό, σε συνδυασμό με τη δυνατότητα πραγματοποίησης παράλληλων διεργασιών, πετυχαίνει το εξής: περισσότερα πράγματα σε λιγότερο χρόνο και με λιγότερο φόρτο, κάτι που περνάει στο σύστημα και ως χαμηλότεροι χρόνοι εκκίνησης και τερματισμού.

Επίσης, γίνεται καλύτερη αξιοποίηση ορισμένων χαρακτηριστικών του πυρήνα, όπως τα control groups (cgroups), τα οποία ρυθμίζουν τη χρηση των πόρων του συστήματος από τις επιμέρους διεργασίες. Επιπρόσθετα, έχει τη δυνατότητα λήψης “στιγμιοτύπων” του συστήματος και των ενεργών διεργασιών, βοηθώντας έτσι στην επαναφορά από μια κακή στιγμή όπως λ.χ. η απότομη διακοπή ρεύματος.

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

Άλλα πλεονεκτήματα είναι η ευελιξία στον εντοπισμό-προσάρτηση αφαιρούμενων μέσων και η (ακόμα και αυτοματοποιημένη) εκκίνηση και ο τερματισμός διεργασιών “on demand”. Υπάρχουν πολλά περισσότερα, λόγω χώρου όμως θα παροτρύνω τους ενδιαφερόμενους να μελετήσουν μόνοι τους.

Με μια απλοποιημένη ερμηνεία, το systemd δεν είναι ένα υδροκέφαλο τέρας. Στην ουσία αποτελεί την ομπρέλα κάτω από την οποία συγκεντρώνονται διάφορα και διαφορετικά προγράμματα. Κάτι σαν τον οργανωτή της ομάδας.

Για εσάς που δε σας πήρε ο ύπνος μέχρι εδώ, ας δούμε κάποια απλά παραδείγματα χρήσης του.

Το βασικό συστατικό των εντολών είναι η λεξούλα systemctl (system control) κι ενίοτε η systemd. Έτσι λοιπόν, για την εκκίνηση και τον τερματισμό κάποιας διεργασίας, π.χ. το dhcpcd, οι αντίστοιχες εντολές είναι (το # δηλώνει δικαιώματα root και το $ τον απλό χρήστη):

Κώδικας:

# systemctl start dhcpcd

Κώδικας:

# systemctl stop dhcpcd

Παρόμοια, αν θέλουμε η διεργασία να εκκινεί ή όχι σε κάθε boot, δίνουμε

Κώδικας:

# systemctl enable dhcpcd

Κώδικας:

# systemctl disable dhcpcd

Με αυτά τα τέσσερα θα ασχοληθείτε ως επί το πλείστον. Τα πρώτα δύο δεν εμφανίζουν κάποιο μήνυμα στο τερματικό αλλά επιστρέφουν στο prompt μετά από επιτυχή εκτέλεση. Τα δεύτερα έχουν το αποτέλεσμα που μπορείτε να δείτε παρακάτω:


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

Κώδικας:

$ systemctl status όνομα διεργασίας

Εδώ, ανάλογα με το αν τρέχει ή όχι, θα μας εμφανίσει κάποιο περιεκτικό μήνυμα όπως αυτό:


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

Μπορούμε επίσης να δούμε το συνολικό χρόνο εκκίνησης του συστήματός μας, με την εντολή (προσοχή στην αρχική λέξη)

Κώδικας:

$ systemd-analyze

η οποία μας επιστρέφει κάτι σαν αυτό:


Για ακόμα μεγαλύτερη χρονική ακρίβεια ανά διεργασία, δίνουμε

Κώδικας:

$ systemd-analyze blame

Με την εντολή systemctl --help μπορείτε να δείτε όλες τις σχετικές εισαγωγές, οι οποίες χρειάζονται το δικό τους τόμο για να τις καλύψουμε αναλυτικά εδώ. Επίσης, ένα δείγμα “χειροποίητου” αρχείου service για το systemd είναι το καθ' όλα λιτό που ακολουθεί:


Σε κάθε περίπτωση, μην τη φοβάστε την αλλαγή και σίγουρα μην κρίνετε χωρίς πρώτα να αποκτήσετε επαρκή προσωπική άποψη. Λάβετε υπ' όψη σας επίσης ότι κάποιες διανομές αρχίζουν τώρα την επαφή τους με το systemd και ίσως κάνουν κάποια λάθη στην ενσωμάτωσή του. Τυχόν προβλήματα που ίσως αντιμετωπίσετε δηλαδή πιθανόν και να οφείλονται στο γεγονός αυτό και όχι στο ίδιο το systemd. Περισσότερα σχετικά με τους μύθους, τις πραγματικότητες αλλά και τους στόχους του systemd μπορείτε να διαβάσετε στο blog του Lennart Poettering, πιθανότατα στο σχετικό wiki της διανομής σας αλλά και σε αρκετά σημεία στο διαδίκτυο.

 [Πρέπει να είστε εγγεγραμμένοι και συνδεδεμένοι για να δείτε αυτόν το σύνδεσμο.]

Source: [Πρέπει να είστε εγγεγραμμένοι και συνδεδεμένοι για να δείτε αυτόν το σύνδεσμο.]