Ανάγνωση αρχείων καταγραφής με το journalctl

Ενότητα 6: Υπηρεσίες και αρχεία καταγραφής · Χρόνος ανάγνωσης: 11 λεπτά

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

Βασικές έννοιες: journald, journal, journalctl -u, -p, --since/--until, -f, -b, -e, -n, προτεραιότητα (err, warning, info), μόνιμη αποθήκευση, /var/log/journal, --disk-usage, --vacuum-size, /var/log, logrotate, rsyslog

Το αρχείο καταγραφής ως πρώτος μάρτυρας

Όταν κάτι δεν λειτουργεί στον server σας, η αιτία βρίσκεται σχεδόν πάντα σε ένα αρχείο καταγραφής. Ένας ιστότοπος που εμφανίζει σελίδα σφάλματος, μια υπηρεσία που δεν ξεκινά, ένα αντίγραφο ασφαλείας που δεν εκτελέστηκε απόψε: ο server το έχει καταγράψει. Ένας καλός διαχειριστής κοιτάζει πρώτα το αρχείο καταγραφής και μόνο μετά αρχίζει να αλλάζει πράγματα.

Στους σύγχρονους Linux servers, το journald (μέρος του systemd) συγκεντρώνει τα μηνύματα του kernel, του ίδιου του systemd και όλων των υπηρεσιών σε ένα ενιαίο αρχείο καταγραφής: το journal. Το διαβάζετε με το journalctl.

Για να μπορείτε να τα διαβάσετε όλα, πρέπει να ανήκετε στην ομάδα adm ή systemd-journal, ή να χρησιμοποιήσετε το sudo. Χωρίς αυτά τα δικαιώματα βλέπετε μόνο τα δικά σας μηνύματα.

Πού αποθηκεύεται; Μόνιμα ή προσωρινά

Το journald αποθηκεύει το journal σε ένα από δύο σημεία:

• στο /var/log/journal/: μόνιμα, τα logs διατηρούνται μετά από επανεκκίνηση·
• στο /run/log/journal/: προσωρινά, στη μνήμη, χάνονται μετά από επανεκκίνηση.

Η προεπιλεγμένη ρύθμιση (Storage=auto στο /etc/systemd/journald.conf) επιλέγει μόνιμη αποθήκευση αν υπάρχει ο φάκελος /var/log/journal/. Στο Debian, το πακέτο systemd δημιουργεί αυτόν τον φάκελο ήδη από το Debian 11, και στο Ubuntu υπάρχει επίσης. Ελέγξτε το:

anna@web1:~$ ls -d /var/log/journal
/var/log/journal
anna@web1:~$ journalctl --list-boots | tail -n 3
 -2 3c1f... Sun 2026-11-01 04:30:12 CET Sun 2026-11-08 04:30:01 CET
 -1 9ab7... Sun 2026-11-08 04:30:40 CET Mon 2026-11-09 08:12:05 CET
  0 e41d... Mon 2026-11-09 08:12:30 CET Mon 2026-11-09 11:40:17 CET

Αν βλέπετε μόνο μία εκκίνηση, ενώ ο server έχει ήδη επανεκκινηθεί κάποια φορά, τότε τα logs σας είναι προσωρινά. Δημιουργήστε τον φάκελο (sudo mkdir -p /var/log/journal και sudo systemd-tmpfiles --create --prefix /var/log/journal) και επανεκκινήστε το journald. Αυτό είναι σημαντικό: μετά από ένα crash θέλετε ακριβώς να μάθετε τι συνέβη πριν από την επανεκκίνηση.

Από το Debian 12, το Debian δεν εγκαθιστά πλέον το rsyslog από προεπιλογή. Αυτό το πρόγραμμα έγραφε παλαιότερα αρχεία κειμένου όπως τα /var/log/syslog και /var/log/auth.log. Σε έναν νέο Debian server, λοιπόν, αυτά δεν υπάρχουν· όλα βρίσκονται στο journal. Το Ubuntu εξακολουθεί να έχει rsyslog. Οδηγούς που λένε «κοιτάξτε στο /var/log/auth.log» μπορείτε στο Debian να τους μεταφράσετε σε journalctl -u ssh.

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

Χωρίς φίλτρο, το journalctl εμφανίζει τα πάντα, ξεκινώντας από τα παλαιότερα. Σπάνια είναι αυτό που θέλετε. Τα σημαντικότερα φίλτρα, τα οποία μπορείτε να συνδυάσετε:

