Σε αυτό το δεύτερο μέρος του οδηγού δύο μερών σχετικά με τη ρύθμιση του Linux υπηρεσιών για αυτόματη εκκίνηση μετά από επανεκκίνηση ή κατάρρευση του συστήματος, θα συζητήσουμε λεπτομερώς το σύστημα init. Μπορείτε να ανατρέξετε στο Μέρος 1 της σειράς: Πώς να ρυθμίσετε μια υπηρεσία Linux για αυτόματη εκκίνηση μετά από επανεκκίνηση ή κατάρρευση συστήματος: Πρακτικά παραδείγματα εδώ.
Ο παρών οδηγός θα επικεντρωθεί αρκετά στη θεωρία. Επομένως, θα πρέπει να τον χρησιμοποιήσετε ως σημείο αναφοράς για να κατανοήσετε βαθύτερα πώς λειτουργεί το σύστημα init στο Linux. Στο πρώτο μέρος αυτού του οδηγού, μοιραστήκαμε ορισμένα αποσπάσματα κώδικα και σενάρια εκκίνησης (startup scripts) που διαβάζει το σύστημα init κατά την εκκίνηση. Χρησιμοποιήσαμε επίσης το MySQL ως παράδειγμα για να μάθουμε πώς να ενεργοποιούμε και να απενεργοποιούμε μια υπηρεσία Linux για αυτόματη εκκίνηση μετά από κατάρρευση ή επανεκκίνηση. Όπως μάθατε στο πρώτο μέρος αυτού του οδηγού δύο μερών, υπάρχουν τρία συστήματα init που χρησιμοποιούνται σε διαφορετικές διανομές του Linux: το System V, το Upstart και το Systemd. Μπορείτε να ανατρέξετε στο πρώτο μέρος αυτού του οδηγού για να κατανοήσετε τη διανομή και την έκδοση που έχει ρυθμιστεί να χρησιμοποιεί ένα συγκεκριμένο σύστημα init.
Σε αυτόν τον οδηγό, θα εξηγήσουμε τον κώδικα που χρησιμοποιήσαμε στο πρώτο μέρος του οδηγού. Θα αναλύσουμε τις εντολές και τα αρχεία ρυθμίσεων που χρησιμοποιεί το σύστημα init. Ας ξεκινήσουμε!
Προαπαιτούμενα
Στο κλείσιμο του πρώτου μέρους αυτού του οδηγού δύο μερών, αναφέραμε ότι θα πρέπει να διατηρήσετε τους τρεις δοκιμαστικούς διακομιστές σε λειτουργία. Εάν τους είχατε διαγράψει, μπορείτε να επιστρέψετε και να τους δημιουργήσετε ξανά. Αυτό θα σας βοηθήσει να παρακολουθήσετε τον οδηγό. Οι τρεις δοκιμαστικοί διακομιστές που πρέπει να έχετε είναι:
- Ubuntu 9.04 και παλαιότερο, ή Debian 6 x64 (θα το χρησιμοποιήσουμε για να επιδείξουμε το σύστημα init System V)
- Ubuntu 14.04 x64 (θα το χρησιμοποιήσουμε για να επιδείξουμε το Upstart). Ορίστε ένας οδηγός για το πώς να ρυθμίσετε εύκολα τον Ubuntu διακομιστή σας.
- CentOS 7 x64 (θα το χρησιμοποιήσουμε για να επιδείξουμε το Systemd).
Θα πρέπει να έχετε έναν χρήστη με δικαιώματα sudo σε καθέναν από τους διακομιστές που θα χρησιμοποιήσετε για να εκτελέσετε τις εντολές. Αυτός ο οδηγός για τη ρύθμιση του αρχείου sudoers στο Linux μπορεί να σας καθοδηγήσει.
Note: Οι εντολές στον οδηγό θα επηρεάσουν τις υπηρεσίες του συστήματος. Επομένως, δεν πρέπει να τις εφαρμόσετε σε έναν ενεργό διακομιστή παραγωγής.
Runlevels
Ένα runlevel είναι ένα επίπεδο λειτουργίας που περιγράφει την τρέχουσα κατάσταση ενός συστήματος Linux σε σχέση με το ποιες υπηρεσίες είναι διαθέσιμες. Η ιδέα προέρχεται από το System V init. Όταν το σύστημα Linux εκκινεί, αρχικοποιεί τον πυρήνα (kernel), εισέρχεται σε ένα runlevel και εκτελεί το σενάριο εκκίνησης (startup script) που σχετίζεται με αυτό το runlevel. Μπορείτε να εκτελέσετε μόνο ένα runlevel κατά την εκκίνηση.
Άλλα παραδείγματα runlevels περιλαμβάνουν την κατάσταση τερματισμού λειτουργίας, τη λειτουργία επανεκκίνης, τη λειτουργία ενός χρήστη (single-user mode) κ.λπ. Κάθε επίπεδο καθορίζει ποιες υπηρεσίες θα εκτελούνται σε αυτήν την κατάσταση. Ορισμένες υπηρεσίες μπορούν να εκτελούνται σε περισσότερα από ένα επίπεδα, ενώ άλλες όχι.
Υπάρχουν επτά runlevels: από το 0 έως το 6. Παρακάτω δίνεται ο ορισμός των επτά runlevels:
- Runlevel 0: Τερματισμός λειτουργίας συστήματος
- Runlevel 1: Λειτουργία ενός χρήστη και διάσωσης (Single-user and rescue mode)
- Runlevels 2, 3, 4: Λειτουργία πολλών χρηστών και κειμένου με ενεργοποιημένο το δίκτυο
- Runlevel 5: Λειτουργία πολλών χρηστών, με ενεργοποιημένο δίκτυο και γραφικό περιβάλλον
- Runlevel 6: Επανεκκίνηση συστήματος
Τα runlevels δεν εκτελούνται απαραίτητα διαδοχικά. Τα runlevels 2, 3 και 4 διαφέρουν ανάλογα με τη διανομή Linux που εκτελείτε. Μπορείτε να εφαρμόσετε το runlevel 4 σε ορισμένες διανομές και όχι σε άλλες. Όταν ενεργοποιήσατε μια υπηρεσία για αυτόματη εκκίνηση, όπως εξηγήθηκε στο πρώτο μέρος, στην πραγματικότητα την προσθέσατε σε ένα runlevel. Στο System V, το λειτουργικό σύστημα ξεκινά με ένα συγκεκριμένο runlevel και κατά την εκκίνηση, προσπαθεί να ξεκινήσει όλες τις υπηρεσίες που σχετίζονται με αυτό το runlevel. Τα runlevels είναι στόχοι (targets) στο Systemd, το οποίο θα συζητήσουμε στην ενότητα για το Systemd.
Init και PID 1
Το σύστημα init είναι η πρώτη-πρώτη διεργασία που εκτελείται όταν εκκινεί ένα σύστημα Linux και ο πυρήνας (Kernel) φορτώνεται στη μνήμη. Εκτελεί διάφορες εργασίες, συμπεριλαμβανομένου του καθορισμού του τρόπου με τον οποίο θα φορτωθεί μια διεργασία χρήστη ή μια υπηρεσία συστήματος, με ποια σειρά και αν θα πρέπει να ξεκινά αυτόματα. Σε κάθε διανομή Linux, κάθε διεργασία αναγνωρίζεται από ένα αναγνωριστικό διεργασίας (PID) και το init έχει PID 1. Είναι ο γονέας όλων των άλλων διεργασιών που ξεκινούν διαδοχικά καθώς εκκινεί το σύστημα.
Ιστορικό του init
Το σύστημα init που συναντάται στις πρόσφατες διανομές Linux αποτελεί βελτίωση του αρχικού. Οι παλαιότερες εκδόσεις των διανομών Linux χρησιμοποιούσαν το System V init, το οποίο χρησιμοποιούνταν παρομοίως στα συστήματα Unix. Καθώς το Linux εξελισσόταν, υλοποιήθηκε ο δαίμονας init Upstart – δημιουργήθηκε από την Ubuntu. Τώρα, (κατά τη συγγραφή αυτού του οδηγού, το 2021) έχουμε τον δαίμονας init Systemd – ο οποίος υλοποιήθηκε για πρώτη φορά από τη Fedora. Καθώς τα συστήματα Linux συνεχίζουν να εξελίσσονται, ενδέχεται να υπάρξει ένα νεότερο σύστημα init. Για αυτόν τον οδηγό, θα συζητήσουμε αυτά τα τρία: System V, Upstart και Systemd.
Οι πρόσφατες εκδόσεις Linux διαθέτουν από προεπιλογή το σύστημα init Systemd. Ωστόσο, έχουν διατηρήσει τα άλλα παλαιότερα συστήματα init για συμβατότητα προς τα πίσω. Υπάρχουν διαφορετικές υλοποιήσεις του System V που μπορείτε να χρησιμοποιήσετε σε άλλες παραλλαγές του Linux. Για παράδειγμα, το FreeBSD, μια παραλλαγή του UNIX, χρησιμοποιεί το BSD init. Οι παλαιότερες εκδόσεις του Debian χρησιμοποιούν το SysVinit. Και τα δύο προέρχονται από το System V.
Ο τρόπος με τον οποίο κάθε έκδοση του δαίμονα init διαχειρίζεται τις υπηρεσίες είναι διαφορετικός. Οι βελτιώσεις που προστέθηκαν σε κάθε έκδοση είχαν ως στόχο ένα ισχυρό εργαλείο διαχείρισης υπηρεσιών που θα χειριζόταν όλα όσα χρειάζεται ένα σύστημα Linux από υπηρεσίες, συσκευές, θύρες και άλλους πόρους. Υπήρχε ανάγκη για ένα ισχυρό σύστημα που θα μπορούσε να φορτώνει πόρους παράλληλα και που θα μπορούσε να ανακάμψει κομψά από μια κατάρρευση του συστήματος.
Ακολουθία System V Init
Το System V χρησιμοποιεί ένα αρχείο inittab για να διατηρεί οδηγίες αρχικοποίησης. Το Upstart διατηρεί το αρχείο inittab για συμβατότητα προς τα πίσω. Δείτε τη ροή εκκίνησης του System V:
- Το σύστημα init προέρχεται από το δυαδικό αρχείο /sbin/init.
- Μόλις το σύστημα init φορτωθεί στη μνήμη, διαβάζει το πρώτο του αρχείο στο /etc/inittab.
- Μία από τις καταχωρίσεις σε αυτό το αρχείο καθορίζει το runlevel στο οποίο πρέπει να εκκινήσει το μηχάνημα. Για παράδειγμα, εάν η τιμή για το runlevel έχει οριστεί σε 5, το Linux θα εκκινήσει σε λειτουργία πολλών χρηστών, με γραφικό περιβάλλον και ενεργοποιημένο το δίκτυο (σύνηθες σε διανομές που έχουν σχεδιαστεί για επιτραπέζια χρήση). Το runlevel που καθορίζεται εδώ είναι γνωστό ως το προεπιλεγμένο runlevel επειδή είναι αυτό που θα χρησιμοποιείται πάντα.
- Στη συνέχεια, το σύστημα init κοιτάζει βαθύτερα στο /etc/inittab αρχείο και διαβάζει ποια σενάρια init πρέπει να εκτελέσει για αυτό το runlevel.
Βρίσκοντας ποια σενάρια πρέπει να εκτελέσει για ένα δεδομένο runlevel, το σύστημα init θα βρει ποιες υπηρεσίες πρέπει να εκκινήσει. Σε αυτά τα σενάρια init είναι που συνήθως ρυθμίζετε τη συμπεριφορά εκκίνησης για μεμονωμένες υπηρεσίες, με τον ίδιο τρόπο που ρυθμίσαμε την υπηρεσία MySQL στο πρώτο μέρος αυτού του οδηγού.
Δομή σεναρίων System V Init
Σε αυτήν την ενότητα, θα εξετάσουμε λεπτομερώς τα σενάρια init. Τα αρχεία ρυθμίσεων του System V ή τα σενάρια init είναι αυτά που ελέγχουν τις υπηρεσίες. Τα σενάρια init αρχικοποιούν μια υπηρεσία, εξ ου και το όνομα σενάριο init.
Κάθε υπηρεσία έχει το δικό της σενάριο init. Για παράδειγμα, το σενάριο init της MySQL ελέγχει τον διακομιστή MySQL. Οι πάροχοι εφαρμογών παρέχουν τα σενάρια init για τη συγκεκριμένη εφαρμογή τους, ενώ οι εγγενείς υπηρεσίες Linux συνοδεύουν την εγκατάσταση του λειτουργικού συστήματος. Όταν δημιουργείτε μια προσαρμοσμένη εφαρμογή, μπορείτε επίσης να δημιουργήσετε τα δικά σας προσαρμοσμένα σενάρια init για αυτήν.
Για να ξεκινήσει μια υπηρεσία όπως ο διακομιστής MySQL, το δυαδικό της πρόγραμμα φορτώνεται πρώτα στη μνήμη. Ανάλογα με τις ρυθμίσεις του, το πρόγραμμα μπορεί να συνεχίσει να εκτελείται στο παρασκήνιο για να συνεχίσει να δέχεται συνδέσεις πελατών. Το σενάριο init της υπηρεσίας χειρίζεται την εργασία εκκίνησης, διακοπής ή επαναφόρτωσης της δυαδικής εφαρμογής. Τα σενάρια init στο System V είναι σενάρια κελύφους. Ένα άλλο όνομα για αυτά είναι σενάρια rc (run command).
Δομή καταλόγου System V
Ο γονικός κατάλογος για τα σενάρια init είναι ο κατάλογος /etc. Ο κατάλογος /etc/init.d είναι ο πραγματικός κατάλογος για τα σενάρια κελύφους init. Τα σενάρια συνδέονται με συμβολικούς συνδέσμους στους καταλόγους rc.
Υπάρχουν αρκετοί κατάλογοι rc μέσα στον κατάλογο /etc, καθένας με έναν αριθμό στο όνομά του. Οι αριθμοί αντιπροσωπεύουν διαφορετικά runlevels. Εάν εμφανίσετε τα περιεχόμενα του καταλόγου, θα δείτε ονόματα όπως /etc/rc0.d, /etc/rc1.d, /etc/rc2.d, κ.λπ.
Εάν δείτε τα περιεχόμενα καθενός από τους καταλόγους rc, θα δείτε αρχεία που ξεκινούν με K ή S στο όνομα αρχείου τους, ακολουθούμενα από δύο ψηφία. Αυτά τα αρχεία περιέχουν συμβολικούς συνδέσμους που δείχνουν πίσω στα πραγματικά σενάρια κελύφους init του πραγματικού προγράμματος. Τα γράμματα K και S είναι συντομογραφίες: το K σημαίνει Kill ή Stop, ενώ το S σημαίνει Start. Τα δύο ψηφία στα ονόματα των αρχείων αντιπροσωπεύουν τη σειρά εκτέλεσης. Αν δείτε ένα αρχείο με όνομα K05script_name, θα εκτελεστεί πριν από ένα αρχείο με όνομα K09script_name.
Εκκίνηση
Προχωρώντας με τη σειρά εκκίνησης, ας δούμε πώς καλούνται τα σενάρια init.
Τα σενάρια S και K δεν καλούνται απευθείας από το σύστημα init. Αντίθετα, καλούνται από ένα άλλο σενάριο: το /etc/init.d/rc σενάριο. Το αρχείο /etc/inittab καθοδηγεί τον δαίμονα init σε ποιο runlevel πρέπει να εκκινήσει το σύστημα από προεπιλογή. Ανάλογα με το καθορισμένο runlevel, μια γραμμή στο αρχείο /etc/inittab καλεί το σενάριο /etc/init.d/rc, περνώντας το προεπιλεγμένο runlevel ως παράμετρο. Χρησιμοποιώντας αυτήν την παράμετρο, το σενάριο θα καλέσει τα αρχεία κάτω από τον αντίστοιχο κατάλογο /etc/rcN.d, όπου το N υποδηλώνει το runlevel. Για παράδειγμα, εάν ο διακομιστής εκκινεί με runlevel 5, θα κληθούν τα αντίστοιχα αρχεία κάτω από τον κατάλογο /etc/rc5.d.
Μέσα στον κατάλογο rc, όλα τα σενάρια K εκτελούνται αριθμητικά με όρισμα stop, ενώ όλα τα σενάρια S εκτελούνται παρόμοια με όρισμα start. Τα αντίστοιχα πραγματικά σενάρια κελύφους init για το πρόγραμμα στο οποίο δείχνουν οι συμβολικοί σύνδεσμοι κάτω από τον κατάλογο /etc/rcN.d θα κληθούν με τις παραμέτρους stop και start αντίστοιχα.
Με απλά λόγια, αυτό που συμβαίνει κάθε φορά που ένα σύστημα Linux εισέρχεται ή μεταβαίνει σε ένα συγκεκριμένο runlevel είναι ότι θα εκτελεστούν ορισμένα σενάρια για να σταματήσουν κάποιες υπηρεσίες, ενώ άλλα θα εκτελεστούν για να ξεκινήσουν άλλες υπηρεσίες. Αυτή η διαδικασία διασφαλίζει ότι οποιαδήποτε διεργασία δεν υποτίθεται ότι εκτελείται σε μια δεδομένη κατάσταση του Linux σταματά, και οποιαδήποτε διεργασία θα έπρεπε να εκτελείται ξεκινά αυτόματα.
Αυτόματη εκκίνηση System V
Όταν ενεργοποιείτε μια υπηρεσία για αυτόματη εκκίνηση κατά την εκκίνηση του συστήματος, τροποποιείτε απευθείας τη συμπεριφορά του init. Για παράδειγμα, εάν ρυθμίσετε μια υπηρεσία να ξεκινά αυτόματα στο runlevel 2, η διεργασία init δημιουργεί τους κατάλληλους συμβολικούς συνδέσμους στον κατάλογο /etc/rc2.d. Για να σας βοηθήσουμε να κατανοήσετε, θα το εξηγήσουμε με ένα παράδειγμα.
Παράδειγμα System V
Για να σας δώσουμε ένα πρακτικό παράδειγμα, θα χρησιμοποιήσουμε τη διαμόρφωση της υπηρεσίας MySQL από το μέρος 1. Επομένως, συνδεθείτε στο Debian 6 VPS με τον sudo/root χρήστη σας χρησιμοποιώντας ssh (ή putty εάν είστε σε Windows) και προχωρήστε με τα ακόλουθα βήματα.
Βήμα 1: Ανοίξτε και εξετάστε το αρχείο inittab
Πρώτα, εισαγάγετε την ακόλουθη εντολή για να δείτε τα περιεχόμενα του αρχείου inittab στο τερματικό:
|
1 |
cat /etc/inittab | grep initdefault |
Τα περιεχόμενα του αρχείου θα πρέπει να είναι κάπως έτσι:
|
1 |
id:2:initdefault: |
Ο αριθμός 2 υποδηλώνει το runlevel με το οποίο ξεκινά το σύστημα. Σε αυτήν την περίπτωση, το runlevel 2 είναι το προεπιλεγμένο, επομένως αυτό το σύστημα Debian θα ξεκινήσει σε runlevel 2 ως multi-user, text mode. Μπορείτε να εκτελέσετε την ακόλουθη εντολή για επιβεβαίωση:
|
1 |
cat /etc/inittab | grep Runlevel |
Θα εμφανίσει έξοδο παρόμοια με:
|
1 2 3 4 |
# Runlevel 0 is halt. # Runlevel 1 is single-user. # Runlevels 2-5 are multi-user. # Runlevel 6 is reboot. |
Βήμα 2: Εξέταση των καταλόγων rc
Στη συνέχεια, για να εμφανίσετε τους καταλόγους rc, εκτελέστε την ακόλουθη εντολή:
|
1 |
ls -ld /etc/rc*.d |
Εδώ είναι ένα στιγμιότυπο οθόνης της εξόδου:

Όπως είδαμε νωρίτερα στο αρχείο inittab, το σύστημα έχει ρυθμιστεί να εκκινεί σε runlevel 2, επομένως τα σενάρια κάτω από τον κατάλογο /etc/rc2.d θα εκτελεστούν κατά την εκκίνηση του συστήματος. Μπορείτε να εμφανίσετε τα περιεχόμενα αυτού του καταλόγου χρησιμοποιώντας την εντολή:
|
1 |
ls -l /etc/rc2.d |
Όπως μπορείτε να δείτε από την έξοδο, τα αρχεία είναι απλώς συμβολικοί σύνδεσμοι που δείχνουν στα πραγματικά αρχεία σεναρίων κάτω από τον κατάλογο /etc/init.d. Εδώ είναι ένα απόσπασμα της εξόδου:

Δεν υπάρχουν σενάρια K σε αυτόν τον κατάλογο, μόνο σενάρια S (start). Τα σενάρια θα ξεκινήσουν τις υπηρεσίες που συνδέονται εδώ, όπως το rsync. Μπορείτε επίσης να παρατηρήσετε την υπηρεσία mysql που αναφέρεται, την οποία συζητάμε στο επόμενο υποθέμα.
Βήμα 3: Εξέταση του σεναρίου Init
Όταν εγκαθίσταται μια υπηρεσία που είναι συμβατή με το System V, δημιουργεί ένα σενάριο κελύφους (shell script) στον κατάλογο /etc/init.d. Μπορείτε να ελέγξετε τη διαθεσιμότητα του σεναρίου κελύφους της MySQL εισάγοντας την ακόλουθη εντολή:
|
1 |
ls -l /etc/init.d/my* |
Εμφανίζει το παρακάτω αποτέλεσμα:

