systemd è una suite di demoni per la gestione del sistema, librerie ed utility progettate per dirigere centralmente e configurare il sistema operativo GNU/Linux.
Fornisce un gestore per il sistema ed i servizi che viene eseguito come PID 1 e avvia il resto del sistema come alternativa al tradizionale Sysvinit .
systemd fornisce funzionalità di parallelizzazione aggressive, è possibile attivare socket e D-Bus per i servizi che si stanno avviando, offre demoni che possono partire a richiesta,
Sta diventando lo standard per tutte le principali distribuzioni GNU/Linux ed al momento è il default per Arch Linux, Red Hat Enterprise/CentOS (versione 7), Fedora, Mageia e Suse Enterprise, è pianificato il suo utilizzo su Debian 8 ed Ubuntu 15.04.
Ci sono un sacco di persone che “parlano” a favore e contro systemd in rete in quanto alcuni lo vedono come troppo intrusivo, complesso e contro la la < a href=”http://en.wikipedia.org/wiki/Unix_philosophy”>filosofia Unix di mantenere le cose semplici e fare un solo compito con un programma.
Utilizzando Red Hat 7 al lavoro e Arch Linux sul mio portatile ho iniziato ad usarlo e devo dire che sono d’accordo che non è così semplice in partenza, ma cerchiamo di prendere le cose buone ed in questo articolo mi piacerebbe mostrarvi qualche comando che è possibile utilizzare con systemd per gestire i processi e che ho trovato molto utile.
Processesi e cgroups
systemd organizza i processi con cgroups ,questa è una caratteristica del kernel Linux per limitare, dare delle policy e gestire l’utilizzo delle risorse di alcuni processi (in realtà gruppi di processi). Rispetto ad altri approcci, come il comando ‘nice’ o /etc/security/limits.conf, i cgroups sono più flessibili.
I gruppi di controllo possono essere utilizzati in diversi modi:
- crearli e gestirli al volo utilizzando strumenti come
cgcreate,cgexec,cgclassifyetc - il “rules engine daemon”, per spostare automaticamente alcuni utenti/gruppi/gruppi di comandi (
/etc/cgrules.confe/usr/lib/systemd/system/cgconfig.service) - Attraverso dei software come i Linux Containers (LXC)
Quindi i Control Groups sono due cose: (A) un modo per dare una gerarchia ed etichette a gruppi di processi , e (B) un modo per applicare i limiti delle risorse a questi gruppi. systemd richiede solo la prima cosa (A), e non la seconda (B).
Questo uso dei cgroups si può vedere con il comando ps, che è stato aggiornato per mostrare cgroups. Utilizzare questo comando per vedere quale servizio possiede quale processo:
$ ps xawf -eo pid,user,cgroup,args PID USER CGROUP COMMAND 2 root - [kthreadd] 3 root - \_ [ksoftirqd/0] [...] 4281 root - \_ [flush-8:0] 1 root name=systemd:/systemd-1 /sbin/init 455 root name=systemd:/systemd-1/sysinit.service /sbin/udevd -d 28188 root name=systemd:/systemd-1/sysinit.service \_ /sbin/udevd -d 28191 root name=systemd:/systemd-1/sysinit.service \_ /sbin/udevd -d 1096 dbus name=systemd:/systemd-1/dbus.service /bin/dbus-daemon --system --address=systemd: --nofork --systemd-activation 1131 root name=systemd:/systemd-1/auditd.service auditd 1133 root name=systemd:/systemd-1/auditd.service \_ /sbin/audispd 1135 root name=systemd:/systemd-1/auditd.service \_ /usr/sbin/sedispatch 1171 root name=systemd:/systemd-1/NetworkManager.service /usr/sbin/NetworkManager --no-daemon 4028 root name=systemd:/systemd-1/NetworkManager.service \_ /sbin/dhclient -d -4 -sf /usr/libexec/nm-dhcp-client.action -pf /var/run/dhclient-wlan0.pid -lf /var/lib/dhclient/dhclient-7d32a784-ede9-4cf6-9ee3-60edc0bce5ff-wlan0.lease - 1175 avahi name=systemd:/systemd-1/avahi-daemon.service avahi-daemon: running [epsilon.local] 1194 avahi name=systemd:/systemd-1/avahi-daemon.service \_ avahi-daemon: chroot helper 1193 root name=systemd:/systemd-1/rsyslog.service /sbin/rsyslogd -c 4 1195 root name=systemd:/systemd-1/cups.service cupsd -C /etc/cups/cupsd.conf 1207 root name=systemd:/systemd-1/mdmonitor.service mdadm --monitor --scan -f --pid-file=/var/run/mdadm/mdadm.pid 1210 root name=systemd:/systemd-1/irqbalance.service irqbalance 1216 root name=systemd:/systemd-1/dbus.service /usr/sbin/modem-manager 1219 root name=systemd:/systemd-1/dbus.service /usr/libexec/polkit-1/polkitd 1242 root name=systemd:/systemd-1/dbus.service /usr/sbin/wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -B -u -f /var/log/wpa_supplicant.log -P /var/run/wpa_supplicant.pid 1249 68 name=systemd:/systemd-1/haldaemon.service hald 1250 root name=systemd:/systemd-1/haldaemon.service \_ hald-runner 1273 root name=systemd:/systemd-1/haldaemon.service \_ hald-addon-input: Listening on /dev/input/event3 /dev/input/event9 /dev/input/event1 /dev/input/event7 /dev/input/event2 /dev/input/event0 /dev/input/event8 1275 root name=systemd:/systemd-1/haldaemon.service \_ /usr/libexec/hald-addon-rfkill-killswitch 1284 root name=systemd:/systemd-1/haldaemon.service \_ /usr/libexec/hald-addon-leds 1285 root name=systemd:/systemd-1/haldaemon.service \_ /usr/libexec/hald-addon-generic-backlight 1287 68 name=systemd:/systemd-1/haldaemon.service \_ /usr/libexec/hald-addon-acpi 1317 root name=systemd:/systemd-1/abrtd.service /usr/sbin/abrtd -d -s 1332 root name=systemd:/systemd-1/getty@.service/tty2 /sbin/mingetty tty2 1339 root name=systemd:/systemd-1/getty@.service/tty3 /sbin/mingetty tty3 1342 root name=systemd:/systemd-1/getty@.service/tty5 /sbin/mingetty tty5 1343 root name=systemd:/systemd-1/getty@.service/tty4 /sbin/mingetty tty4 1344 root name=systemd:/systemd-1/crond.service crond ..... |
Nella terza colonna si vede il systemd cgroup assegnato ad ogni processo. Troverete che i processi udev utilizzano il nome = systemd: cgroup /systemd-1/sysinit.service, che è dove systemd mette tutti i processi avviati dal servizio sysinit.service, che copre l’avvio dei processi iniziali.
Un modo diverso di presentare le stesse informazioni è lo strumento systemd-cgls che viene fornito con systemd. Esso mostra la gerarchia cgroup in un bel albero. Il suo output è simile al seguente:
$ systemd-cgls + 2 [kthreadd] [...] + 4281 [flush-8:0] + user | \ lennart | \ 1 | + 1495 pam: gdm-password | + 1521 gnome-session | + 1534 dbus-launch --sh-syntax --exit-with-session | + 1535 /bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session | + 1603 /usr/libexec/gconfd-2 | + 1612 /usr/libexec/gnome-settings-daemon | + 1615 /ushr/libexec/gvfsd | + 1621 metacity | + 1626 /usr/libexec//gvfs-fuse-daemon /home/lennart/.gvfs | + 1634 /usr/bin/pulseaudio --start --log-target=syslog | + 1635 gnome-panel | + 1638 nautilus | + 1640 /usr/libexec/polkit-gnome-authentication-agent-1 | + 1641 /usr/bin/seapplet | + 1644 gnome-volume-control-applet | + 1645 /usr/libexec/bonobo-activation-server --ac-activate --ior-output-fd=24 | + 1646 /usr/sbin/restorecond -u | + 1649 /usr/libexec/pulse/gconf-helper | + 1652 /usr/bin/devilspie | + 1662 nm-applet --sm-disable | + 1664 gnome-power-manager | + 1665 /usr/libexec/gdu-notification-daemon | + 1668 /usr/libexec/im-settings-daemon | + 1670 /usr/libexec/evolution/2.32/evolution-alarm-notify | + 1672 /usr/bin/python /usr/share/system-config-printer/applet.py | + 1674 /usr/lib64/deja-dup/deja-dup-monitor | + 1675 abrt-applet | + 1677 bluetooth-applet | + 1678 gpk-update-icon | + 1701 /usr/libexec/gvfs-gdu-volume-monitor | + 1707 /usr/bin/gnote --panel-applet --oaf-activate-iid=OAFIID:GnoteApplet_Factory --oaf-ior-fd=22 | + 1725 /usr/libexec/clock-applet | + 1727 /usr/libexec/wnck-applet | + 1729 /usr/libexec/notification-area-applet | + 1759 gnome-screensaver | + 1780 /usr/libexec/gvfsd-trash --spawner :1.9 /org/gtk/gvfs/exec_spaw/0 | + 1864 /usr/libexec/gvfs-afc-volume-monitor | + 1874 /usr/libexec/gconf-im-settings-daemon | + 1882 /usr/libexec/gvfs-gphoto2-volume-monitor | + 1903 /usr/libexec/gvfsd-burn --spawner :1.9 /org/gtk/gvfs/exec_spaw/1 | + 1909 gnome-terminal | + 1913 gnome-pty-helper | + 1914 bash | + 1968 ssh-agent | + 1994 gpg-agent --daemon --write-env-file | + 2221 bash | + 2461 bash | + 4193 ssh tango | + 15113 bash | + 18679 /bin/sh /usr/lib64/firefox-3.6/run-mozilla.sh /usr/lib64/firefox-3.6/firefox | + 18741 /usr/lib64/firefox-3.6/firefox | + 27251 empathy | + 27262 /usr/libexec/mission-control-5 | + 27265 /usr/libexec/telepathy-haze | + 27268 /usr/libexec/telepathy-logger | + 27270 /usr/libexec/dconf-service | + 27280 /usr/libexec/notification-daemon | + 27284 /usr/libexec/telepathy-gabble | + 27285 /usr/libexec/telepathy-salut | + 27297 /usr/libexec/geoclue-yahoo | + 28900 /usr/lib64/nspluginwrapper/npviewer.bin --plugin /usr/lib64/mozilla/plugins/libflashplayer.so --connection /org/wrapper/NSPlugins/libflashplayer.so/18741-6 | + 29219 emacs systemd-for-admins-1.txt | + 29231 ssh tango | \ 29519 systemd-cgls \ systemd-1 + 1 /sbin/init + ntpd.service | \ 4112 /usr/sbin/ntpd -n -u ntp:ntp -g + systemd-logger.service | \ 1499 /lib/systemd/systemd-logger + accounts-daemon.service | \ 1496 /usr/libexec/accounts-daemon + rtkit-daemon.service | \ 1473 /usr/libexec/rtkit-daemon + console-kit-daemon.service | \ 1408 /usr/sbin/console-kit-daemon --no-daemon + prefdm.service | + 1376 /usr/sbin/gdm-binary -nodaemon | + 1391 /usr/libexec/gdm-simple-slave --display-id /org/gnome/DisplayManager/Display1 --force-active-vt | + 1394 /usr/bin/Xorg :0 -nr -verbose -auth /var/run/gdm/auth-for-gdm-f2KUOh/database -nolisten tcp vt1 | + 1419 /usr/bin/dbus-launch --exit-with-session | \ 1511 /usr/bin/gnome-keyring-daemon --daemonize --login + getty@.service | + tty6 | | \ 1346 /sbin/mingetty tty6 | + tty4 | | \ 1343 /sbin/mingetty tty4 | + tty5 | | \ 1342 /sbin/mingetty tty5 | + tty3 | | \ 1339 /sbin/mingetty tty3 | \ tty2 | \ 1332 /sbin/mingetty tty2 + abrtd.service | \ 1317 /usr/sbin/abrtd -d -s + crond.service | \ 1344 crond + sshd.service | \ 1362 /usr/sbin/sshd + sendmail.service | + 4094 sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue | \ 4096 sendmail: accepting connections + auditd.service | + 1131 auditd | + 1133 /sbin/audispd | \ 1135 /usr/sbin/sedispatch .... |
questo comando mostra i processi per il loro cgroup e quindi il servizio, come etichette systemd con i cgroups dopo i servizi. Ad esempio, si può facilmente vedere che il servizio auditd.service genera tre processi individuali, auditd, audisp e sedispatch.
Quando è necessario uccidere un servizio si può uccidere tramite il nome cgroup, in modo da non dover cercare tutti i PID o utilizzare comandi come killall o pgrep, come esempio per uccidere tutti i processi del servizio auditd è possibile utilizzare il comando :
# systemctl kill auditd.service
Questo farà sì che SIGTERM venga inviato a tutti i processi del servizio auditd, non solo al processo principale. Naturalmente, è possibile anche inviare un segnale diverso, se lo si desidera.
# systemctl kill -s SIGKILL auditd.service
A volte è sufficiente inviare un segnale specifico per il processo principale di un servizio, forse perché si vuole attivare una ripartenza via SIGHUP. Invece di ricercare il PID, ecco un modo più semplice per farlo:
# systemctl kill -s HUP –kill-who=main crond.service
E dal mio punto di vista questo è davvero ottimo!
Non più ps -ef | grep qualcosa | awk qualcosa | uccidi il risultato dell’awk 🙂
Analisi dell’uso delle risorse
Per comprendere l’utilizzo delle risorse di tutti i servizi, gli sviluppatori hanno creato lo strumento systemd systemd-cgtop , che mostrerà tutti cgroups del sistema, determina il loro utilizzo delle risorse (CPU, memoria, e IO) e le presenta con uno stile simile al comando top. Basandosi sul fatto che i servizi systemd sono gestiti in cgroups questo strumento, quindi, può presentare i servizi come top mostra i processi.
Purtroppo, per impostazione predefinita cgtop sarà solo in grado di tracciare l’utilizzo della CPU per-servizio, IO e memoria sono monitorati solo come totale per l’intera macchina. La ragione di questo è semplicemente che per default non ci sono cgroups per-service blkio e memory nelle gerarchie del controller, ma questo è ciò che è necessario per determinare l’utilizzo delle risorse.
Se è necessario il monitoraggio delle risorse per queste risorse si consiglia di aggiungere blkio e memory per il parametro DefaultControllers= in /etc/systemd/system.conf (vedi systemd.conf(5) per i dettagli). In alternativa, è possibile abilitare la risorsa di audit singolarmente per servizi, facendo uso dell’opzione ControlGroup= nei file unitari (Vedere systemd.exec (5) per i dettagli).
Per sottolineare questo: a meno che blkio e memory siano abilitati per i servizi in questione, con una delle opzioni suggerite sopra nessuna informazione sull’utilizzo delle risorse sarà disponibile per i servizi di sistema ed i dati mostrati da systemd-cgtop saranno incompleti.
Risorse
Managing Services on Linux with systemd
Dal creatore di systemd:
- Rethinking PID 1
- systemd for Administrators, Part 1
- systemd for Administrators, Part II
- systemd for Administrators, Part III
- systemd for Administrators, Part IV
- systemd for Administrators, Part V
- systemd for Administrators, Part VI
- systemd for Administrators, Part VII
- systemd for Administrators, Part VIII
- systemd for Administrators, Part IX
- systemd for Administrators, Part X
- systemd for Administrators, Part XI
Popular Posts:
- None Found
What? No comments in three days? And we were told that systemd was soooo popular an very much appreciated by Linux users worldwide!
Great article!
One question, though: when I create a service through systemd, does it automatically generates its own cgroup? I am curious about it because I configured microservices (2 standalone jars) to run as services (using systemd). When I execute systemctl -l status service1 It outputs some description showing a main PID, and a cgroup tree, describing the service file path I configured, a sh file path that I also created and finally the jar file path I am running as a microservices. Does this microservice, in this cenario, have isolated resources as in a container approach (such as Docker)?
Thanks!!