Οι προτεραιότητες κυμαίνονται από 0 (emerg) έως 7 (debug): emerg, alert, crit, err, warning, notice, info, debug. Με το -p err λαμβάνετε το err και ό,τι είναι σοβαρότερο. Το -p warning εμφανίζει και τις προειδοποιήσεις.

Μια τυπική διαδρομή αναζήτησης. Ο ιστότοπός σας εμφανίζει από σήμερα το πρωί σφάλμα 502:

anna@web1:~$ systemctl status php8.4-fpm
× php8.4-fpm.service - The PHP 8.4 FastCGI Process Manager
     Active: failed (Result: exit-code) since Mon 2026-11-09 07:02:11 CET; 4h ago
...
anna@web1:~$ sudo journalctl -u php8.4-fpm --since today -p warning --no-pager
nov 09 07:02:10 web1 php-fpm8.4[1830]: [09-Nov-2026 07:02:10] ERROR: [/etc/php/8.4/fpm/pool.d/www.conf:42] unknown entry 'pm.max_children '
nov 09 07:02:10 web1 php-fpm8.4[1830]: [09-Nov-2026 07:02:10] ERROR: FPM initialization failed
nov 09 07:02:11 web1 systemd[1]: php8.4-fpm.service: Main process exited, code=exited, status=78/CONFIG
nov 09 07:02:11 web1 systemd[1]: php8.4-fpm.service: Failed with result 'exit-code'.

Η αιτία αναγράφεται κατά λέξη: ένα τυπογραφικό λάθος στη γραμμή 42 ενός αρχείου ρυθμίσεων. Η κατάσταση 78 (CONFIG) επιβεβαιώνει ότι πρόκειται για σφάλμα ρύθμισης. Δεν χρειάζεται να μαντέψετε τίποτα.

Δύο συμβουλές για την ανάγνωση:

• Διαβάζετε από πάνω προς τα κάτω και αναζητήστε το πρώτο σφάλμα. Ένα σφάλμα συχνά προκαλεί ολόκληρη σειρά επακόλουθων μηνυμάτων. Το πρώτο είναι συνήθως η αιτία.
• Προσέξτε την ώρα. Τι άλλαξε γύρω από εκείνη τη στιγμή; Μια αυτόματη ενημέρωση (μάθημα 4.2: /var/log/unattended-upgrades/), μια δική σας αλλαγή, μια επανεκκίνηση;

Άλλα αρχεία καταγραφής

Δεν βρίσκονται όλα στο journal. Πολλά προγράμματα γράφουν επίσης (ή μόνο) δικά τους αρχεία στο /var/log/:

Τα μεγάλα αρχεία κειμένου τα διαβάζετε με το less (αναζήτηση με /), το τέλος τους με το tail -n 50, σε πραγματικό χρόνο με το tail -f και τα φιλτράρετε με το grep:

anna@web1:~$ sudo grep " 502 " /var/log/nginx/access.log | tail -n 5

Τα logs των Docker containers δεν βρίσκονται στο /var/log, αλλά στο ίδιο το Docker: docker compose logs (μάθημα 9.3).

Τα logs δεν πρέπει να γεμίζουν τον δίσκο σας

Ένας γεμάτος δίσκος είναι μία από τις πιο συχνές αιτίες για τις οποίες ένας server «ξαφνικά» σταματά να λειτουργεί: οι βάσεις δεδομένων σταματούν, οι ενημερώσεις αποτυγχάνουν, μερικές φορές δεν μπορείτε καν να συνδεθείτε. Τα logs είναι συχνά οι υπαίτιοι.

Το journal περιορίζει τον εαυτό του. Από προεπιλογή χρησιμοποιεί το πολύ 10% του συστήματος αρχείων, με μέγιστο τα 4 GB (SystemMaxUse=). Πόσο χώρο χρησιμοποιεί τώρα και πώς τον καθαρίζετε:

anna@web1:~$ journalctl --disk-usage
Archived and active journals take up 512.0M in the file system.
anna@web1:~$ sudo journalctl --vacuum-time=30d     # διαγραφή όσων είναι παλαιότερα από 30 ημέρες
anna@web1:~$ sudo journalctl --vacuum-size=500M    # έως 500 MB

Αν θέλετε ένα σταθερό όριο, ορίστε το σε ένα drop-in /etc/systemd/journald.conf.d/grootte.conf:

[Journal]
SystemMaxUse=1G

και επανεκκινήστε το journald με sudo systemctl restart systemd-journald.