Το αρχείο είναι αρκετά μεγάλο. Μπορείτε να εισαγάγετε την ακόλουθη εντολή για να δείτε τα περιεχόμενά του:
|
1 |
cat /etc/init.d/mysql | less |
Βήμα 4: Χρήση του chkconfig ή του sysv-rc-conf
Chkconfig είναι μια εντολή που μπορείτε να χρησιμοποιήσετε σε διανομές που βασίζονται στο RHEL όπως το CentOS για να ενεργοποιήσετε ή να απενεργοποιήσετε υπηρεσίες συμβατές με το System V. Μπορείτε επίσης να τη χρησιμοποιήσετε για να δείτε μια λίστα με τις εγκατεστημένες υπηρεσίες και τα αντίστοιχα runlevels τους. Δείτε την εντολή για αυτό (λειτουργεί σε CentOS):
|
1 |
chkconfig --list | grep service_name |
Στις διανομές Debian, ένα τέτοιο εργαλείο δεν υπάρχει εγγενώς. Το update-rc.d στα συστήματα Debian εγκαθιστά και καταργεί μόνο υπηρεσίες από τα runlevels. Υπάρχει ένα προσαρμοσμένο εργαλείο που μπορείτε να χρησιμοποιήσετε για να φέρετε τη λειτουργικότητα του chkconfig στα συστήματα Debian. Εισαγάγετε την ακόλουθη εντολή για να το εγκαταστήσετε:
|
1 |
sudo apt-get install sysv-rc-conf –y |
Μόλις εγκατασταθεί, μπορείτε να εκτελέσετε την ακόλουθη εντολή για να δείτε τις συμπεριφορές των runlevels για διάφορες υπηρεσίες:
|
1 |
sudo sysv-rc-conf |
Το αποτέλεσμα αυτής της εντολής είναι μορφοποιημένο σε έναν πίνακα που δείχνει το όνομα της υπηρεσίας στα αριστερά και το runlevel στο οποίο εκτελείται η υπηρεσία:

Το X υποδεικνύει το runlevel στο οποίο θα εκτελείται η υπηρεσία. Αυτό το εργαλείο σάς επιτρέπει να απενεργοποιήσετε ή να ενεργοποιήσετε μια υπηρεσία για ένα runlevel χρησιμοποιώντας τα πλήκτρα βέλους και το πλήκτρο διαστήματος (space bar). Για να εξέλθετε από το εργαλείο, πατήστε Q.
Βήμα 5: Δοκιμή της συμπεριφοράς εκκίνησης της MySQL κατά την εκκίνηση του συστήματος
Από το παραπάνω στιγμιότυπο οθόνης, μπορείτε να δείτε ότι η υπηρεσία mysql είναι ενεργοποιημένη στα runlevels 2,3,4,5. Μπορείτε να απενεργοποιήσετε τη MySQL χρησιμοποιώντας την ακόλουθη εντολή:
|
1 |
sudo update-rc.d mysql disable |
Το αποτέλεσμα μοιάζει με αυτό. Παρατηρήστε ότι η υπηρεσία έχει σταματήσει για όλα τα runlevels:

