systemd (Ελληνικά)
Από την ιστοσελίδα του project:
Ο systemd είναι ένας διαχειριστής συστήματος και υπηρεσιών για το Linux, συμβατός με τα script εκκίνησης SysV και LSB. O systemd είναι ικανός για παραλληλισμό εργασιών, χρησιμοποιεί socket και τον D-Bus(αγγλικά) για να εκκινήσει τις υπηρεσίες. Προσφέρει εκκίνηση daemons σύφωνα με τις επιθυμίες του χρήστη, παρακολουθεί τις υπηρεσίες που χρησιμοποιούν τα Linux control groups(αγγλικά), υποστηρίζει snapshooting και επαναφορά του συστήματος σε προηγούμενη κατάσταση, συντηρεί τα σημεία προσάρτησης (και αυτόματης προσάρτησης) και υλοποιεί μια επιμελημένη, βασισμένη σε εξαρτήσεις, κεντρική λογική υπηρεσίων.
Contents
- 1 Βασική χρήση της εντολής systemctl
- 2 Γράφοντας προσαρμοσμένα .service files
- 3 Targets
- 4 Temporary files
- 5 Timers
- 6 Journal
- 7 Troubleshooting
- 8 See also
Βασική χρήση της εντολής systemctl
Η βασική εντολή που χρησιμοποιείται για τον έλεγχο του systemd είναι η systemctl. Μερικές από τις χρήσεις της εντολής εξετάζουν την κατάσταση του συστήματος και διαχειρίζονται το σύστημα και τις υπηρεσίες (services). Δες το systemctl(1) για περισσότερες λεπτομέρειες.
Αναλύοντας την κατάσταση του συστήματος
Παρέχει λίστα των μονάδων (units) που εκτελούνται:
$ systemctl
ή
$ systemctl list-units
Παρέχει λίστα των μονάδων που απέτυχαν:
$ systemctl --failed
Οι διαθέσιμες μονάδες φαίνονται στο /usr/lib/systemd/system/
και στο /etc/systemd/system/
(το τελευταίο έχει προτεραιότητα). Μπορείτε να δείτε μια λίστα των εγκατεστημένων αρχείων των μονάδων με την εντολή:
$ systemctl list-unit-files
Χρησιμοποιώντας τις μονάδες (units)
Οι μονάδες μπορούν να είναι, για παράδειγμα, υπηρεσίες (.service), σημεία προσάρτησης (.mount), συσκευές (.device) ή υποδοχές (.socket)
Όταν χρησιμοποιούμε το systemctl, γενικά πρέπει να προσδιορίσουμε το πλήρες όνομα του αρχείου της μονάδας, συμπεριλαμβανομένης της κατάληξης του, για παράδειγμα sshd.socket. Υπάρχουν ωστόσο μερικές σύντομες μορφές για τον προσδιορισμό των μονάδων στις ακόλουθες εντολές του systemctl :
- Αν δεν προσδιορίσουμε την κατάληξη το systemctl θα υποθέσει πως πρόκειται για υπηρεσία .service. Για παράδειγμα, το
netcfg
και τοnetcfg.service
είναι ισοδύναμα. - Τα σημεία προσάρτησης θα μεταφράζονται αυτόματα σε κατάλληλη μονάδα.mount. Για παράδειγμα, το να προσδιορίσουμε το
/home
είναι ισοδύναμο με τοhome.mount
. - Ομοίως με τα σημεία προσάρτησης, οι συσκευές θα μεταφράζονται αυτόματα σε κατάλληλη μονάδα .device και ως εκ τούτου το να προσδιορίζουμε το
/dev/sda2
είναι ισοδύναμο με τοdev-sda2.device
.
Δείτε στο systemd.unit(5) για λεπτομέρειες.
Για να ενεργοποιήσετε μια μονάδα αμέσως:
# systemctl start unit
Απενεργοποιήστε μια μονάδα αμέσως:
# systemctl stop unit
Επανεκκίνηση μια μονάδας:
# systemctl restart unit
Για να φορτώσει ξανά τις ρυθμίσεις:
# systemctl reload unit
Δείτε την κατάσταση μιας μονάδας, συμπεριλαμβανομένου του αν τρέχει ή όχι:
$ systemctl status unit
Δείτε αν μια μονάδα είναι ενεργοποιημένη ή όχι:
$ systemctl is-enabled unit
Ενεργοποιείστε μια μονάδα έτσι ώστε να εκκινεί κατά το boot:
# systemctl enable unit
Απενεργοποίηση μιας υπηρεσίας έτσι ώστε να μην εκκινεί κατά το boot:
# systemctl disable unit
Δείτε την σελίδα τεκμηρίωσης που σχετίζεται με μια μονάδα (πρέπει να υποστηρίζεται από το αρχείο (unit file)):
$ systemctl help unit
Φορτώστε ξανά το systemd σαρώνοντας και εντοπίζοντας νέες μονάδες ή μονάδες που έχουν αλλάξει:
# systemctl daemon-reload
Διαχείριση ενέργειας
Το polkit(αγγλικά) είναι απαραίτητο για να διαχειριστείτε την ενέργεια ως απλός χρήστης (non-root user). Αν βρίσκεστε σε μια τοπική systemd-logind συνεδρία χρήστη και καμία άλλη συνεδρία δεν είναι ενεργή, οι παρακάτω εντολές θα λειτουργήσουν χωρίς δικαιώματα υπερ-χρήστη(root). Αν όχι, (επειδή για παράδειγμα ένας άλλος χρήστης είναι συνδεδεμένος σε ένα TTY), το systemd αυτόματα θα σας ζητήσει τον κωδικό του υπερ-χρήστη (root).
Επανεκκίνηση του συστήματος:
$ systemctl reboot
Διακοπή λειτουργίας του συστήματος:
$ systemctl poweroff
Θέστε το σύστημα σε κατάσταση αναστολής λειτουργίας:
$ systemctl suspend
Θέστε το σύστημα σε κατάσταση αδρανοποίησης:
$ systemctl hibernate
Θέστε το σύστημα σε κατάσταση υβριδικού-ύπνου:
$ systemctl hybrid-sleep
Γράφοντας προσαρμοσμένα .service files
Η σύνταξη του systemd (χρησιμοποιώντας τις μονάδες) είναι εμπνευσμένη από τα .desktop files του XDG Desktop Entry, τα οποία είναι εμπνευσμένα από τα .ini files της Microsoft.
Χειρισμός εξαρτήσεων
Με τον systemd οι εξαρτήσεις μπορούν να επιλυθούν σχεδιάζοντας ένα αρχείο μονάδας(unit file) σωστά. Η πιο συνήθης περίπτωση είναι πως η μονάδα A απαιτεί την μονάδα B να τρέχει ήδη, πριν η μονάδα A ξεκινήσει. Σε αυτή την περίπτωση προσθέτουμε Requires=B
και After=B
στο τμήμα [Unit]
της μονάδας A. Αν η εξάρτηση είναι προαιρετική, προσθέτουμε Wants=B
και After=B
. Σημειώστε ότι τα Wants=
και Requires=
δεν συνεπάγονται το After=
, που σημαίνει πως αν το After=
δεν καθοριστεί, οι δύο μονάδες θα εκκινήσουν παράλληλα.
Οι εξαρτήσεις, συνήθως, τοποθετούνται στις υπηρεσίες (services) και όχι στα targets. Για παράδειγμα, το network.target «τραβιέται» από οποιαδήποτε υπηρεσία εκκινεί και ρυθμίζει τις διασυνδέσεις του δικτύου σας και ως εκ τούτου διατάσσοντας την προσαρμοσμένη μονάδα μετά(after), είναι αρκετό αφού το netwrok.target εκκινεί ούτως ή άλλως.
Είδος
Υπάρχουν πολλά διαφορετικά είδη start-up που πρέπει να σκεφτούμε όταν γράφουμε ένα προσαρμοσμένο αρχείο service. Αυτό το καθορίζουμε με την παράμετρο Type=
στο τμήμα [Service]
. Δείτε στο systemd.service(5) για πιο λεπτομερή εξήγηση.
-
Type=simple
(προεπιλογή): Ο systemd θεωρεί ότι η υπηρεσία πρέπει να εκκινήσει αμέσως. Η διεργασία δεν πρέπει να γίνεται fork. Μην χρησιμοποιείτε αυτόν τον τύπο αν άλλες υπηρεσίες πρέπει να τακτοποιηθούν βάση της συγκεκριμένης υπηρεσίας, εκτός και αν ενεργοποιείται μέσω socket. -
Type=forking
: O systemd θεωρεί πως η υπηρεσία έχει εκκινηθεί όταν η διεργασία έχει γίνει fork και η parent έχει τερματιστεί. Για κλασικές διεργασίες deamon χρησιμοποιείστε αυτόν τον τύπο, εκτός αν γνωρίζετε πως δεν είναι απαραίτητο. Πρέπει να προσδιορίσετε και τοPIDFile=
, έτσι ώστε ο systemd να μπορεί να παρακολουθεί την βασική διεργασία. -
Type=oneshot
: αυτός ο τύπος είναι εύχρηστος για scripts που κάνουν μια συγκεκριμένη «δουλειά» και μετά τερματίζονται. Μπορείτε να θέσετε και τοRemainAfterExit=yes
έτσι ώστε ο systemd να θεωρεί την διεργασία ως ενεργή, ακόμη και μετά τον τερματισμό της. -
Type=notify
: πανομοιότυπο με τοType=simple
, με την προϋπόθεση ότι o daemon θα στείλει ένα σήμα στον systemd για το πότε είναι έτοιμος. Η υλοποίηση της αναφοράς για την εν λόγω ειδοποίηση παρέχεται από το libsystemd-daemon.so. -
Type=dbus
: η υπηρεσία θεωρείται έτοιμη όταν το προσδιορισμένοBusName
εμφανίζεται στο system bus του Dbus.
Επεξεργασία σε παρεχόμενα αρχεία μονάδων
Για να επεξεργαστείτε ένα αρχείο μονάδας(unit) που παρέχεται από κάποιο πακέτο, μπορείτε να δημιουργήσετε έναν κατάλογο που να ονομάζεται /etc/systemd/system/unit.d/
, για παράδειγμα /etc/systemd/system/httpd.service.d/
και να τοποθετήσετε τα αρχεία *.conf εκεί μέσα έτσι ώστε να παρακάμψετε ή να προσθέσετε νέες επιλογές. Ο systemd θα αναλύσει τα αρχεία *.conf και θα τα "περάσει" στην κορυφή της πρωτότυπης μονάδας(unit). Για παράδειγμα, αν απλά θέλετε να προσθέσετε μια επιπρόσθετη εξάρτηση σε μια μονάδα, μπορείτε να δημιουργήσετε το παρακάτω αρχείο:
/etc/systemd/system/unit.d/customdependency.conf
[Unit] Requires=new dependency After=new dependency
Ως άλλο ένα παράδειγμα, για να αντικαταστήσετε την οδηγία του ExecStart
για μια μονάδα, που δεν είναι του τύπου oneshot
, δημιουργήστε το παρακάτω αρχείο:
/etc/systemd/system/unit.d/customexec.conf
[Service] ExecStart= ExecStart=new command
Άλλο ένα παράδειγμα για την αυτόματη επανεκκίνηση μιας υπηρεσίας:
/etc/systemd/system/unit.d/restart.conf
[Service] Restart=always RestartSec=30
Έπειτα τρέξτε το παρακάτω για να τεθούν σε ισχύ οι αλλαγές σας:
# systemctl daemon-reload # systemctl restart unit
Εναλλακτικά μπορείτε να αντιγράψετε το παλιό αρχείο μονάδας από το /usr/lib/systemd/system/
στο /etc/systemd/system/
και να κάνετε τις αλλαγές σας εκεί. Ένα αρχείο μονάδας στο /etc/systemd/system/
πάντα παρακάμπτει/αντικαθιστά την ίδια μονάδα που βρίσκεται στο /usr/lib/systemd/system/
. Σημειώστε πως όταν η πρωτότυπη μονάδα στο /usr/lib/
αλλάξει, πιθανών λόγω αναβάθμισης του πακέτου, αυτές οι αλλαγές δεν θα περαστούν αυτόματα στο προσαρμοσμένο αρχείο σας στο /etc/
. Επιπροσθέτως θα πρέπει να ενεργοποιήσετε πάλι την μονάδα χειροκίνητα με systemctl reenable unit
. Γι' αυτό το λόγο προτείνεται να χρησιμοποιείτε την μέθοδο με τα αρχεία *.conf που περιγράφεται παραπάνω.
Όπως τα παρεχόμενα αρχεία μονάδων θα αναβαθμίζονται από καιρό σε καιρό, χρησιμοποιείστε το systemd-delta για συντήρηση του συστήματος.
Επισήμανση σύνταξης για μονάδες με τον Vim
Η επισήμανση σύνταξης για τα αρχεία μονάδων του systemd μέσα στον Vim(αγγλικά) μπορεί να ενεργοποιηθεί εγκαθιστώντας το vim-systemdAUR από τα επίσημα αποθετήρια(αγγλικά).
Targets
Το systemd χρησιμοποιεί τα targets τα οποία εξυπηρετούν έναν παρόμοιο σκοπό με τα runlevels όμως συμπεριφέρονται λίγο διαφορετικά. Κάθε target διαθέτει ένα όνομα αντί για αριθμό και προτίθεται να εξυπηρετήσει έναν συγκεκριμένο σκοπό με την πιθανότητα να υπάρχουν περισσότερα από ένα ενεργά την ίδια στιγμή. Κάποια targets εφαρμόζονται καθώς δανείζονται όλα τα services ενός άλλου target και προσθέτοντας επιπρόσθετα services σε αυτό. Στο systemd υπάρχουν targets τα οποία μιμούνται τα πιο κοινώς γνωστά runlevels του SystemVinit οπότε και μπορείτε ακόμη να αλλάξετε σε κάποια targets χρησιμοποιώντας την συνηθισμένη εντολή telinit RUNLEVEL
.
Δείτε τα τρέχοντα targets
Το παρακάτω πρέπει να χρησιμοποιείται στο systemd αντί του runlevel
:
$ systemctl list-units --type=target
Δημιουργία προσαρμοσμένου target
Τα runlevels στα οποία έχει ανατεθεί ένας συγκεκριμένος σκοπός σε μια "καθαρή" εγκατάσταση Fedora, 0, 1, 3, 5, και 6, έχουν μια αντιστοίχιση 1:1 με κάποιο συγκεκριμένο systemd target. Δυστυχώς, δεν υπάρχει κάποιος αξιόπιστος τρόπος να κάνετε το ίδιο σε runlevels επιπέδου χρήστη όπως τα 2 και 4. Αν κάνετε χρήση των συγκεκριμένων, προτείνεται να δημιουργήσετε ένα νέο systemd target με όνομα /etc/systemd/system/your target
το οποίο θα παίρνει ένα από τα ήδη υπάρχοντα runlevels ως βάση (μπορείτε να δείτε στο /usr/lib/systemd/system/graphical.target
ως παράδειγμα), να δημιουργήσετε ένα κατάλογο /etc/systemd/system/your target.wants
, και μετά να φτιάξετε ένα symlink των επιπρόσθετων services από το /usr/lib/systemd/system/
τα οποία θέλετε να ενεργοποιήσετε.
Πίνακας Targets
SysV Runlevel | systemd Target | Σημειώσεις |
---|---|---|
0 | runlevel0.target, poweroff.target | Τερματισμός συστήματος. |
1, s, single | runlevel1.target, rescue.target | Single user mode. |
2, 4 | runlevel2.target, runlevel4.target, multi-user.target | Runlevels ορισμένα από τον χρήστη. Από προεπιλογή, ακριβώς ίδιο με το 3. |
3 | runlevel3.target, multi-user.target | Πολλαπλού-χρήστη, μη-γραφικό. Οι χρήστες συνήθως μπορούν να κάνουν εισαγωγή στο σύστημα μέσα από πολλαπλές κονσόλες ή μέσω δικτύου. |
5 | runlevel5.target, graphical.target | Πολλαπλού-χρήστη, γραφικό. Συνήθως περιλαμβάνει όλα τα services του runlevel 3 και επιπροσθέτως ένα γραφικό περιβάλλον σύνδεσης. |
6 | runlevel6.target, reboot.target | Επανεκκίνηση |
emergency | emergency.target | Κέλυφος έκτακτης ανάγκης |
Αλλαγή τρέχοντος target
Στο systemd τα targets εκτίθενται μέσω των target units. Μπορείτε να τα αλλάξετε ως εξής:
# systemctl isolate graphical.target
Αυτό θα τροποποιήσει μόνο το τρέχον target και δεν έχει καμία επίδραση στην επόμενη εκκίνηση συστήματος. Ισοδυναμεί με εντολές όπως telinit 3
ή telinit 5
του Sysvinit.
Αλλαγή προεπιλεγμένου target εκκίνησης συστήματος
Το κανονικό target είναι το default.target, το οποίο από προεπιλογή είναι ένα alias του graphical.target (το οποίο αντιστοιχεί περίπου στο παλιό runlevel 5). Για να αλλάξετε το προεπιλεγμένο target κατά τη διάρκεια της εκκίνησης, προσθέστε μια από τις ακόλουθες παραμέτρους πυρήνα(αγγλικά) στον bootloader:
-
systemd.unit=multi-user.target
(το οποίο αντιστοιχεί περίπου στο παλιό runlevel 3), -
systemd.unit=rescue.target
(το οποίο αντιστοιχεί περίπου στο παλιό runlevel 1).
Εναλλακτικά, μπορείτε να μην πειράξετε τον bootloader αλλά να αλλάξετε το default.target. Αυτό μπορεί να γίνει χρησιμοποιώντας την systemctl:
# systemctl enable multi-user.target
Η επίδραση αυτής της εντολής φαίνεται στη έξοδο της systemctl· ένα symlink στο νέο προεπιλεγμένο target δημιουργείται στο /etc/systemd/system/default.target
. Αυτό λειτουργεί μόνον αν το:
[Install] Alias=default.target
υπάρχει στο αρχείο ρυθμίσεων του target. Για τώρα, τα multi-user.target και graphical.target το έχουν και τα δυο.
Temporary files
"systemd-tmpfiles creates, deletes and cleans up volatile and temporary files and directories." It reads configuration files in /etc/tmpfiles.d/
and /usr/lib/tmpfiles.d/
to discover which actions to perform. Configuration files in the former directory take precedence over those in the latter directory.
Configuration files are usually provided together with service files, and they are named in the style of /usr/lib/tmpfiles.d/program.conf
. For example, the Samba daemon expects the directory /run/samba
to exist and to have the correct permissions. Therefore, the samba package ships with this configuration:
/usr/lib/tmpfiles.d/samba.conf
D /run/samba 0755 root root
Configuration files may also be used to write values into certain files on boot. For example, if you used /etc/rc.local
to disable wakeup from USB devices with echo USBE > /proc/acpi/wakeup
, you may use the following tmpfile instead:
/etc/tmpfiles.d/disable-usb-wake.conf
w /proc/acpi/wakeup - - - - USBE
See the systemd-tmpfiles
and tmpfiles.d(5)
man pages for details.
/sys
since the systemd-tmpfiles-setup service may run before the appropriate device modules is loaded. In this case you could check whether the module has a parameter for the option you want to set with modinfo module
and set this option with a config file in /etc/modprobe.d[broken link: invalid section]. Otherwise you will have to write a udev rule to set the appropriate attribute as soon as the device appears.Timers
Systemd can replace cron functionality to a great extent. See systemd/Timers.
Journal
systemd has its own logging system called the journal; therefore, running a syslog daemon is no longer required. To read the log, use:
# journalctl
In Arch Linux, the directory /var/log/journal/
is a part of the systemd package, and the journal (when Storage=
is set to auto
in /etc/systemd/journald.conf
) will write to /var/log/journal/
. If you or some program delete that directory, systemd will not recreate it automatically; however, it will be recreated during the next update of the systemd package. Until then, logs will be written to /run/systemd/journal
, and logs will be lost on reboot.
/var/log/journal/
resides in a btrfs file system, you should consider disabling Copy-on-Write for the directory. See the main article for details: Btrfs#Copy-on-Write (CoW).Filtering output
journalctl allows you to filter the output by specific fields. Be aware that if there are many messages to display or filtering of large time span has to be done, the output of this command can be delayed for quite some time.
Examples:
Show all messages from this boot:
# journalctl -b
However, often one is interested in messages not from the current, but from the previous boot (e.g. if an unrecoverable system crash happened). This is possible through optional offset parameter of the -b
flag: journalctl -b -0
shows messages from the current boot, journalctl -b -1
from the previous boot, journalctl -b -2
from the second previous and so on. See journalctl(1) for full description, the semantics is much more powerful.
Follow new messages:
# journalctl -f
Show all messages by a specific executable:
# journalctl /usr/lib/systemd/systemd
Show all messages by a specific process:
# journalctl _PID=1
Show all messages by a specific unit:
# journalctl -u netcfg
Show kernel ring buffer:
# journalctl _TRANSPORT=kernel
See journalctl(1), systemd.journal-fields(7), or Lennert's blog post for details.
Journal size limit
If the journal is persistent (non-volatile), its size limit is set to a default value of 10% of the size of the respective file system. For example, with /var/log/journal
located on a 50 GiB root partition this would lead to 5 GiB of journal data. The maximum size of the persistent journal can be controlled by SystemMaxUse
in /etc/systemd/journald.conf
, so to limit it for example to 50 MiB uncomment and edit the corresponding line to:
SystemMaxUse=50M
Refer to journald.conf(5) for more info.
Journald in conjunction with syslog
Compatibility with classic syslog implementations is provided via a socket /run/systemd/journal/syslog
, to which all messages are forwarded. To make the syslog daemon work with the journal, it has to bind to this socket instead of /dev/log
(official announcement). The syslog-ng package in the repositories automatically provides the necessary configuration.
# systemctl enable syslog-ng
A good journalctl tutorial is here.
Forward journald to /dev/tty12
In /etc/systemd/journald.conf
enable the following:
ForwardToConsole=yes TTYPath=/dev/tty12 MaxLevelConsole=info
Restart journald with sudo systemctl restart systemd-journald
.
Troubleshooting
Investigating systemd errors
As an example, we will investigate an error with systemd-modules-load
service:
1. Lets find the systemd services which fail to start:
$ systemctl --state=failed
systemd-modules-load.service loaded failed failed Load Kernel Modules
2. Ok, we found a problem with systemd-modules-load
service. We want to know more:
$ systemctl status systemd-modules-load
systemd-modules-load.service - Load Kernel Modules Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static) Active: failed (Result: exit-code) since So 2013-08-25 11:48:13 CEST; 32s ago Docs: man:systemd-modules-load.service(8). man:modules-load.d(5) Process: 15630 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE)
If the Process ID
is not listed, just restart the failed service with systemctl restart systemd-modules-load
3. Now we have the process id (PID) to investigate this error in depth. Enter the following command with the current Process ID
(here: 15630):
$ journalctl -b _PID=15630
-- Logs begin at Sa 2013-05-25 10:31:12 CEST, end at So 2013-08-25 11:51:17 CEST. -- Aug 25 11:48:13 mypc systemd-modules-load[15630]: Failed to find module 'blacklist usblp' Aug 25 11:48:13 mypc systemd-modules-load[15630]: Failed to find module 'install usblp /bin/false'
4. We see that some of the kernel module configs have wrong settings. Therefore we have a look at these settings in /etc/modules-load.d/
:
$ ls -Al /etc/modules-load.d/
... -rw-r--r-- 1 root root 79 1. Dez 2012 blacklist.conf -rw-r--r-- 1 root root 1 2. Mär 14:30 encrypt.conf -rw-r--r-- 1 root root 3 5. Dez 2012 printing.conf -rw-r--r-- 1 root root 6 14. Jul 11:01 realtek.conf -rw-r--r-- 1 root root 65 2. Jun 23:01 virtualbox.conf ...
5. The Failed to find module 'blacklist usblp'
error message might be related to a wrong setting inside of blacklist.conf
. Lets deactivate it with inserting a trailing # before each option we found via step 3:
/etc/modules-load.d/blacklist.conf
# blacklist usblp # install usblp /bin/false
6. Now, try to start systemd-modules-load
:
$ systemctl start systemd-modules-load.service
If it was successful, this shouldn't prompt anything. If you see any error, go back to step 3. and use the new PID for solving the errors left.
If everything is ok, you can verify that the service was started successfully with:
$ systemctl status systemd-modules-load
systemd-modules-load.service - Load Kernel Modules Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static) Active: active (exited) since So 2013-08-25 12:22:31 CEST; 34s ago Docs: man:systemd-modules-load.service(8) man:modules-load.d(5) Process: 19005 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=0/SUCCESS) Aug 25 12:22:31 mypc systemd[1]: Started Load Kernel Modules.
Often you can solve these kind of problems like shown above. For further investigation look at Diagnosing boot problems.
Diagnosing boot problems
Boot with these parameters on the kernel command line:
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M
Shutdown/reboot takes terribly long
If the shutdown process takes a very long time (or seems to freeze) most likely a service not exiting is to blame. systemd waits some time for each service to exit before trying to kill it. To find out if you are affected, see this article.
Short lived processes do not seem to log any output
If journalctl -u foounit
does not show any output for a short lived service, look at the PID instead. For example, if systemd-modules-load.service
fails, and systemctl status systemd-modules-load
shows that it ran as PID 123, then you might be able to see output in the journal for that PID, i.e. journalctl -b _PID=123
. Metadata fields for the journal such as _SYSTEMD_UNIT and _COMM are collected asynchronously and rely on the /proc
directory for the process existing. Fixing this requires fixing the kernel to provide this data via a socket connection, similar to SCM_CREDENTIALS.
Disabling application crash dumps journaling
Run the following in order to overwrite the settings from /lib/sysctl.d/
:
# ln -s /dev/null /etc/sysctl.d/50-coredump.conf # sysctl kernel.core_pattern=core
This will disable logging of coredumps to the journal.
Note that the default RLIMIT_CORE of 0 means that no core files are written, either. If you want them, you also need to "unlimit" the core file size in the shell:
$ ulimit -c unlimited
See sysctl.d and the documentation for /proc/sys/kernel for more information.
Error message on reboot or shutdown
cgroup : option or name mismatch, new: 0x0 "", old: 0x4 "systemd"
See this thread for an explanation.
watchdog watchdog0: watchdog did not stop!
See this thread for an explanation.
See also
- Official web site
- Wikipedia article
- Manual pages
- systemd optimizations
- FAQ
- Tips and tricks
- systemd for Administrators (PDF)
- About systemd on Fedora Project
- How to debug systemd problems
- Two part introductory article in The H Open magazine.
- Lennart's blog story
- Status update
- Status update2
- Status update3
- Most recent summary
- Fedora's SysVinit to systemd cheatsheet
- Configuring systemd to allow normal users to shutdown