Τα αρχεία κειμένου στο /var/log τα διαχειρίζεται το logrotate: κάθε ημέρα ή εβδομάδα ένα αρχείο μετονομάζεται (error.log.1), οι παλαιότερες εκδόσεις συμπιέζονται (.gz) και οι παλαιότερες όλων διαγράφονται. Οι κανόνες ανά πρόγραμμα βρίσκονται στο /etc/logrotate.d/. Τα πακέτα της διανομής φέρνουν τον δικό τους κανόνα. Αν ένα δικό σας πρόγραμμα ή script γράφει σε δικό του αρχείο καταγραφής, δημιουργήστε μόνοι σας έναν κανόνα, διαφορετικά το αρχείο θα μεγαλώνει επ' αόριστον.

Αναζήτηση του τι καταλαμβάνει χώρο:

anna@web1:~$ df -h /
anna@web1:~$ sudo du -xh /var/log | sort -h | tail -n 5

Logs και ιδιωτικότητα

Τα αρχεία καταγραφής περιέχουν διευθύνσεις IP, ονόματα χρηστών και μερικές φορές διευθύνσεις email: πρόκειται για δεδομένα προσωπικού χαρακτήρα. Μην τα διατηρείτε περισσότερο από όσο χρειάζεται (από μερικές εβδομάδες έως μερικούς μήνες είναι σύνηθες για έναν μικρό server), μην τα αφήνετε δημόσια προσβάσιμα (ένας φάκελος /logs στο webroot σας είναι γνωστό λάθος) και μην τα αντιγράφετε αβασάνιστα σε υπηρεσίες τρίτων.

Σε AlmaLinux και Rocky Linux

Το journalctl λειτουργεί με τον ίδιο τρόπο. Εκεί το rsyslog είναι ακόμη ενεργό από προεπιλογή, με αρχεία όπως τα /var/log/messages και /var/log/secure (το αντίστοιχο του auth.log). Τα μηνύματα του SELinux βρίσκονται στο /var/log/audit/audit.log· το ausearch -m avc -ts recent εμφανίζει τις πρόσφατες απορρίψεις.

Σύνοψη

• Το journald συγκεντρώνει όλα τα μηνύματα στο journal· διαβάστε το με το journalctl, φιλτραρισμένο ανά υπηρεσία (-u), προτεραιότητα (-p), χρόνο (--since) και εκκίνηση (-b).
• Ελέγξτε ότι το journal είναι μόνιμο (υπάρχει το /var/log/journal), διαφορετικά χάνετε τα logs σας μετά από επανεκκίνηση.
• Το Debian 12 και οι νεότερες εκδόσεις δεν έχουν από προεπιλογή rsyslog και επομένως ούτε /var/log/auth.log και /var/log/syslog· όλα βρίσκονται στο journal.
• Αναζητήστε το πρώτο σφάλμα και εξετάστε τι άλλαξε γύρω από εκείνη τη στιγμή.
• Παρακολουθείτε το μέγεθος: το journal περιορίζει τον εαυτό του (--disk-usage, --vacuum-*), τα αρχεία κειμένου τα διαχειρίζεται το logrotate.

Κουίζ

Άσκηση

Άσκηση Z6.2: Ανάλυση μιας υπηρεσίας που καταρρέει. Στο αρχείο παραδείγματος journal-crash-1.txt υπάρχει η έξοδος των systemctl status και journalctl μιας υπηρεσίας που επανεκκινείται συνεχώς και στη συνέχεια εγκαταλείπεται. Απαντήστε: πώς ονομάζεται η υπηρεσία, πόσες φορές προσπάθησε το systemd να την εκκινήσει, με ποιον κωδικό εξόδου σταμάτησε, ποια είναι η αιτία σύμφωνα με το πρώτο μήνυμα σφάλματος και τι ώρα σταμάτησε να προσπαθεί το systemd; Το πρόγραμμα συγκρίνει τις απαντήσεις σας με το σταθερό κλειδί. Στη συνέχεια ελέγξτε στον δικό σας server αν το journalctl -p err -b εμφανίζει σφάλματα και αν το journal σας είναι μόνιμο.

Για περαιτέρω μελέτη

• Εγχειρίδιο journalctl(1): https://manpages.debian.org/trixie/systemd/journalctl.1.en.html
• Εγχειρίδιο journald.conf(5) (Storage=, SystemMaxUse=): https://manpages.debian.org/trixie/systemd/journald.conf.5.en.html
• Debian 12, σημειώσεις έκδοσης 5.1.7 (το rsyslog δεν εγκαθίσταται πλέον από προεπιλογή): https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html