Εκτελέστε την παρακάτω εντολή για να δείτε τα περιεχόμενα του καταλόγου:
|
1 |
ls -l /etc/rc2.d |
Δείτε τη γραμμή mysql στο παρακάτω αποτέλεσμα:
|
1 |
lrwxrwxrwx 1 root root 15 Dec 11 05:28 K01mysql -> ../init.d/mysql |
Το αποτέλεσμα δείχνει ότι ο συμβολικός σύνδεσμος (symlink) έχει αλλάξει σε K, που σημαίνει Kill (διακοπή). Επομένως, η MySQL δεν θα ξεκινά αυτόματα από προεπιλογή στο runlevel 2. Όποτε ενεργοποιείτε ή απενεργοποιείτε μια υπηρεσία στο System V, αυτό είναι που συμβαίνει. Εφόσον υπάρχει ένα σενάριο S (start) στον προεπιλεγμένο κατάλογο runlevel για μια υπηρεσία, ο δαίμονας init θα ξεκινά αυτήν την υπηρεσία κατά την εκκίνηση του συστήματος.
Για να ενεργοποιήσετε ξανά την υπηρεσία, εισαγάγετε την ακόλουθη εντολή:
|
1 |
sudo update-rc.d mysql enable |
Βήμα 6: Δοκιμή της συμπεριφοράς εκκίνησης της MySQL μετά από κατάρρευση του συστήματος
Σε αυτήν την ενότητα, θα συζητήσουμε πώς το System V διαχειρίζεται τις καταρρεύσεις υπηρεσιών. Μπορείτε να χρησιμοποιήσετε αυτή τη γνώση για να διαμορφώσετε τη συμπεριφορά των προσαρμοσμένων υπηρεσιών σας μετά από μια κατάρρευση.
Στο πρώτο μέρος αυτού του οδηγού, είχαμε κάνει μια αλλαγή στο αρχείο /etc/inittab για να επιτρέψουμε στη MySQL να ξεκινά αυτόματα μετά από μια κατάρρευση. Προσθέσαμε την ακόλουθη γραμμή για να ενεργοποιήσουμε αυτήν τη συμπεριφορά:
|
1 |
ms:2345:respawn:/bin/sh /usr/bin/mysqld_safe |
Μπορούμε να ελέγξουμε αυτήν τη συμπεριφορά κάνοντας μερικές δοκιμές. Αρχικά, επανεκκινήστε το VPS σας εισάγοντας την ακόλουθη εντολή:
|
1 |
sudo reboot |
Μετά την επανεκκίνηση, ελέγξτε με ποια αναγνωριστικά διεργασίας (process IDs) εκτελούνται τα mysql_safe και mysqld, εισάγοντας την ακόλουθη εντολή για να λάβετε τα αναγνωριστικά διεργασίας:
|
1 |
ps -ef | grep mysql |
Το αποτέλεσμα που λάβαμε ήταν:
|
1 2 |
hackins 1836 1 0 07:30 ? 00:00:00 /bin/sh /usr/bin/mysqld_safe mysql 186338 907 0 07:30 ? 00:00:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --port=3306 |
Σημειώστε τα ID των διεργασιών. Στη δική μας περίπτωση, ήταν 1836 και 186338. Τώρα, προσομοιώστε μια κατάρρευση τερματίζοντας τη διεργασία με τον διακόπτη -9, εισάγοντας την ακόλουθη εντολή. Θυμηθείτε να αντικαταστήσετε με τα δικά σας ID διεργασιών:
|
1 2 |
sudo kill -9 1836 sudo kill -9 186338 |
Μετά από λίγα λεπτά, ελέγξτε την κατάσταση της MySQL εκτελώντας την ακόλουθη εντολή:
|
1 |
sudo service mysql status |
Το αποτέλεσμα δείχνει ότι η MySQL εκτελείται, πράγμα που σημαίνει ότι επανεκκινήθηκε μετά την προσομοιωμένη κατάρρευση. Εάν εκτελέσετε την ps -ef | grep mysql εντολή ξανά, θα διαπιστώσετε ότι και οι δύο mysqld_safe και mysqld διεργασίες εκτελούνται, αν και με νέα ID.
Μπορείτε να δοκιμάσετε να τερματίσετε τις διεργασίες πολλές φορές και θα επανεκκινηθούν μετά από λίγα λεπτά. Αυτή η συμπεριφορά είναι εφικτή χάρη στη γραμμή που προσθέσαμε στο αρχείο /etc/inittab . Με αυτόν τον τρόπο ρυθμίζετε τις υπηρεσίες ώστε να επανεκκινούνται αυτόματα μετά από μια κατάρρευση στο System V. Για να δείτε ξανά τη σύνταξη, ρίξτε μια ματιά στο Μέρος 1 αυτού του οδηγού.
Ορισμένες προσαρμοσμένες υπηρεσίες ενδέχεται να έχουν σφάλματα και να αποτυγχάνουν να επανεκκινηθούν μετά από πολλαπλές προσπάθειες. Ο δαίμονας init θα προσπαθήσει να επανεκκινήσει μια υπηρεσία, αλλά εάν αποτύχει περισσότερες από δέκα φορές μέσα σε δύο λεπτά, το σύστημα Linux απενεργοποιεί την υπηρεσία για έως και 5 λεπτά. Αυτό βοηθά στη διατήρηση της σταθερότητας του συστήματος και διασφαλίζει ότι οι πόροι του συστήματος δεν σπαταλούνται σε υπηρεσίες που καταρρέουν. Είναι καλή ιδέα να ελέγχετε τα αρχεία καταγραφής του συστήματός σας για να εντοπίσετε προβλήματα με τις προσαρμοσμένες εφαρμογές σας που πρέπει να διορθωθούν.
Εισαγωγή στο Upstart
Το σύστημα init System V υπήρξε κρίσιμο για τις διανομές Linux για μεγάλο χρονικό διάστημα. Ωστόσο, όπως συμβαίνει με την τεχνολογία, συνεχίζει να εξελίσσεται. Το οικοσύστημα του Linux αναπτύχθηκε τρομερά χάρη στην υποστήριξη από την κοινότητα ανοιχτού κώδικα. Το System V φορτώνει εργασίες και υπηρεσίες με σειριακό τρόπο, γεγονός που προκαλεί πολυπλοκότητα και καταναλώνει χρόνο. Επιπλέον, η εισαγωγή σύγχρονων αφαιρούμενων μέσων αποθήκευσης, για τα οποία το System V δεν είχε σχεδιαστεί, οδήγησε στην ανάγκη για ένα διαφορετικό σύστημα init.
Οι προγραμματιστές του Ubuntu άρχισαν να εργάζονται πάνω σε ένα άλλο σύστημα προετοιμασίας. Αυτό το σύστημα init σχεδιάστηκε για να χειρίζεται ταχύτερη φόρτωση του λειτουργικού συστήματος, να εξασφαλίζει ομαλό καθαρισμό των υπηρεσιών που κατέρρευσαν, να διατηρεί προβλέψιμη την εξάρτηση μεταξύ των υπηρεσιών του συστήματος και να λαμβάνει υπόψη τα αφαιρούμενα μέσα αποθήκευσης. Έτσι γεννήθηκε ο δαίμονας Upstart.
Το Upstart init έχει αρκετά πλεονεκτήματα έναντι του System V init με τους ακόλουθους τρόπους:
- Το Upstart δεν φορτώνει τις υπηρεσίες σειριακά όπως το System V, μειώνοντας έτσι τον χρόνο εκκίνησης του συστήματος.
- Είναι σχεδιασμένο να χειρίζεται καλύτερα τις υπηρεσίες που έχουν καταρρεύσει, με ομαλό καθαρισμό και επανεκκίνηση της υπηρεσίας.
- Το Upstart χρησιμοποιεί ένα ευέλικτο σύστημα συμβάντων για την προσαρμογή του χειρισμού των υπηρεσιών σε διάφορες καταστάσεις.
- Το init αποφεύγει τα πολύπλοκα σενάρια κελύφους για τη φόρτωση και τη διαχείριση υπηρεσιών όπως στο System V. Το Upstart χρησιμοποιεί απλά αρχεία ρυθμίσεων που είναι εύκολο να κατανοηθούν και να τροποποιηθούν.
- Το Upstart κατασκευάστηκε με γνώμονα τη συμβατότητα προς τα πίσω. Το σενάριο /etc/init.d/rc εξακολουθεί να εκτελείται για τη διαχείριση των εγγενών υπηρεσιών του System V.
- Αποφεύγει τη διατήρηση περιττών συμβολικών συνδέσμων, που όλοι δείχνουν στο ίδιο σενάριο.
Συμβάντα Upstart
Το Upstart βασίζεται σε συμβάντα, επιτρέποντας τη συσχέτιση πολλαπλών συμβάντων με την ίδια υπηρεσία. Αυτή η αρχιτεκτονική που βασίζεται σε συμβάντα εξασφαλίζει ευέλικτη διαχείριση υπηρεσιών. Κάθε συμβάν μπορεί να καλέσει ένα σενάριο κελύφους ειδικό για το συγκεκριμένο συμβάν.
Τα συμβάντα του Upstart περιλαμβάνουν:
- Starting
- Started
- Stopping
- Stopped
Μεταξύ ενός συμβάντος, μια υπηρεσία μπορεί να βρίσκεται σε διάφορες καταστάσεις, συμπεριλαμβανομένων ενδεικτικά των εξής:
- Waiting
- Pre-start
- Starting
- Post-start
- Running
- Pre-stop
- Stopping
- Post-stop
Το Upstart init μπορεί να ρυθμιστεί ώστε να αναλαμβάνει ενέργειες για καθεμία από αυτές τις καταστάσεις, εξού και ο ευέλικτος σχεδιασμός του.
Ακολουθία εκκίνησης του Upstart Init
Το Upstart init εκτελεί το σενάριο /etc/init.d/rc κατά την εκκίνηση, ακριβώς όπως το System V. Αυτό το σενάριο εκτελεί κανονικά οποιαδήποτε σενάρια init του System V για να εξασφαλίσει τη συμβατότητα προς τα πίσω.
Τα αρχεία ρυθμίσεων του Upstart βρίσκονται στον κατάλογο /etc/init , επομένως αναζητά εκεί από προεπιλογή και εκτελεί τις εντολές κελύφους που βρίσκονται στα αρχεία ρυθμίσεων κάτω από αυτόν τον κατάλογο.
Αρχεία ρυθμίσεων Upstart
Το Upstart init χρησιμοποιεί αρχεία ρυθμίσεων υπηρεσιών για τον έλεγχο των υπηρεσιών, σε αντίθεση με τα σενάρια bash που χρησιμοποιούνται στο System V. Το πρότυπο ονομασίας για αυτά τα αρχεία ρυθμίσεων υπηρεσιών είναι service_name.conf.
Τα αρχεία περιέχουν περιεχόμενο απλού κειμένου χωρισμένο σε διάφορες ενότητες που ονομάζονται stanzas. Κάθε stanza περιγράφει μια διαφορετική κατάσταση μιας υπηρεσίας και τη συμπεριφορά της. Διαφορετικά stanzas ελέγχουν διαφορετικά συμβάντα μιας υπηρεσίας. Για παράδειγμα, waiting, pre-start, start, pre-stop, stopping, κ.λπ.
Ένα stanza περιέχει εντολές shell, καθιστώντας δυνατή την έναρξη αρκετών ενεργειών για κάθε συμβάν για κάθε υπηρεσία. Επιπλέον, κάθε αρχείο ρυθμίσεων υπηρεσίας καθορίζει τα ακόλουθα δύο πράγματα:
- Σε ποια runlevels πρέπει να ξεκινά και να σταματά η υπηρεσία.
- Εάν η υπηρεσία πρέπει να κάνει respawn σε περίπτωση κατάρρευσης.
Δομή καταλόγου Upstart
Τα αρχεία ρυθμίσεων υπηρεσιών του Upstart βρίσκονται κάτω από τον κατάλογο /etc/init . Μην το συγχέετε αυτό με το /etc/init.d.
Παράδειγμα Upstart
Σε αυτό το παράδειγμα, θα δούμε πώς το Upstart χειρίζεται μια υπηρεσία κατά την εκκίνηση του συστήματος και σε περίπτωση κατάρρευσης. Θα μπούμε σε περισσότερες λεπτομέρειες εξηγώντας τα πρακτικά παραδείγματα που παρουσιάστηκαν στο πρώτο μέρος αυτού του οδηγού.
Βήμα 1: Συνδεθείτε στον διακομιστή Ubuntu 14.0.4
Αρχικά, για τη δοκιμή του Upstart, θα χρησιμοποιήσουμε τον δεύτερο VPS, αυτόν που τρέχει Ubuntu 14.0.4. Αυτό συμβαίνει επειδή αυτή η διανομή Linux εφαρμόζει το Upstart εγγενώς. Χρησιμοποιήστε ssh ή putty εάν είστε σε Windows. Πρέπει να συνδεθείτε με έναν χρήστη με δικαιώματα root ή sudo. Έχω έναν χρήστη που ονομάζεται hackins, οπότε έτσι θα συνδεόμουν:
|
1 |
ssh hackins@my_server_ip |
Αντικαταστήστε με τον root/sudo χρήστη σας και τη δημόσια διεύθυνση IP του διακομιστή σας. Στη συνέχεια, πατήστε enter και πληκτρολογήστε τον κωδικό πρόσβασης ή τη φράση πρόσβασης.
Βήμα 2: Εξετάστε τον κατάλογο init και rc
Τα αρχεία ρυθμίσεων του Upstart αποθηκεύονται στον κατάλογο /etc/init. Είναι ο κατάλογος που θα χρησιμοποιήσετε κατά τη δημιουργία νέων αρχείων ρυθμίσεων υπηρεσιών.
Για να δείτε τη λίστα με τα ονόματα των αρχείων ρυθμίσεων στον κατάλογο /etc/init, εκτελέστε την ακόλουθη εντολή:
|
1 |
sudo ls -l /etc/init/ | less |
Όπως θα δείτε από το αποτέλεσμα της παραπάνω εντολής, πολλές υπηρεσίες εκτελούνται υπό το Upstart. Πατήστε Q για έξοδο από το less.
Εάν εκτελέσετε το ακόλουθο για να δείτε τη λίστα με τα αρχεία ρυθμίσεων υπηρεσιών για το System V στον κατάλογο rc, θα δείτε μόνο μερικά:
|
1 |
sudo ls -l /etc/rc3.d/* | less |
Βήμα 3: Εξετάστε ένα αρχείο Upstart
Στο πρώτο μέρος αυτού του οδηγού, είχαμε χρησιμοποιήσει ένα αρχείο mysql.conf για να μάθουμε για τη ρύθμιση παραμέτρων του διακομιστή. Για να εμπλουτίσουμε τις γνώσεις μας, ας χρησιμοποιήσουμε μια διαφορετική ρύθμιση. Το αρχείο ρυθμίσεων cron είναι ένας καλός υποψήφιος. Εισαγάγετε την ακόλουθη εντολή για να ανοίξετε το αρχείο:
|
1 |
sudo nano /etc/init/cron.conf |
Θα πρέπει να λάβετε ένα αποτέλεσμα παρόμοιο με το παρακάτω στιγμιότυπο οθόνης:

Το σενάριο είναι αρκετά απλό. Σημειώστε τα ακόλουθα σημαντικά πεδία: start on, stop on, fork, και respawn. Ας ορίσουμε τι κάνουν αυτές οι οδηγίες:
- start on δίνει εντολή στο Ubuntu να ξεκινήσει τον daemon cron όταν το σύστημα εισέρχεται στα runlevels 2,3,4 ή 5. Δεν θα εκτελείται στα άλλα runlevels που δεν καθορίζονται εδώ, δηλαδή στα 0,1 ή 6.
- stop on δίνει εντολή στο Ubuntu να σταματήσει έναν εκτελούμενο daemon. Ωστόσο, σε αυτήν την περίπτωση, υπάρχει ένα θαυμαστικό (!) το οποίο είναι σύμβολο άρνησης. Το σενάριο δεν πρέπει να σταματά στα runlevels μετά το θαυμαστικό: 2,3,4,5.
- fork η οδηγία δίνει εντολή στο Upstart να αποσυνδέσει τη διεργασία από την κονσόλα και να τη διατηρήσει σε εκτέλεση στο παρασκήνιο.
- respawn η οδηγία δίνει εντολή στο σύστημα να ξεκινήσει το cron αυτόματα εάν καταρρεύσει για οποιονδήποτε λόγο.
Πατήστε Ctrl X για έξοδο από τον επεξεργαστή χωρίς να πληκτρολογήσετε τίποτα.
Άλλα αρχεία ρυθμίσεων του upstart ακολουθούν την ίδια δομή, με stanzas για start, stop και respawn. Ορισμένα αρχεία ρυθμίσεων ενδέχεται να έχουν πρόσθετα μπλοκ σεναρίων για pre-start, pre-stop, post-start και άλλα. Αυτά τα μπλοκ κώδικα λένε στο σύστημα τι να εκτελέσει όταν μια διεργασία βρίσκεται σε οποιαδήποτε από τις καθορισμένες καταστάσεις.
Βήμα 4: Δοκιμή της συμπεριφοράς εκκίνησης της υπηρεσίας MySQL μετά την εκκίνηση του συστήματος
Το MySQL είναι από προεπιλογή ρυθμισμένο να εκκινεί αυτόματα μετά την εκκίνηση του συστήματος. Θα προσπαθήσουμε να το απενεργοποιήσουμε και να δούμε τη συμπεριφορά. Στο Upstart, μια υπηρεσία μπορεί να απενεργοποιηθεί δημιουργώντας ένα αρχείο με όνομα service_name.override κάτω από τον κατάλογο /etc/init/. Το περιεχόμενο του αρχείου είναι μόνο μία λέξη: manual.
Ας δούμε πώς μπορούμε να χρησιμοποιήσουμε αυτήν την εντολή για να απενεργοποιήσουμε την υπηρεσία MySQL. Εισαγάγετε την ακόλουθη εντολή για να ανοίξετε το αρχείο με τον επεξεργαστή nano:
|
1 |
sudo nano /etc/init/mysql.override |
Στο αρχείο που ανοίξατε προσθέστε την ακόλουθη γραμμή:
|
1 |
Manual |
Αποθηκεύστε τις αλλαγές πατώντας Ctrl + O, και μετά enter. Βγείτε από τον επεξεργαστή πατώντας Ctrl + X. Εκτελέστε την ακόλουθη εντολή για να επανεκκινήσετε τον διακομιστή:
|
1 |
sudo reboot |
Περιμένετε μερικά λεπτά και μετά συνδεθείτε ξανά. Μόλις συνδεθείτε ξανά, ελέγξτε την κατάσταση της υπηρεσίας MySQL εισάγοντας την ακόλουθη εντολή:
|
1 |
sudo initctl status mysql |
Το αποτέλεσμα θα υποδεικνύει ότι η υπηρεσία δεν εκτελείται:
|
1 |
mysql stop/waiting |
Αυτό υποδεικνύει ότι το MySQL δεν ξεκίνησε αυτόματα μετά την εκκίνηση του συστήματος. Στη συνέχεια, ανοίξτε το αρχείο ρυθμίσεων του MySQL και ελέγξτε αν η οδηγία start έχει αλλάξει:
|
1 |
sudo cat /etc/init/mysql.conf | grep start\ on |
Το αποτέλεσμα θα υποδεικνύει ότι τίποτα δεν άλλαξε:
|
1 |
start on runlevel [2345] |
Αυτό σημαίνει ότι εάν η υπηρεσία σας δεν εκκινεί αυτόματα, και ελέγξετε μόνο το αρχείο ρυθμίσεων της υπηρεσίας (service_name.conf), ενδέχεται να μην βρείτε το σφάλμα. Θα πρέπει επίσης να ελέγξετε την ύπαρξη του αρχείου service_name.override στον κατάλογο.
Εισαγάγετε την ακόλουθη εντολή για να διαγράψετε το αρχείο override και να ενεργοποιήσετε ξανά την υπηρεσία MySQL. Στη συνέχεια, επανεκκινήστε τον διακομιστή:
|
1 2 |
sudo rm -f /etc/init/mysql.override sudo reboot |
Μόλις εκκινήσει ο διακομιστής, ελέγξτε ξανά την κατάσταση της υπηρεσίας MySQL:
|
1 |
sudo initctl status mysql |
Θα πρέπει να δείξει ότι η υπηρεσία MySQL ξεκίνησε αυτόματα.
Βήμα 5: Δοκιμή της συμπεριφοράς εκκίνησης της υπηρεσίας MySQL μετά από κατάρρευση του συστήματος
Από προεπιλογή, η υπηρεσία MySQL επανεκκινείται αυτόματα εάν καταρρεύσει. Για να σταματήσουμε αυτήν τη συμπεριφορά, θα επεξεργαστούμε το αρχείο mysql.conf . Εισαγάγετε την ακόλουθη εντολή για να ανοίξετε το αρχείο με τον επεξεργαστή nano:
|
1 |
sudo nano /etc/init/mysql.conf |
Βρείτε τις γραμμές της οδηγίας respawn και μετατρέψτε τις σε σχόλια όπως φαίνεται παρακάτω με #:
|
1 2 |
# respawn # respawn limit 2 5 |
Εκτελέστε τις ακόλουθες εντολές για να επανεκκινήσετε την υπηρεσία:
|
1 2 |
sudo initctl stop mysql sudo initctl start mysql |
Χρησιμοποιήσαμε τις παραπάνω εντολές για να σταματήσουμε και να ξεκινήσουμε την υπηρεσία επειδή η χρήση του initctl restart ή του initctl reload δεν θα λειτουργούσε εδώ. Όταν εκτελείτε την εντολή για την εκκίνηση της υπηρεσίας MySQL, το αποτέλεσμα θα εμφανίσει ένα PID για το MySQL όπως:
|
1 |
mysql start/running, process 1439 |
Το δικό μας PID ήταν 1439. Στη συνέχεια, σημειώστε τι λάβατε όταν εκτελέσατε την εντολή, θα το χρησιμοποιήσουμε στο επόμενο βήμα. Για να προσομοιώσετε μια κατάρρευση, τερματίστε τη διεργασία MySQL χρησιμοποιώντας την ακόλουθη εντολή, θυμηθείτε να αντικαταστήσετε το PID σας όπως εξηγήθηκε παραπάνω:
|
1 |
sudo kill -9 1439 |
Για να ελέγξετε αν το MySQL επανεκκινήθηκε μετά την κατάρρευση, περιμένετε μερικά λεπτά και μετά εισαγάγετε την ακόλουθη εντολή:
|
1 |
sudo initctl status mysql |
Το αποτέλεσμα θα υποδεικνύει ότι το MySQL έχει σταματήσει:
|
1 |
mysql stop/waiting |
Δοκιμάστε να ελέγξετε την κατάσταση μερικές ακόμη φορές για να δείτε αν υπάρχει κάποια αλλαγή. Θα παρατηρήσετε ότι το MySQL παραμένει σταματημένο. Αυτό συμβαίνει επειδή το αρχείο ρυθμίσεων της υπηρεσίας δεν έχει τις οδηγίες respawn (αυτές που μετατρέψαμε σε σχόλια). Δείτε το μέρος 1 αυτού του οδηγού για περισσότερες εξηγήσεις σχετικά με την οδηγία respawn.
Γιατί σας δείξαμε πώς να απενεργοποιείτε την αυτόματη επανεκκίνηση για υπηρεσίες μετά την εκκίνηση ή την κατάρρευση του συστήματος; Αυτό γίνεται κυρίως για σκοπούς αντιμετώπισης προβλημάτων. Εάν για παράδειγμα, η υπηρεσία σας ξεκινά και συνεχίζει να καταρρέει, ίσως θέλετε να την απενεργοποιήσετε ώστε να μπορέσετε να αντιμετωπίσετε το πρόβλημα, καθώς και να διατηρήσετε το σύστημά σας σταθερό. Μπορείτε επίσης να αποτρέψετε την αυτόματη επανεκκίνηση ορισμένων παλιών ρυθμίσεων υπηρεσιών εάν τύχει να αναβαθμίσετε σε μια νέα διανομή Linux που συνοδεύεται εγγενώς με systemd που συζητείται στην επόμενη ενότητα.
Εισαγωγή στο Systemd
Systemd είναι το πιο πρόσφατο σύστημα init, το οποίο συναντάται στις πιο πρόσφατες διανομές Linux. Περιλαμβάνει πολλά στοιχεία που συνθέτουν ένα σύγχρονο σύστημα Linux.
Systemd διαχειρίζεται όχι μόνο τις υπηρεσίες αλλά και ολόκληρο το σύστημα Linux. Σε αυτήν την ενότητα, θα εστιάσουμε στο πώς το systemd ελέγχει τη συμπεριφορά των υπηρεσιών μετά από μια εκκίνηση ή κατάρρευση του συστήματος.
Το Systemd είναι συμβατό προς τα πίσω με τα σενάρια init και τις εντολές του System V. Επομένως, εάν έχετε υπηρεσίες ρυθμισμένες για το System V, θα εκτελούνται επίσης υπό το Systemd. Οι περισσότερες εντολές διαχείρισης του Upstart και του System V έχουν τροποποιηθεί για να λειτουργούν με το Systemd. Το Systemd μετονομάζεται σε init κατά τον χρόνο εκκίνησης. Ένα /sbin/init αρχείο υπάρχει που συνδέεται συμβολικά με το /bin/systemd.
Αρχεία Ρύθμισης Systemd: Αρχεία Unit
Η ρύθμιση του Systemd αποτελείται από αρχεία unit. Κάθε αρχείο unit αντιπροσωπεύει έναν πόρο του συστήματος. Ενώ τα άλλα δύο συστήματα init (δηλ. το System V και το Upstart) ήταν υπεύθυνα για τη διαχείριση των υπηρεσιών ενός συστήματος Linux, το Systemd όχι μόνο διαχειρίζεται τους δαίμονες υπηρεσιών (service daemons), αλλά και άλλους τύπους πόρων του συστήματος, όπως διαδρομές λειτουργικού συστήματος συσκευών, υποδοχές (sockets), σημεία προσάρτησης (mount points) κ.λπ. Τα αρχεία unit αποθηκεύουν πληροφορίες σχετικά με τον πόρο.
Κάθε αρχείο unit αντιπροσωπεύει έναν συγκεκριμένο πόρο συστήματος με στυλ ονομασίας service_name.unit_type. Αυτό σημαίνει ότι θα βρείτε αρχεία όπως home.mount, dbus.service, sshd.socket, κ.λπ. Τα αρχεία unit είναι απλά αρχεία κειμένου με δηλωτική σύνταξη που είναι εύκολο να κατανοηθεί και να τροποποιηθεί.
Δομή Καταλόγων
Η κύρια τοποθεσία των εγγενών αρχείων unit είναι ο κατάλογος /lib/systemd/system/. Τα αρχεία unit που δημιουργείτε εσείς ή εκείνα που δημιουργούνται προσαρμοσμένα από τους διαχειριστές συστήματος, καθώς και άλλα τροποποιημένα εγγενή αρχεία unit, αποθηκεύονται στον κατάλογο /etc/systemd/system.
Εάν ένα αρχείο unit με το ίδιο όνομα υπάρχει τόσο στον κατάλογο /lib/systemd/system/ όσο και στον /etc/systemd/system, το systemd θα χρησιμοποιήσει αυτόν που βρίσκεται κάτω από τον κατάλογο /etc.
Όταν ενεργοποιείτε μια υπηρεσία για να ξεκινά κατά τον χρόνο εκκίνησης ή σε οποιοδήποτε άλλο target/runlevel, δημιουργείται ένας συμβολικός σύνδεσμος για αυτό το αρχείο unit της υπηρεσίας κάτω από τους κατάλληλους καταλόγους στο /etc/systemd/system. Τα αρχεία unit στον κατάλογο /etc/systemd/system είναι απλώς συμβολικοί σύνδεσμοι προς τα αρχεία με παρόμοιο όνομα στον κατάλογο /lib/systemd/system.
Ακολουθία Εκκίνησης Systemd: Target Units
Τα target units είναι μοναδικοί τύποι αρχείων unit που συνήθως έχουν την κατάληξη .target. Τα target units διαφέρουν από άλλους τύπους αρχείων unit επειδή δεν αντιπροσωπεύουν έναν συγκεκριμένο πόρο. Αντίθετα, αντιπροσωπεύουν την κατάσταση ολόκληρου του συστήματος σε μια δεδομένη στιγμή.
Για να το επιτύχουν αυτό, τα target units ομαδοποιούν και εκκινούν πολλαπλά αρχεία unit που αποτελούν μέρος μιας συγκεκριμένης κατάστασης. Αν και τα targets του Systemd και τα runlevels του System V μπορούν να συγκριθούν χαλαρά, δεν είναι τα ίδια. Ένα αρχείο target unit έχει όνομα αντί για αριθμό. Για παράδειγμα, θα βρείτε κάτι όπως multi-user.target αντί για runlevel 3 ή reboot.target αντί για runlevel 6. Ένα σύστημα Linux μπορεί να εκκινήσει με multi-user.target. Σε αυτήν την περίπτωση, ουσιαστικά φέρνει τον διακομιστή στο runlevel 2, 3 ή 4, το οποίο εκκινεί το σύστημα σε λειτουργία κειμένου πολλαπλών χρηστών με ενεργοποιημένο το δίκτυο.
Η διαφορά έγκειται στο πώς φέρνει τον διακομιστή σε αυτό το επίπεδο. Το System V εκκινεί τις υπηρεσίες διαδοχικά. Από την άλλη πλευρά, καθώς ένα σύστημα εκκινεί, το systemd ελέγχει εάν υπάρχουν άλλες υπηρεσίες ή πόροι και καθορίζει τη σειρά φόρτωσής τους.
Μια άλλη διαφορά μεταξύ των μονάδων target του systemd και των runlevels του System V είναι ότι μια διανομή Linux που χρησιμοποιεί το System V θα υπάρχει σε ένα μόνο runlevel. Εάν τροποποιήσετε το runlevel, απλά θα μεταβεί και θα υπάρχει σε αυτό το νέο runlevel. Από την άλλη πλευρά, τα αρχεία target unit μπορούν να είναι συμπεριληπτικά. Επιπλέον, η ενεργοποίηση μιας μονάδας target διασφαλίζει ότι άλλες μονάδες target φορτώνονται ως μέρος της. Για παράδειγμα, εάν εκκινήσετε ένα σύστημα Linux με γραφικό περιβάλλον εργασίας, θα έχει το graphical.target ενεργοποιημένο. Αυτό με τη σειρά του διασφαλίζει αυτόματα ότι το multi-user.target φορτώνεται και ενεργοποιείται επίσης.
Ακολουθεί ένας πίνακας που συγκρίνει τα runlevels και τα targets.
| Runlevel (System V) | Target Units (systemd) |
| runlevel 0 | poweroff.target |
| runlevel 1 | rescue.target |
| runlevel 2,3,4 | multi-user.target |
| runlevel 5 | graphical.target |
| runlevel 6 | reboot.target |
Systemd default.target
Στο systemd, το default.target είναι το αντίστοιχο του προεπιλεγμένου runlevel στο System V. Είδαμε ότι το προεπιλεγμένο runlevel στο System V οριζόταν στο αρχείο inittab. Στο systemd, έχουμε το αρχείο default.target. Το προεπιλεγμένο αρχείο target αποθηκεύεται στον κατάλογο /etc/systemd/system. Συνδέεται συμβολικά (symlink) με ένα από τα αρχεία target unit κάτω από το /lib/systemd/system. Η αλλαγή του προεπιλεγμένου target σημαίνει απλώς τη δημιουργία εκ νέου ενός συμβολικού συνδέσμου και την τροποποίηση του runlevel του συστήματος.
Στο System V, το inittab καθόριζε σε ποιον κατάλογο το Linux θα έβρισκε τα σενάρια init. Αυτός θα μπορούσε να είναι οποιοσδήποτε από τους καταλόγους rc όπως εξηγήθηκε προηγουμένως. Από την άλλη πλευρά, το προεπιλεγμένο target του systemd καθορίζει τις μονάδες πόρων (resource units) που θα φορτωθούν κατά την εκκίνηση. Όλες οι καθορισμένες μονάδες φορτώνονται. Ωστόσο, δεν φορτώνονται όλες παράλληλα, ούτε όλες διαδοχικά. Η φόρτωση της μονάδας πόρου εξαρτάται από τους άλλους πόρους που θέλει (wants) ή απαιτεί (requires).
Εξαρτήσεις Systemd: Wants και Requires
Σε αυτήν την ενότητα, θα συζητήσουμε πώς το Systemd χειρίζεται τις εξαρτήσεις. Είδαμε ότι με το Upstart, η παράλληλη φόρτωση υπηρεσιών είναι δυνατή κατά τη χρήση αρχείων ρυθμίσεων. Συζητήσαμε επίσης πώς το System V χρησιμοποιεί τα runlevels για να καθορίσει ποια υπηρεσία θα ξεκινήσει αυτόματα ή θα περιμένει μέχρι να εμφανιστεί μια άλλη υπηρεσία ή πόρος. Ομοίως, οι υπηρεσίες του Systemd μπορούν να ρυθμιστούν ώστε να φορτώνονται σε ένα ή περισσότερα targets ή να περιμένουν μέχρι να εμφανιστεί μια άλλη υπηρεσία ή πόρος.
Στο Systemd, ένα αρχείο μονάδας (unit file) που απαιτεί (requires) μια άλλη μονάδα δεν θα ξεκινήσει μέχρι η απαιτούμενη μονάδα να φορτωθεί και να ενεργοποιηθεί. Εάν η απαιτούμενη μονάδα αποτύχει να φορτωθεί ενώ η πρώτη μονάδα είναι ενεργή, η πρώτη μονάδα θα σταματήσει.
Αυτή η συμπεριφορά διασφαλίζει τη σταθερότητα του συστήματος. Μια υπηρεσία που απαιτεί (requires) έναν συγκεκριμένο πόρο (για παράδειγμα, μια θύρα) να είναι διαθέσιμος και ενεργός, μπορεί έτσι να τεθεί σε αναμονή μέχρι ο πόρος να είναι διαθέσιμος (δηλαδή να ανοίξει η θύρα).
Αντίθετα, μια μονάδα που θέλει (wants) μια άλλη μονάδα δεν επιβάλλει τέτοιους περιορισμούς. Δεν θα σταματήσει εάν η επιθυμητή μονάδα σταματήσει ενώ η καλούσα μονάδα είναι ακόμα ενεργή. Για παράδειγμα, ορισμένες μη απαραίτητες υπηρεσίες στη λειτουργία graphical-target.
Παράδειγμα Systemd
Ας δούμε πώς μπορούμε να διαμορφώσουμε τη συμπεριφορά μιας υπηρεσίας στο systemd.
Βήμα 1: Συνδεθείτε στο VPS instance σας
Θα χρησιμοποιήσουμε τη MySQL ως μια πραγματική υπηρεσία και το CentOS 7 ως διακομιστή. Για να ακολουθήσετε τα βήματα στην πράξη και να κατανοήσετε τις έννοιες, συνδεθείτε στο CentOS 7 VPS σας ή δημιουργήστε ένα στο CloudSigma. Ένα VPS που εκτελεί διανομή CentOS 7, Debian 7 ή 8, ή Ubuntu 15 ή νεότερη είναι κατάλληλο για αυτήν την ενότητα, καθώς όλα διαθέτουν systemd. Συνδεθείτε χρησιμοποιώντας την εντολή ssh ή εάν είστε σε Windows, χρησιμοποιήστε το PuTTY:
|
1 |
ssh hackins@your_server_ip |
Βήμα 2: Εξετάστε το αρχείο default.target και τις εξαρτήσεις
Η ακολουθία εκκίνησης του Systemd ακολουθεί μια μακρά αλυσίδα εξαρτήσεων, την οποία θα συζητήσουμε λεπτομερώς σε αυτήν την ενότητα.
- default.target
Το αρχείο default.target ελέγχει τις υπηρεσίες που ξεκινούν κατά τη διάρκεια μιας κανονικής εκκίνησης. Μπορείτε να εμφανίσετε το προεπιλεγμένο αρχείο target unit χρησιμοποιώντας την ακόλουθη εντολή:
|
1 |
sudo ls -l /etc/systemd/system/default.target |
Το αποτέλεσμα δείχνει κάτι σαν το παρακάτω στιγμιότυπο οθόνης:
![]()
Το στιγμιότυπο οθόνης δείχνει ότι το default target συνδέεται συμβολικά (symlink) με το αρχείο multi-user.target στο /lib/systemd/system/ κατάλογο. Αυτό σημαίνει ότι, από προεπιλογή, το σύστημα θα εκκινήσει υπό το multi-user.target, ισοδύναμο με runlevel 3.
- multi-user.target.wants
Για να δείτε όλες τις υπηρεσίες που απαιτεί το αρχείο multi-user.target, εισαγάγετε την ακόλουθη εντολή:
|
1 |
sudo ls -l /etc/systemd/system/multi-user.target.wants/*.service |
Η έξοδος περιέχει πολλές γραμμές, ορίστε ένα απόσπασμα:
|
1 2 3 4 5 6 7 8 |
lrwxrwxrwx. 1 root root 38 Dec 25 10:32 /etc/systemd/system/multi-user.target.wants/mysqld.service -> /usr/lib/systemd/system/mysqld.service lrwxrwxrwx. 1 root root 36 Dec 16 19:10 /etc/systemd/system/multi-user.target.wants/ntpd.service -> /usr/lib/systemd/system/ntpd.service lrwxrwxrwx. 1 root root 39 Dec 16 19:08 /etc/systemd/system/multi-user.target.wants/postfix.service -> /usr/lib/systemd/system/postfix.service lrwxrwxrwx. 1 root root 46 Dec 16 19:08 /etc/systemd/system/multi-user.target.wants/rhel-configure.service -> /usr/lib/systemd/system/rhel-configure.service lrwxrwxrwx. 1 root root 39 Dec 16 19:08 /etc/systemd/system/multi-user.target.wants/rsyslog.service -> /usr/lib/systemd/system/rsyslog.service lrwxrwxrwx. 1 root root 36 Dec 16 19:08 /etc/systemd/system/multi-user.target.wants/sshd.service -> /usr/lib/systemd/system/sshd.service lrwxrwxrwx. 1 root root 37 Dec 16 19:08 /etc/systemd/system/multi-user.target.wants/tuned.service -> /usr/lib/systemd/system/tuned.service lrwxrwxrwx. 1 root root 40 Dec 16 19:14 /etc/systemd/system/multi-user.target.wants/yum-cron.service -> /usr/lib/systemd/system/yum-cron.service |
Όπως δείχνει η έξοδος, πρόκειται για συμβολικούς συνδέσμους που δείχνουν στα πραγματικά αρχεία μονάδων στον κατάλογο /lib/systemd/system/. Έχουμε επισημάνει το mysqld.service για να σας δείξουμε ότι αποτελεί επίσης μέρος του multi-user.target. Αν θέλετε να επιβεβαιώσετε εάν μια συγκεκριμένη υπηρεσία είναι ρυθμισμένη για εκκίνηση, μπορείτε να τροποποιήσετε την εντολή για αυτό το αρχείο. Για παράδειγμα, μπορούμε να φιλτράρουμε τα αποτελέσματα για να βρούμε τον δαίμονα mysql ή cron χρησιμοποιώντας τις ακόλουθες εντολές:
|
1 |
sudo systemctl show --property "Wants" multi-user.target | fmt -10 | grep mysql |
Η έξοδος θα δείξει:
|
1 |
mysqld.service |
Για να φιλτράρετε το αποτέλεσμα για τον δαίμονα cron, εισαγάγετε την ακόλουθη εντολή:
|
1 |
sudo systemctl show --property "Wants" multi-user.target | fmt -10 | grep cron |
Η έξοδος θα δείξει:
|
1 |
crond.service |
Εκτός από το multi-user.target, υπάρχουν άλλοι διαφορετικοί τύποι στόχων, δηλ. system-update.target ή basic.target.
Εισαγάγετε την ακόλουθη εντολή για να δείτε από ποιους στόχους εξαρτάται το multi-user target:
|
1 |
sudo systemctl show --property "Requires" multi-user.target | fmt -10 |
Η έξοδος δείχνει:
|
1 |
Requires=basic.target |
Αυτό σημαίνει ότι το basic-target πρέπει να φορτωθεί πρώτα για να εκκινήσει το σύστημα σε λειτουργία multi-user.target.
- basic-target
Εισαγάγετε την ακόλουθη εντολή για να δείτε ποιους άλλους στόχους απαιτεί το basic.target:
|
1 |
sudo systemctl show --property "Requires" basic.target | fmt -10 |
Το αποτέλεσμα θα δείξει:
|
1 |
Requires=sysinit.target |
- sysinit.target
Μπορείτε να εκτελέσετε την ακόλουθη εντολή για να δείτε αν υπάρχουν απαιτούμενοι στόχοι για το sysinit.target. Η σύνταξη της εντολής είναι η ίδια. Μπορείτε να συνεχίσετε να την τροποποιείτε για να δείτε ποιες μονάδες στόχου απαιτούνται από μια άλλη μονάδα στόχου στην πορεία. Ορίστε η εντολή:
|
1 |
sudo systemctl show --property "Requires" sysinit.target | fmt -10 |
Το αποτέλεσμα θα δείξει ότι δεν υπάρχουν απαιτούμενες μονάδες για το sysinit.target. Μπορούμε να ελέγξουμε αν υπάρχουν άλλες υπηρεσίες και στόχοι που ζητούνται από το sysinit.target χρησιμοποιώντας την ακόλουθη εντολή:
|
1 |
sudo systemctl show --property "Wants" sysinit.target | fmt -10 |
Το αποτέλεσμα δείχνει μια μακρά λίστα υπηρεσιών και στόχων που ζητούνται από το sysinit.target. Μέρος του αποτελέσματος μπορείτε να δείτε παρακάτω:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
Wants=systemd-tmpfiles-setup-dev.service systemd-binfmt.service systemd-journald.service rhel-loadmodules.service dev-hugepages.mount systemd-modules-load.service rhel-autorelabel-mark.service plymouth-read-write.service sys-fs-fuse-connections.mount systemd-machine-id-commit.service systemd-random-seed.service systemd-udevd.service systemd-sysctl.service plymouth-start.service rhel-autorelabel.service proc-sys-fs-binfmt_misc.automount local-fs.target rhel-import-state.service sys-kernel-config.mount dev-mqueue.mount kmod-static-nodes.service systemd-update-utmp.service |
Κατά την προετοιμασία του συστήματος με το system4, το σύστημα δεν παραμένει σε έναν μόνο στόχο. Αντίθετα, φορτώνει υπηρεσίες με εξαρτώμενο τρόπο καθώς μεταβαίνει από τον έναν στόχο στον άλλο.
Step 3: Examine a Unit File
Ας δούμε πώς μοιάζει ένα αρχείο μονάδας. Είχαμε χρησιμοποιήσει το αρχείο μονάδας της υπηρεσίας MySQL στο πρώτο μέρος αυτού του οδηγού, και θα το χρησιμοποιήσουμε ξανά. Ωστόσο, μπορούμε επίσης να δούμε ένα άλλο αρχείο μονάδας υπηρεσίας – το αρχείο μονάδας sshd. Εισαγάγετε την ακόλουθη εντολή για να ανοίξετε το αρχείο ρυθμίσεων του sshd:
|
1 |
sudo nano /etc/systemd/system/multi-user.target.wants/sshd.service |
Παρακάτω είναι ένα στιγμιότυπο οθόνης που δείχνει τις γραμμές στο αρχείο:

Όπως μπορείτε να δείτε, τα μπλοκ κώδικα που περιγράφονται στο αρχείο καθιστούν εύκολη την κατανόηση και την τροποποίησή του όποτε είναι απαραίτητο. Παρακάτω υπάρχουν μερικές σημαντικές οδηγίες που πρέπει να κατανοήσετε:
- After – η οδηγία After ορίζει στο σύστημα να φορτώσει την υπηρεσία μόνο αφού έχουν φορτωθεί οι καθορισμένοι στόχοι και υπηρεσίες. Σε αυτήν την περίπτωση, η υπηρεσία SSHD θα φορτωθεί αφού φορτωθούν ο στόχος δικτύου και η υπηρεσία keygen.
- Wants – η οδηγία Wants δείχνει ποιοι στόχοι θέλουν αυτήν την υπηρεσία. Σε αυτήν την περίπτωση το ssh-keygen.service θέλει το sshd.service. Ωστόσο, εάν το sshd αποτύχει ή καταρρεύσει, δεν θα τερματίσει τη λειτουργία του ssh-keygen.service.
Πατήστε Ctrl + X για να κλείσετε τον επεξεργαστή.
Βήμα 4: Δοκιμή της συμπεριφοράς εκκίνησης της υπηρεσίας MySQL κατά την εκκίνηση του συστήματος
Σε αυτήν την ενότητα, θα σας δείξουμε πώς μπορείτε να αλλάξετε και να δοκιμάσετε τη συμπεριφορά της υπηρεσίας MySQL κατά την εκκίνηση του συστήματος. Στην προηγούμενη ενότητα, είδαμε ότι το mysqld.service ζητείται από το multi-user.target. Επομένως, θα ξεκινήσει αυτόματα κατά την εκκίνηση.
Μπορείτε να απενεργοποιήσετε την υπηρεσία εκτελώντας την ακόλουθη εντολή:
|
1 |
sudo systemctl disable mysqld.service |
Η εκτέλεση της εντολής δείχνει ότι ο συμβολικός σύνδεσμος (symlink) της mysql αφαιρείται από τον κατάλογο /etc/systemd/system/multi-user.target.wants/ directory. Για να το δοκιμάσετε αυτό, εκτελέστε την ακόλουθη εντολή για να ελέγξετε αν η MySQL εξακολουθεί να ζητείται από το multi-user.target:
|
1 |
sudo systemctl show --ιδιότητα "Wants" multi-user.target | fmt -10 | grep mysql |
Η εντολή δεν επιστρέφει τίποτα. Εάν προσπαθήσετε να επανεκκινήσετε τον διακομιστή και ελέγξετε την κατάσταση της MySQL, δεν θα εκτελείται, πράγμα που σημαίνει ότι δεν ξεκίνησε αυτόματα κατά την εκκίνηση.
Τώρα ενεργοποιήστε ξανά την υπηρεσία χρησιμοποιώντας την εντολή:
|
1 |
sudo systemctl enable mysqld.service |
Το αποτέλεσμα θα εμφανίσει έναν συμβολικό σύνδεσμο (symlink). Εάν επανεκκινήσετε τον διακομιστή σας, η MySQL θα πρέπει να ξεκινήσει αυτόματα. Η ενεργοποίηση μιας υπηρεσίας Systemd δημιουργεί έναν συμβολικό σύνδεσμο στον κατάλογο wants του προεπιλεγμένου target. Η απενεργοποίηση μιας υπηρεσίας Systemd αφαιρεί τον συμβολικό σύνδεσμο από τον κατάλογο wants κατάλογο.
Βήμα 5: Δοκιμή της συμπεριφοράς εκκίνησης της υπηρεσίας MySQL μετά από κατάρρευση της υπηρεσίας
Από προεπιλογή, η υπηρεσία MySQL θα ξεκινήσει αυτόματα σε περίπτωση κατάρρευσης. Μπορούμε να απενεργοποιήσουμε αυτήν τη συμπεριφορά στο αρχείο ρυθμίσεων Systemd για τη MySQL. Αρχικά, ας ρίξουμε μια ματιά στο αρχείο. Εισαγάγετε την ακόλουθη εντολή για να ανοίξετε το αρχείο:
|
1 |
sudo nano /etc/systemd/system/multi-user.target.wants/mysqld.service |
Το παρακάτω στιγμιότυπο οθόνης δείχνει το αποτέλεσμα:

Η τιμή της οδηγίας Restart έχει οριστεί σε on-failure. Αυτό σημαίνει ότι η υπηρεσία MySQL θα επανεκκινηθεί μετά από μη καθαρούς κωδικούς εξόδου, χρονικό όριο (timeout) ή μη καθαρά σήματα. Παρακάτω υπάρχει ένας πίνακας που δείχνει μερικές από τις παραμέτρους επανεκκίνησης από τη σελίδα man.
| Ρυθμίσεις επανεκκίνησης/Αιτίες εξόδου | no | always | on-success | on-failure | on-abnormal | on-abort | on-watchdog |
| καθαρός κωδικός εξόδου ή σήμα | X | X | |||||
| Μη καθαρός κωδικός εξόδου | X | X | |||||
| Μη καθαρό σήμα | X | X | X | X | |||
| Χρονικό όριο (Timeout) | X | X | X | ||||
| Watchdog | X | X | X | X |
Οι δύο σημαντικές οδηγίες σε ένα αρχείο μονάδας Systemd είναι οι Restart και RestartSec. Ελέγχουν τη συμπεριφορά της υπηρεσίας σε περίπτωση κατάρρευσης. Restart καθορίζει πότε πρέπει να επανεκκινηθεί η υπηρεσία, και RestartSec καθορίζει πόσο χρόνο πρέπει να περιμένει πριν από την επανεκκίνηση μετά από μια κατάρρευση. Για να απενεργοποιήσετε τη συμπεριφορά επανεκκίνησης, σχολιάστε την οδηγία Restart προσθέτοντας ένα # στην αρχή της γραμμής, όπως φαίνεται:
|
1 |
# Restart=always |
Τώρα, επαναφορτώστε τον δαίμονα του συστήματος (system daemon) και, στη συνέχεια, επαναφορτώστε την υπηρεσία mysqld χρησιμοποιώντας τις ακόλουθες εντολές:
|
1 2 |
sudo systemctl daemon-reload sudo systemctl restart mysqld.service |
Στη συνέχεια, εκτελέστε την ακόλουθη εντολή για να βρείτε το κύριο PID (Main PID) της υπηρεσίας MySQL:
|
1 |
sudo systemctl status mysqld.service |

Το κύριο PID για τη δοκιμή μας ήταν 23809. Σημειώστε το δικό σας για να το χρησιμοποιήσετε στην επόμενη εντολή. Χρησιμοποιώντας την εντολή kill -9, προσομοιώστε μια κατάρρευση τερματίζοντας τη διεργασία. Επίσης, θυμηθείτε να αντικαταστήσετε τον αριθμό διεργασίας με αυτόν που λάβατε στη δική σας δοκιμή:
|
1 |
sudo kill -9 23809 |
Εάν εκτελέσετε την εντολή που ελέγχει την κατάσταση της MySQL, θα διαπιστώσετε ότι δεν είναι ενεργή και έχει αποτύχει να επανεκκινηθεί:
|
1 |
sudo systemctl status mysqld.service |

Θα παραμείνει σε κατάσταση αποτυχίας όσο η οδηγία Restart είναι σχολιασμένη στο αρχείο ρυθμίσεων mysqld.service. Αυτό προσομοιώνει μια κατάρρευση όπου μια υπηρεσία σταματά και δεν επανέρχεται.
Για να ενεργοποιήσετε ξανά την υπηρεσία, μπορείτε να επεξεργαστείτε το αρχείο ρυθμίσεων mysqld.service, να καταργήσετε το σχόλιο από την οδηγία Restart, και στη συνέχεια να αποθηκεύσετε και να κλείσετε το αρχείο. Όπως κάνατε νωρίτερα, επαναφορτώστε τον δαίμονα και επανεκκινήστε την υπηρεσία. Αυτό επαναφέρει την υπηρεσία στην αρχική της διαμόρφωση, και τώρα μπορεί να ξεκινήσει αυτόματα μετά από μια κατάρρευση. Τέλος, αυτά είναι όλα για τη ρύθμιση μιας υπηρεσίας ώστε να ξεκινά αυτόματα μετά από μια κατάρρευση. Εάν θέλετε να ρυθμίσετε υπηρεσίες ώστε να ξεκινούν αυτόματα μετά από μια κατάρρευση, απλά πρέπει να προσθέσετε την οδηγία Restart, (και αν το επιθυμείτε, μπορείτε επίσης να προσθέσετε την οδηγία RestartSec), κάτω από την ενότητα [Service] του αρχείου μονάδας της υπηρεσίας.
Συμπέρασμα
Σε αυτόν τον οδηγό, συζητήσαμε πώς το Linux διαχειρίζεται τις υπηρεσίες κατά την εκκίνηση ή μετά από μια κατάρρευση. Για να κατανοήσουμε τη διαδικασία προετοιμασίας του συστήματος Linux, συζητήσαμε τα τρία συστήματα init που χρησιμοποιεί το Linux: System V, Upstart και Systemd. Συζητήσαμε την εξέλιξή τους και πώς λειτουργεί κάθε διαδικασία init σε σχέση με την αυτόματη εκκίνηση μιας υπηρεσίας μετά από επανεκκίνηση του συστήματος ή κατάρρευση.
Καθώς τόσο οι init daemons όσο και οι διανομές Linux εξελίσσονται με την πάροδο του χρόνου, θυμηθείτε να ελέγξετε την έκδοση της διανομής Linux που εκτελείτε, ώστε να γνωρίζετε ποιον init daemon υποστηρίζει εγγενώς το σύστημά σας.
Οι εγγενείς εφαρμογές Linux και οι περισσότερες εφαρμογές τρίτων εκκινούν ήδη αυτόματα μετά από εκκίνηση ή κατάρρευση του συστήματος, οπότε δεν θα χρειαστεί να κάνετε τίποτα. Οι γνώσεις σε αυτόν τον οδηγό είναι εξαιρετικά σημαντικές όταν διαμορφώνετε τη συμπεριφορά εκκίνησης και επανεκκίνησης (respawn) των δικών σας προσαρμοσμένων υπηρεσιών ή κατά την αντιμετώπιση προβλημάτων με υπηρεσίες που καταρρέουν συνεχώς.
Καλή συνέχεια!
Σχόλια
Δεν υπάρχουν σχόλια ακόμα. Γράψτε το πρώτο.