Πίνακας περιεχομένων:
2025 Συγγραφέας: John Day | [email protected]. Τελευταία τροποποίηση: 2025-01-13 06:57
Το να έχετε ένα σταθερό, πάντα λειτουργικό σύστημα, ακόμη και αν χρησιμοποιείτε Linux μπορεί να είναι μια δύσκολη εργασία.
Λόγω της πολυπλοκότητας των σύγχρονων πακέτων λογισμικού και της κακής κωδικοποίησης, αναπόφευκτα ορισμένες διαδικασίες ενδέχεται να καταρρεύσουν κατά καιρούς. Αυτό θα μπορούσε να είναι κακό αν χρησιμοποιείτε διακομιστή και μερικοί άνθρωποι βασίζονται σε αυτές τις υπηρεσίες.
Βήμα 1: Χρήση μεθόδων που παρέχονται από το Systemd
Όπως ίσως γνωρίζετε ήδη, τα περισσότερα σύγχρονα λειτουργικά συστήματα Linux χρησιμοποιούν systemd.
Εάν δεν είστε εξοικειωμένοι με το systemd, αυτό είναι, σύμφωνα με τη wikipedia:
"… ένα σύστημα init που χρησιμοποιείται σε διανομές Linux για εκκίνηση του χώρου χρήστη και διαχείριση όλων των διαδικασιών στη συνέχεια, αντί των αρχικών συστημάτων UNIX System V ή Berkeley Software Distribution (BSD)."
Πολλοί άνθρωποι εξακολουθούν να αμφισβητούν γιατί ήταν απαραίτητο να αντικατασταθεί το παλιό καλό σύστημα init με αυτό το πιο περίπλοκο σύστημα διαχείρισης διαδικασιών, αλλά στον παρακάτω σύνδεσμο θα βρείτε μια καλή εξήγηση:
www.tecmint.com/systemd-replaces-init-in-l…
Η πιο σημαντική βελτίωση θα ήταν ότι είναι σε θέση να αναδείξει το σύστημα γρηγορότερα από το init, λόγω ταυτόχρονης και παράλληλης επεξεργασίας κατά την εκκίνηση αντί της διαδοχικής προσέγγισης του init
Χωρίς να μπείτε στα βαθιά του systemd, για να προσθέσετε μια διαδικασία στο systemd, πρέπει να δημιουργήσετε ένα αρχείο υπηρεσίας. Η σύνταξη ενός τέτοιου αρχείου μπορεί να κυμαίνεται από πολύ απλή έως εντελώς περίπλοκη και δεν θα μπούμε σε λεπτομέρειες. Για να έχετε ένα βασικό αρχείο.service, αρκεί να χρησιμοποιήσετε τις ακόλουθες καταχωρήσεις:
[Μονάδα] Περιγραφή = Περιγραφή εφαρμογήςDocumentation = https://wikipedia.org/ After = local-fs.target network.target [Service] Type = simpleExecStart =/usr/sbin/applicationExecReload =/usr/sbin/εφαρμογή reloadExecStop =/ usr/sbin/application stopRestart = πάντα [Install] WantedBy = multi-user.target
Τοποθετήστε αυτά στο αρχείο application.service στο φάκελο/lib/systemd/system.
Τι κάνει κάθε μία από αυτές τις επιλογές εξηγείται στον ακόλουθο σύνδεσμο:
access.redhat.com/documentation/en-US/Red_…
Για να ξεκινήσετε την εφαρμογή σας, εκδώστε την ακόλουθη εντολή:
sudo systemctl εκκίνηση εφαρμογής. υπηρεσία
Σημείωση: η επέκταση.service μπορεί να παραλειφθεί.
Για να σταματήσετε την εφαρμογή:
sudo systemctl stop application.service
Εάν το αρχείο διαμόρφωσης έχει αλλάξει και θέλετε να φορτώσετε ξανά τις ρυθμίσεις:
sudo systemctl εφαρμογή επαναφόρτωσης. υπηρεσία
Για επανεκκίνηση της εφαρμογής:
sudo systemctl επανεκκίνηση application.service
Για να ενεργοποιήσετε την αυτόματη εκκίνηση κατά την εκκίνηση:
sudo systemctl ενεργοποιήστε την εφαρμογή.service
Εάν αυτό είναι ενεργοποιημένο, τότε ο διαχειριστής διαδικασίας systemd θα προσπαθήσει να ξεκινήσει την εφαρμογή με βάση τις ρυθμίσεις που παρείχε το αρχείο συστήματος.
Για να την απενεργοποιήσετε, χρησιμοποιήστε την ίδια εντολή με την παραπάνω, αλλά με παράμετρο «απενεργοποίηση».
Εάν τοποθετήσετε το Restart = πάντα στο αρχείο υπηρεσίας, τότε το systemd θα παρακολουθεί τη διαδικασία και εάν δεν μπορεί να βρεθεί στη λίστα διεργασιών, θα προσπαθήσει να το επανεκκινήσει αυτόματα.
Αν τοποθετήσετε
RestartSec = 30
μετά την οδηγία επανεκκίνησης, θα περιμένει 30 δευτερόλεπτα προτού προσπαθήσει να επανεκκινήσει τη διαδικασία. Αυτό μπορεί να είναι χρήσιμο, καθώς μια συνεχής προσπάθεια επανεκκίνησης μιας αποτυχημένης υπηρεσίας/εφαρμογής μπορεί να οδηγήσει σε μεγάλη ζήτηση στο σύστημα (εγγραφή αρχείων καταγραφής σφαλμάτων κ.λπ.)
Όπως μπορείτε να δείτε, το systemd παρέχει ήδη κάποια μέσα για την παρακολούθηση των διαδικασιών. Ωστόσο, σε ορισμένες περιπτώσεις αυτό μπορεί να μην είναι αρκετό. Τι γίνεται αν μια διαδικασία δεν εξέλθει (θα εξακολουθεί να βρίσκεται στη λίστα διεργασιών), αλλά σταματά να ανταποκρίνεται. Σε αυτήν την περίπτωση, για να βεβαιωθείτε ότι μια διαδικασία είναι όντως σε λειτουργία, μπορεί να χρειαστείτε επιπλέον ελέγχους για να πραγματοποιήσετε.
Εδώ είναι που τα σενάρια από αυτό το διδακτικό θα είναι χρήσιμα.
Βήμα 2: Διαμόρφωση και χρήση των σεναρίων του Έλεγχου υπηρεσίας
Εάν χρειάζεστε περισσότερο έλεγχο των διαδικασιών/υπηρεσιών που εκτελείτε, αυτά τα σενάρια θα σας βοηθήσουν, σίγουρα.
Καθώς ο κώδικας είναι ελαφρώς μεγάλος, μεταφορτώθηκε στο github και μπορεί να βρεθεί στο ακόλουθο αποθετήριο:
github.com/trex2000/Service-Monitor-Scripts/blob/master/checkService.sh
Η «καρδιά» ολόκληρου του πακέτου είναι το
checkService.sh
Πριν τη χρησιμοποιήσετε, πρέπει να αντικαταστήσετε την πλήρη διαδρομή προς το φάκελο υπηρεσιών. Αυτό μπορεί να βρεθεί στην αρχή του σεναρίου.
Το σενάριο μπορεί να παρακολουθεί διάφορες διαδικασίες και να εκτελεί επιπλέον εργασίες, όπως περιγράφεται παρακάτω:
Περνάει από κάθε αρχείο από τον υποφάκελο /services που έχει επεκτάσεις.serv ή.check και ελέγχει αν υπάρχει μια ενεργή διαδικασία που ονομάζεται «εφαρμογή».
Εάν δεν υπάρχει αρχείο ".check" για μια εφαρμογή, μόνο το αρχείο application.serv:
Εάν η διαδικασία είναι ενεργή, θα θεωρήσει τη διαδικασία ως ενεργή
Εάν η διαδικασία είναι ανενεργή, τότε θα επανεκκινήσει την υπηρεσία εκδίδοντας την ακόλουθη εντολή:
εφαρμογή επανεκκίνησης systemctl
αν το αρχείο.serv είναι άδειο!
Εάν το αρχείο.serv δεν είναι κενό και έχει εκτελέσιμα δικαιώματα, θα προσπαθήσει να το εκτελέσει ως απλό σενάριο BASH.
Αυτό είναι χρήσιμο εάν πρέπει να γίνει κάτι επιπλέον εκτός από την επανεκκίνηση της υπηρεσίας.
Για παράδειγμα, στο αρχείο spamd.serv, από το repo παραπάνω, σε περίπτωση που η υπηρεσία spamd είναι νεκρή, πρέπει να γίνει επανεκκίνηση της υπηρεσίας spamassassin, η οποία θα επανεκκινήσει επίσης το spamd. Η επανεκκίνηση μόνο του spam δεν θα ήταν αρκετή.
Κάποιος μπορεί να επεξεργαστεί το περιεχόμενο ενός τέτοιου αρχείου εξυπηρέτησης σύμφωνα με τις ανάγκες.
Ένα άλλο παράδειγμα είναι το αρχείο pcscd.serv. Σε αυτήν την περίπτωση επανεκκινήθηκαν/σκοτώθηκαν επίσης πολλές άλλες διαδικασίες.
Εάν υπάρχει ένα αρχείο ελέγχου, αφού ελέγξετε εάν η διαδικασία εκτελείται, θα εκτελέσει επίσης αυτό το αρχείο δέσμης ενεργειών για να εκτελέσει επιπλέον ελέγχους.
Για παράδειγμα, για την υπηρεσία oscam, δημιουργήσαμε ένα αρχείο ελέγχου που προσπαθεί να συνδεθεί με τη διεπαφή ιστού για να διαπιστωθεί εάν είναι επιτυχές. Εάν όχι, τότε, παρά την ενεργοποίηση της διαδικασίας, η υπηρεσία δεν ανταποκρίνεται και χρειάζεται επανεκκίνηση. Η επανεκκίνηση της υπηρεσίας πρέπει να πραγματοποιηθεί/κληθεί από το ίδιο το αρχείο.check.
Ένα άλλο παράδειγμα θα ήταν η υπηρεσία DLNA mediatomb.
Αυτός είναι ένας μικρός διακομιστής που παρέχει περιεχόμενο βίντεο/ήχου σε πελάτες DLNA και μεταδίδεται στο δίκτυο. Μερικές φορές η υπηρεσία κολλάει και δεν είναι πλέον ανακαλύψιμη, αλλά η διαδικασία θα είναι ακόμα ενεργή. Για να ελέγξετε αν η υπηρεσία είναι ανιχνεύσιμη, χρησιμοποιήθηκε το βοηθητικό πρόγραμμα CLI που ονομάζεται gssdp-Discover. Ολόκληρος ο κώδικας που ελέγχει τον διακομιστή DLNA τοποθετήθηκε μέσα σε ένα σενάριο mediatomb.check.
Αυτά είναι μόνο μερικά παραδείγματα για το πώς μπορείτε να χρησιμοποιήσετε τα αρχεία.serv και.check.
Για να παρακολουθήσετε μια νέα υπηρεσία, πρέπει να δημιουργήσετε ένα.serv και, εάν χρειάζεται, επίσης ένα αρχείο ελέγχου και να γράψετε το αντίστοιχο σενάριο μέσα σε αυτά.
Εάν αρκεί μόνο ο έλεγχος της παρουσίας της διαδικασίας, τότε αρκεί ένα κενό αρχείο.serv. Εάν πρέπει να γίνουν επιπλέον έλεγχοι, τότε πρέπει να δημιουργηθεί ένα αρχείο.check και να γραφτεί ένα μικρό σενάριο για να γίνει η εργασία.
Από πηγή, το σενάριο.sh πρέπει να εκτελείται περιοδικά, επομένως πρέπει επίσης να δημιουργηθεί μια εργασία cron για αυτό:
#ελέγξτε τις υπηρεσίες που εκτελούνται κάθε 5 λεπτά */5 * * * * /var/bin/ServiceCheck/checkService.sh>/dev/null
Βήμα 3: Τελικές σκέψεις
Ελπίζω ότι θα βρείτε αυτό το πακέτο χρήσιμο, καθώς μπορεί πολύ απλά να παρακολουθεί τις διαδικασίες Linux και ελπίζουμε ότι θα ελαχιστοποιήσει τον χρόνο διακοπής των υπηρεσιών σας.
Μη διστάσετε να ανεβάσετε επιπλέον σενάρια στο github, αν δημιουργήσετε νέα. Απλώς ενημερώστε με και θα σας προσθέσω ως συνεργάτη.