Systemctl: Unterschied zwischen den Versionen
KKeine Bearbeitungszusammenfassung |
KKeine Bearbeitungszusammenfassung |
||
Zeile 1: | Zeile 1: | ||
'''systemctl''' steuert den Systemd | |||
Auf einem frisch gestarteten CentOS 7 mit grafischer Benutzeroberfläche sind das um die 130 Stück. Wer nur an bestimmten Units interessiert ist, kann die Anzeige über den Parameter "--type=" einschränken. | Auf einem frisch gestarteten CentOS 7 mit grafischer Benutzeroberfläche sind das um die 130 Stück. Wer nur an bestimmten Units interessiert ist, kann die Anzeige über den Parameter "--type=" einschränken. |
Version vom 23. Februar 2022, 09:52 Uhr
systemctl steuert den Systemd
Auf einem frisch gestarteten CentOS 7 mit grafischer Benutzeroberfläche sind das um die 130 Stück. Wer nur an bestimmten Units interessiert ist, kann die Anzeige über den Parameter "--type=" einschränken.
Alle Dienste präsentiert etwa "systemctl --type=service". Die Ausgaben von "systemctl" zeigt standardmäßig "less" an, die Navigation erfolgt mit den Pfeiltasten und der Leertaste, [q] wiederum beendet die Anzeige.
Neben dem Namen der Unit verrät "systemctl" in der zweiten und dritten Spalte, ob es die Unit laden und aktivieren konnte. Die Spalte "SUB" gibt Auskunft über den derzeitigen Status: Bei einem Dateisystem erfährt man etwa, ob dieses gemountet ist, bei einem Dienst hingegen, ob dieser läuft ("running").
In der letzten Spalte findet man schließlich noch eine kurze Beschreibung der Unit. Sofern ein Dienst beim Start nicht hochfahren wollte oder abgestürzt ist, markiert "systemctl" dies in seiner Ausgabe in hell leuchtendem Rot.
Eine Liste mit allen nicht funktionierenden Units liefert "systemctl --failed", detaillierte Informationen über eine Unit zeigt ein Aufruf von "systemctl status" an (Bild 2).
In bestimmten Situationen erzeugt Systemd selbst eine Unit. Das passiert beispielsweise nach dem Anstöpseln eines neuen Gerätes.
Die dann unter Umständen mithilfe von Udev generierten Units erscheinen zwar in der Ausgabe von "systemctl", es existieren aber keine passenden Unit-Dateien auf der Festplatte. Von diesen dynamisch generierten Units dürfen aber wiederum andere Units abhängen.
Änderungen nur mit root
Alle bisher vorgestellten Informationen darf jeder Nutzer abfragen. Um Änderungen an der Konfiguration vorzunehmen, müssen Sie "systemctl" jedoch mit Root-Rechten starten.
Dann lassen sich einzelne Units über »systemctl start« aktivieren beziehungsweise mit »systemctl stop« anhalten. Der folgende Befehl fährt den SSH-Daemon hoch:
systemctl start sshd.service
Auf Systemen mit SysV-Init würde dies dem Aufruf des Skripts "/etc/init.d/sshd start" entsprechen. Vergessen Sie im Unit-Namen den Typ, geht Systemd von ".service" aus.
Den SSH-Daemon könnten Sie folglich einfach mit »systemctl start sshd« anwerfen. "systemctl" wechselt natürlich auch Targets.
Der folgende Befehl aktiviert beispielsweise das Target "rescue.target", was wiederum zu einem Rettungssystem führt:
systemctl isolate rescue.target
Die Angabe "isolate" sorgt dafür, dass ausschließlich die von "rescue.target" vorgegebenen Units aktiv sind, alle anderen Dienste und Units beendet Systemd.
Um zu verhindern, dass ein Dienst beim Systemstart automatisch hochfährt, deaktivieren Sie ihn:
systemctl disable sshd.service
In diesem Beispiel würde Systemd den SSH-Daemon aus sämtlichen Targets nehmen. Mit "enable" knipsen Sie ihn wieder an:
systemctl enable sshd.service
Damit gehört der SSH-Daemon wieder zu allen Targets, die in seiner Unit-Datei (aus dem Listing "sshd.service") hinter "WantedBy" vermerkt sind.
Im Hintergrund setzt Systemd dabei übrigens lediglich die symbolischen Links in den ".wants"-Unterverzeichnissen.
Bild 2: In den Status-Informationen liefert "systemctl" unter anderem auch die PID (hier die 1270) und die Laufzeit des Dienstes (hier über eine Stunde).
Wichtige Systemd-Befehle
systemctl | |
systemctl start sshd.service | |
systemctl stop sshd.service | |
systemctl disable sshd.service | |
systemctl enable sshd.service | |
systemctl --failed | |
systemctl isolate graphical.target | |
systemctl isolate multi-user.target | |
systemctl daemon-reload |
|
Listing running services
$ systemctl UNIT LOAD ACTIVE SUB JOB DESCRIPTION accounts-daemon.service loaded active running Accounts Service atd.service loaded active running Job spooling tools avahi-daemon.service loaded active running Avahi mDNS/DNS-SD Stack bluetooth.service loaded active running Bluetooth Manager colord-sane.service loaded active running Daemon for monitoring attached scanners and registering them with colord colord.service loaded active running Manage, Install and Generate Color Profiles crond.service loaded active running Command Scheduler cups.service loaded active running CUPS Printing Service dbus.service loaded active running D-Bus System Message Bus ...
Showing runtime status
$ systemctl status udisks2.service udisks2.service - Storage Daemon
Loaded: loaded (/usr/lib/systemd/system/udisks2.service; static) Active: active (running) since Wed, 27 Jun 2012 20:49:25 +0200; 1 day and 1h ago Main PID: 615 (udisksd) CGroup: name=systemd:/system/udisks2.service └ 615 /usr/lib/udisks2/udisksd --no-debug
Jun 27 20:49:25 epsilon udisksd[615]: udisks daemon version 1.94.0 starting Jun 27 20:49:25 epsilon udisksd[615]: Acquired the name org.freedesktop.UDisks2 on the system message bus
Runlevel
What would get started?
… if I booted into a specific target?
If you want systemd to calculate the "initial" transaction it would execute on boot, try something like this:
$ systemd --test --system --unit=foobar.target
for a boot target foobar.target. Note that this is mostly a debugging tool that actually does a lot more than just calculate the initial transaction, so don't build scripts based on this.
Change current runlevel
In systemd runlevels are exposed via "target units". You can change them like this:
- systemctl isolate runlevel5.target
Note however, that the concept of runlevels is a bit out of date, and it is usually nicer to use modern names for this. e.g.:
- systemctl isolate graphical.target
This will only change the current runlevel, and has no effect on the next boot.
Change default runlevel
The symlink /etc/systemd/system/default.target controls where we boot into by default. Link it to the target unit of your choice. For example, like this:
or
Current runlevel
Note that there might be more than one target active at the same time. So the question regarding the runlevel might not always make sense. Here's how you would figure out all targets that are currently active:
If you are just interested in a single number, you can use the venerable runlevel command, but again, its output might be misleading.
Enable another getty
Simply instantiate a new getty service for the port of your choice (internally, this places another symlink for instantiating another serial getty in the getty.target.wants/ directory).
- systemctl enable serial-getty@ttyS2.service
- systemctl start serial-getty@ttyS2.service
Note that gettys on the virtual console are started on demand. You can control how many you get via the NAutoVTs= setting in logind.conf(7). Also see this blog story.
Which service a process belongs to?
You may either use ps for that:
$ alias psc='ps xawf -eo pid,user,cgroup,args' $ psc ...
Or you can even check /proc/$PID/cgroup directly. Also see this blog story.
journalctl - display full messages
Even if less is not used?
A: Use:
- journalctl --full
/tmp and tmpfs
My systemd system always comes up with /tmp as a tiny tmpfs. How do I get rid of this?
That's also a long story, please have a look on:* API File Systems (http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems)
cgroups
cgroup tree
$ systemd-cgls └ system
├ 1 /usr/lib/systemd/systemd --system --deserialize 18 ├ ntpd.service │ └ 8471 /usr/sbin/ntpd -u ntp:ntp -g ├ upower.service │ └ 798 /usr/libexec/upowerd ├ wpa_supplicant.service │ └ 751 /usr/sbin/wpa_supplicant -u -f /var/log/wpa_supplicant.log -c /etc/wpa_supplicant/wpa_supplicant.conf -u -f /var/log/wpa_supplicant.log -P /var/run/wpa_supplicant.pid ├ nfs-idmap.service │ └ 731 /usr/sbin/rpc.idmapd ├ nfs-rquotad.service │ └ 753 /usr/sbin/rpc.rquotad ├ nfs-mountd.service │ └ 732 /usr/sbin/rpc.mountd ├ nfs-lock.service │ └ 704 /sbin/rpc.statd ├ rpcbind.service │ └ 680 /sbin/rpcbind -w ├ postfix.service │ ├ 859 /usr/libexec/postfix/master │ ├ 877 qmgr -l -t fifo -u │ └ 32271 pickup -l -t fifo -u ├ colord-sane.service │ └ 647 /usr/libexec/colord-sane ├ udisks2.service │ └ 615 /usr/lib/udisks2/udisksd --no-debug ├ colord.service │ └ 607 /usr/libexec/colord ├ prefdm.service │ ├ 567 /usr/sbin/gdm-binary -nodaemon │ ├ 602 /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1 │ ├ 612 /usr/bin/Xorg :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-O00GPA/database -seat seat0 -nolisten tcp │ └ 905 gdm-session-worker [pam/gdm-password] ├ systemd-ask-password-wall.service │ └ 645 /usr/bin/systemd-tty-ask-password-agent --wall ├ atd.service │ └ 544 /usr/sbin/atd -f ├ ksmtuned.service │ ├ 548 /bin/bash /usr/sbin/ksmtuned │ └ 1092 sleep 60 ├ dbus.service │ ├ 586 /bin/dbus-daemon --system --address=systemd: --nofork --systemd-activation │ ├ 601 /usr/libexec/polkit-1/polkitd --no-debug │ └ 657 /usr/sbin/modem-manager ├ cups.service │ └ 508 /usr/sbin/cupsd -f ├ avahi-daemon.service │ ├ 506 avahi-daemon: running [epsilon.local] │ └ 516 avahi-daemon: chroot helper ├ system-setup-keyboard.service │ └ 504 /usr/bin/system-setup-keyboard ├ accounts-daemon.service │ └ 502 /usr/libexec/accounts-daemon ├ systemd-logind.service │ └ 498 /usr/lib/systemd/systemd-logind ├ crond.service │ └ 486 /usr/sbin/crond -n ├ NetworkManager.service │ ├ 484 /usr/sbin/NetworkManager --no-daemon │ └ 8437 /sbin/dhclient -d -4 -sf /usr/libexec/nm-dhcp-client.action -pf /var/run/dhclient-wlan0.pid -lf /var/lib/dhclient/dhclient-903b6f6aa7a1-46c8-82a9-7f637dfbb3e4-wlan0.lease -cf /var/run/nm-d... ├ libvirtd.service │ ├ 480 /usr/sbin/libvirtd │ └ 571 /sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --except-interface lo --listenaddress 192.168.122.1 --dhcp-range 192.168.122.2,1... ├ bluetooth.service │ └ 479 /usr/sbin/bluetoothd -n ├ systemd-udev.service │ └ 287 /usr/lib/systemd/systemd-udevd └ systemd-journald.service └ 280 /usr/lib/systemd/systemd-journald
ps with cgroups
$ alias psc='ps xawf -eo pid,user,cgroup,args' $ psc
PID USER CGROUP COMMAND
...
1 root name=systemd:/systemd-1 /bin/systemd systemd.log_target=kmsg systemd.log_level=debug selinux=0 415 root name=systemd:/systemd-1/sysinit.service /sbin/udevd -d 928 root name=systemd:/systemd-1/atd.service /usr/sbin/atd -f 930 root name=systemd:/systemd-1/ntpd.service /usr/sbin/ntpd -n 932 root name=systemd:/systemd-1/crond.service /usr/sbin/crond -n 935 root name=systemd:/systemd-1/auditd.service /sbin/auditd -n 943 root name=systemd:/systemd-1/auditd.service \_ /sbin/audispd 964 root name=systemd:/systemd-1/auditd.service \_ /usr/sbin/sedispatch 937 root name=systemd:/systemd-1/acpid.service /usr/sbin/acpid -f 941 rpc name=systemd:/systemd-1/rpcbind.service /sbin/rpcbind -f 944 root name=systemd:/systemd-1/rsyslog.service /sbin/rsyslogd -n -c 4 947 root name=systemd:/systemd-1/systemd-logger.service /lib/systemd/systemd-logger 950 root name=systemd:/systemd-1/cups.service /usr/sbin/cupsd -f 955 dbus name=systemd:/systemd-1/messagebus.service /bin/dbus-daemon --system --address=systemd: --nofork --systemd-activation 969 root name=systemd:/systemd-1/getty@.service/tty6 /sbin/mingetty tty6 970 root name=systemd:/systemd-1/getty@.service/tty5 /sbin/mingetty tty5 971 root name=systemd:/systemd-1/getty@.service/tty1 /sbin/mingetty tty1 973 root name=systemd:/systemd-1/getty@.service/tty4 /sbin/mingetty tty4 974 root name=systemd:/user/lennart/2 login -- lennart 1824 lennart name=systemd:/user/lennart/2 \_ -bash 975 root name=systemd:/systemd-1/getty@.service/tty3 /sbin/mingetty tty3 988 root name=systemd:/systemd-1/polkitd.service /usr/libexec/polkit-1/polkitd 994 rtkit name=systemd:/systemd-1/rtkit-daemon.service /usr/libexec/rtkit-daemon
...