Systemctl

Aus Foxwiki
Subpages:

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. 

[[Image:Bild1.png|top]]

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: 

 # ln -sf /usr/lib/systemd/system/multi-user.target /etc/systemd/system/default.target

or 

 # ln -sf /usr/lib/systemd/system/graphical.target /etc/systemd/system/default.target

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: 

 $ systemctl list-units --type=target

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? 

# journalctl --full

/tmp and tmpfs

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
...
Abgerufen von „https://wiki.foxtom.de/index.php?title=Systemctl&oldid=29899“