Prozessmanagement mit systemd im Userspace: Unterschied zwischen den Versionen
| (44 dazwischenliegende Versionen von 6 Benutzern werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
'' | == Über systemd == | ||
''systemd'' ist seit einigen Jahren das Init-System aller gängigen Linux-Distributionen. Der ''init''-Prozess hat im laufenden System die Prozessnummer "1". Er verwaltet alle anderen Prozesse als Kind-Prozesse. | |||
Auch ein normaler Account ohne besondere Privilegien kann | Auch ein normaler Account ohne besondere Privilegien kann systemd nutzen, um Prozesse im Userspace zu starten und zu kontrollieren. Auf der Hostsharing Managed Operations Platform kann jeder Account mit einer gültigen Login-Shell Dienste unter der Kontrolle von systemd starten. | ||
Im Hostsharing Managed Webspace ist es zwingend, systemd als Prozessmonitor für eigene Serverdienste zu nutzen; auf einem Hostsharing Managed Server ist es die empfohlene Vorgehensweise ("Best practice"). | |||
== Eigene Serverdienste mit systemd == | |||
Die systemd-Konfiguration wird in dem Verzeichnis des Benutzers eingerichtet, unter dem die Anwendung laufen soll. | |||
In diesem Beispiel soll die Anwendung GotoSocial unter der Benutzerkennung von ''xyz00-service'' laufen. | |||
Nachdem die Anwendung im Benutzer ''xyz00-service'' installiert wurde, erfolgt nun die Konfiguration von systemd in demselben Benutzer. | |||
Benutzer, die systemd steuern sollen, müssen über eine gültige Shell verfügen, so dass man sich per ''ssh'' oder vom Paketadmin mit dem Befehl ''sudo -i -u xyz00-service'' anmelden kann. | |||
Die Umgebungsvariable ''XDG_RUNTIME_DIR'' sollte im Environment des Users gesetzt sein, wenn man erfolgreich angemeldet ist. Das testet man mit | |||
<syntaxhighlight lang="bash"> | <syntaxhighlight lang="bash"> | ||
| Zeile 43: | Zeile 29: | ||
Dabei wird statt ''112345'' eine andere Zahl erscheinen. Diese Zahl ist die numerische User-Id des Users ''xyz00-service'' im System. | Dabei wird statt ''112345'' eine andere Zahl erscheinen. Diese Zahl ist die numerische User-Id des Users ''xyz00-service'' im System. | ||
=== | === systemd Units === | ||
Die | Die systemd-Units für einen User werden im Verzeichnis ''$HOME/.config/systemd/user/'' verwaltet. Dieser Pfad ist fest vorgegeben. Der Pfad muss bei einem neuen Benutzer angelegt werden. | ||
<syntaxhighlight lang="bash"> | <syntaxhighlight lang="bash"> | ||
| Zeile 51: | Zeile 37: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
In diesem Verzeichnis wird für jeden Service eine Datei mit der Endung ''.service'' angelegt. | In diesem Verzeichnis wird für jeden Service eine Datei mit der Endung ''.service'' angelegt. In diesem Beispiel ist dies eine GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmiersprache ''Go'' programmiert ist. | ||
<syntaxhighlight lang="ini" line> | <syntaxhighlight lang="ini" line> | ||
[Unit] | [Unit] | ||
Description=GotoSocial Service | Description=GotoSocial Service | ||
#After=my-redis.service | |||
[Service] | [Service] | ||
| Zeile 62: | Zeile 49: | ||
Environment="PATH=/usr/local/bin:/usr/bin:/bin" | Environment="PATH=/usr/local/bin:/usr/bin:/bin" | ||
ExecStart=%h/gotosocial/gotosocial --config-path %h/gotosocial/config.yaml server start | ExecStart=%h/gotosocial/gotosocial --config-path %h/gotosocial/config.yaml server start | ||
StandardOutput= | StandardOutput=append:%h/var/gotosocial.log | ||
StandardError=inherit | StandardError=inherit | ||
Restart=always | Restart=always | ||
| Zeile 71: | Zeile 58: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
Folgende Eigenschaften sind einstellbar: | |||
; After: Hier kann eingestellt werden, welcher Dienst bereits laufen muss, bevor dieser Dienst gestartet wird. Wenn GotoSocial eine Redis-Instanz benötigt, könnte das entsprechend eingestellt werden. | |||
; Type=simple : ''simple'' ist die Voreinstellung und kann weggelassen werden. Evtl. braucht man auch ''forking'', wenn ein Dienst als Daemon im Hintergrund startet. Wenn man die Wahl hat, sollte man den Dienst immer im Vordergrund starten und nicht forken. | ; Type=simple : ''simple'' ist die Voreinstellung und kann weggelassen werden. Evtl. braucht man auch ''forking'', wenn ein Dienst als Daemon im Hintergrund startet. Wenn man die Wahl hat, sollte man den Dienst immer im Vordergrund starten und nicht forken. | ||
; WorkingDirectory : ist das Verzeichnis, in dem der Dienst gestartet wird. %h ist in dieser Datei eine Abkürzung für das Home-Verzeichnis des Users. | ; WorkingDirectory : ist das Verzeichnis, in dem der Dienst gestartet wird. %h ist in dieser Datei eine Abkürzung für das Home-Verzeichnis des Users. | ||
; Environment : Hier wird die Variable ''PATH'' definiert. Man kann mehrere Einträge des Namens ''Environment'' eintragen und bei Bedarf eine beliebige Anzahl von Environment-Variablen definieren. | ; Environment : Hier wird die Variable ''PATH'' definiert. Man kann mehrere Einträge des Namens ''Environment'' eintragen und bei Bedarf eine beliebige Anzahl von Environment-Variablen definieren. | ||
; ExecStart : Das Programm, das als Dienst ausgeführt wird. Man kann eine komplette Kommandozeile angeben. | ; ExecStart : Das Programm, das als Dienst ausgeführt wird. Man kann eine komplette Kommandozeile angeben. | ||
; StandardOutput : Eine Log-Datei in die die Standardausgabe des laufenden Dienstes geschrieben wird. | ; StandardOutput : Eine Log-Datei, in die die Standardausgabe des laufenden Dienstes geschrieben wird. | ||
; StandardError : Entsprechend zu ''StandardOutput''. Mit ''inherit'' wird | ; StandardError : Entsprechend zu ''StandardOutput''. Mit ''inherit'' wird die Datei von ''StandardOutput'' geerbt. | ||
; Restart=always : Der Dienst soll grundsätzlich neu gestartet werden, wenn der Prozess unerwartet beendet wird. | ; Restart=always : Der Dienst soll grundsätzlich neu gestartet werden, wenn der Prozess unerwartet beendet wird. | ||
; PrivateTmp=true : ''/tmp'' und ''/var/tmp'' werden temporär im Namespace gemountet, so dass sie nicht mit anderen Prozessen geteilt werden. | ; PrivateTmp=true : ''/tmp'' und ''/var/tmp'' werden temporär im Namespace gemountet, so dass sie nicht mit anderen Prozessen geteilt werden. | ||
; WantedBy : | ; WantedBy : sollte im Usermodus von systemd meistens ''default.target'' sein. Andere Targets sind z.B. ''base.target'' oder ''timers.target''. Für eine komplette Liste: <code>systemctl list-units --user --type=target</code> | ||
=== RAM- und CPU-Limits === | ==== RAM- und CPU-Limits ==== | ||
Auf Wunsch kann man die RAM- und CPU-Ressourcen für den Dienst begrenzen. Dazu trägt man weitere Eigenschaften im Abschnitt ''Service'' ein: | Auf Wunsch kann man die RAM- und CPU-Ressourcen für den Dienst begrenzen. Dazu trägt man weitere Eigenschaften im Abschnitt ''Service'' ein: | ||
| Zeile 101: | Zeile 89: | ||
; CPUQuota : Maximale Belegung eines CPU-Threads in Prozent. Werte über 100% sind sinnvoll, wenn mehr als ein CPU-Thread verfügbar ist. | ; CPUQuota : Maximale Belegung eines CPU-Threads in Prozent. Werte über 100% sind sinnvoll, wenn mehr als ein CPU-Thread verfügbar ist. | ||
=== | ==== Ausführliche Dokumentation der Direktiven ==== | ||
Eine ausführliche Dokumentation der Direktiven findet sich hier: | |||
https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html | |||
=== systemd Unit starten und stoppen === | |||
Nachdem die systemd-Unit definiert ist, soll der Dienst gestartet werden. | |||
Für die Verwaltung des Dienstes stehen die folgenden Kommandos zur Verfügung: | Für die Verwaltung des Dienstes stehen die folgenden Kommandos zur Verfügung: | ||
| Zeile 128: | Zeile 122: | ||
==== Enable und Disable ==== | ==== Enable und Disable ==== | ||
Wenn ein Dienst nach einem Reboot des Servers automatisch gestartet werden soll, muss er aktiviert werden: | |||
<syntaxhighlight lang="bash"> | <syntaxhighlight lang="bash"> | ||
| Zeile 133: | Zeile 129: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
Wenn er nicht automatisch nach einem Reboot starten soll, muss der Dienst entsprechend deaktiviert werden: | |||
<syntaxhighlight lang="bash"> | <syntaxhighlight lang="bash"> | ||
| Zeile 154: | Zeile 150: | ||
zeigen den Status aller Dienste des Users bzw. eines bestimmten Dienstes an. | zeigen den Status aller Dienste des Users bzw. eines bestimmten Dienstes an. | ||
== Zeitgesteuerte Ausführung mit systemd == | |||
Mit Hilfe von systemd können auch wiederkehrende Aufgaben zeitgesteuert automatisiert werden. | |||
Cronjobs, die früher für solche Zwecke benutzt wurden, lassen sich also durch systemd Units ersetzen. | |||
Neben dem »service-file« wird dazu eine weitere Unit, nämlich ein »timer-file«, mit der Endung ».timer« angelegt und aktiviert. | |||
=== Einrichten des »service-files« === | |||
<syntaxhighlight lang=bash> | |||
$ cat $HOME/.config/systemd/user/my-cleanup.service | |||
[Unit] | |||
Description=My Cleanup Service | |||
[Service] | |||
Type=oneshot | |||
ExecStart=%h/bin/cleanup-script | |||
</syntaxhighlight> | |||
=== Testen === | |||
<syntaxhighlight lang=bash> | |||
$ systemctl --user start my-cleanup.service | |||
</syntaxhighlight> | |||
=== Einrichten des »timer-files« === | |||
<syntaxhighlight lang=bash> | |||
$ cat $HOME/.config/systemd/user/my-cleanup.timer | |||
[Unit] | |||
Description=Daily My Cleanup Timer | |||
[Timer] | |||
OnCalendar=daily | |||
RandomizedDelaySec=3600 | |||
Persistent=true | |||
[Install] | |||
WantedBy=timers.target | |||
</syntaxhighlight> | |||
Der RandomizedDelay bewirkt, dass der Prozess zufällig im Zeitraum einer Stunde gestartet wird. | |||
Wenn mehrere Timer-Aufgaben täglich (daily) auf einem System gestartet werden, verhindert diese Einstellung, dass alle Prozesse exakt zur gleichen Zeit starten und das System eventuell überlasten. | |||
Die zufällige Verzögerung sollte in einem sinnvollen Verhältnis zur Frequenz der Zeitsteuerung erfolgen. | |||
Bei täglich ausgeführten Aufgaben mag eine Stunde (3600 Sekunden) sinnvoll sein. | |||
Bei Aufgaben, die stündlich ausgeführt werden, wählt man eine kürzere Verzögerung, zum Beispiel fünf Minuten. | |||
Die Syntax der Datei lässt sich mit diesem Befehl prüfen: | |||
<syntaxhighlight lang=bash> | |||
systemd-analyze verify $HOME/.config/systemd/user/my-cleanup.timer | |||
</syntaxhighlight> | |||
Einzelne Kalendereinträge lassen sich mit Erklärung ausgeben: | |||
<syntaxhighlight lang=bash> | |||
systemd-analyze calendar '*:0/2' | |||
</syntaxhighlight> | |||
Eine ausführliche Dokumentation der Direktiven findet sich hier: | |||
https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html | |||
=== Aktivieren der zeitgesteuerten Ausführung === | |||
Der Timer muss noch aktiviert und gestartet werden: | |||
<syntaxhighlight lang=bash> | |||
$ systemctl --user enable my-cleanup.timer --now | |||
</syntaxhighlight> | |||
== RAM Kontingent eines Webspace == | |||
Den aktuell belegten RAM eines Webspace ''xyz00'' kann man sich mit dem Befehl | |||
<syntaxhighlight lang="bash"> | |||
systemctl status pacs-xyz00.slice | |||
</syntaxhighlight> | |||
ansehen. | |||
Etwa in der fünften Zeile der Ausgabe findet man eine Angabe der Form: | |||
<syntaxhighlight lang="bash"> | |||
Memory: 58.4M (max: 14.8G available: 14.8G) | |||
</syntaxhighlight> | |||
Hier sind aktuell 58,4 Megabyte RAM genutzt, es sind 14,8 Gigabyte RAM für den Webspace verfügbar. Der verfügbare RAM ist das gebuchte Kontingent. Das gebuchte Kontigent wird im Shared Hosting deutlich kleiner sein. | |||
Das RAM Kontingent wird in Schritten von jeweils 128 Ḿegabyte gebucht. Änderungen des RAM Kontingents für einen Webspace nimmt der Service unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist. | |||
= weiterführende Links = | |||
* https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html | |||
* https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html | |||
* https://documentation.suse.com/smart/systems-management/html/systemd-working-with-timers/index.html#systemd-timer-catchup | |||
* https://wiki.archlinux.org/title/Systemd/Timers#As_a_cron_replacement | |||
---- | |||
[[Kategorie:systemd]] | |||
[[Kategorie:Eigene Daemons]] | |||
Aktuelle Version vom 3. Dezember 2024, 01:18 Uhr
Über systemd
systemd ist seit einigen Jahren das Init-System aller gängigen Linux-Distributionen. Der init-Prozess hat im laufenden System die Prozessnummer "1". Er verwaltet alle anderen Prozesse als Kind-Prozesse.
Auch ein normaler Account ohne besondere Privilegien kann systemd nutzen, um Prozesse im Userspace zu starten und zu kontrollieren. Auf der Hostsharing Managed Operations Platform kann jeder Account mit einer gültigen Login-Shell Dienste unter der Kontrolle von systemd starten.
Im Hostsharing Managed Webspace ist es zwingend, systemd als Prozessmonitor für eigene Serverdienste zu nutzen; auf einem Hostsharing Managed Server ist es die empfohlene Vorgehensweise ("Best practice").
Eigene Serverdienste mit systemd
Die systemd-Konfiguration wird in dem Verzeichnis des Benutzers eingerichtet, unter dem die Anwendung laufen soll. In diesem Beispiel soll die Anwendung GotoSocial unter der Benutzerkennung von xyz00-service laufen. Nachdem die Anwendung im Benutzer xyz00-service installiert wurde, erfolgt nun die Konfiguration von systemd in demselben Benutzer.
Benutzer, die systemd steuern sollen, müssen über eine gültige Shell verfügen, so dass man sich per ssh oder vom Paketadmin mit dem Befehl sudo -i -u xyz00-service anmelden kann. Die Umgebungsvariable XDG_RUNTIME_DIR sollte im Environment des Users gesetzt sein, wenn man erfolgreich angemeldet ist. Das testet man mit
echo $XDG_RUNTIME_DIR
Die Ausgabe sollte sein:
xyz00-service@h01:~$ echo $XDG_RUNTIME_DIR
/run/user/112345
xyz00-service@h01:~$
Dabei wird statt 112345 eine andere Zahl erscheinen. Diese Zahl ist die numerische User-Id des Users xyz00-service im System.
systemd Units
Die systemd-Units für einen User werden im Verzeichnis $HOME/.config/systemd/user/ verwaltet. Dieser Pfad ist fest vorgegeben. Der Pfad muss bei einem neuen Benutzer angelegt werden.
mkdir -p $HOME/.config/systemd/user
In diesem Verzeichnis wird für jeden Service eine Datei mit der Endung .service angelegt. In diesem Beispiel ist dies eine GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmiersprache Go programmiert ist.
[Unit]
Description=GotoSocial Service
#After=my-redis.service
[Service]
Type=simple
WorkingDirectory=%h/gotosocial
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
ExecStart=%h/gotosocial/gotosocial --config-path %h/gotosocial/config.yaml server start
StandardOutput=append:%h/var/gotosocial.log
StandardError=inherit
Restart=always
PrivateTmp=true
[Install]
WantedBy=default.target
Folgende Eigenschaften sind einstellbar:
- After
- Hier kann eingestellt werden, welcher Dienst bereits laufen muss, bevor dieser Dienst gestartet wird. Wenn GotoSocial eine Redis-Instanz benötigt, könnte das entsprechend eingestellt werden.
- Type=simple
- simple ist die Voreinstellung und kann weggelassen werden. Evtl. braucht man auch forking, wenn ein Dienst als Daemon im Hintergrund startet. Wenn man die Wahl hat, sollte man den Dienst immer im Vordergrund starten und nicht forken.
- WorkingDirectory
- ist das Verzeichnis, in dem der Dienst gestartet wird. %h ist in dieser Datei eine Abkürzung für das Home-Verzeichnis des Users.
- Environment
- Hier wird die Variable PATH definiert. Man kann mehrere Einträge des Namens Environment eintragen und bei Bedarf eine beliebige Anzahl von Environment-Variablen definieren.
- ExecStart
- Das Programm, das als Dienst ausgeführt wird. Man kann eine komplette Kommandozeile angeben.
- StandardOutput
- Eine Log-Datei, in die die Standardausgabe des laufenden Dienstes geschrieben wird.
- StandardError
- Entsprechend zu StandardOutput. Mit inherit wird die Datei von StandardOutput geerbt.
- Restart=always
- Der Dienst soll grundsätzlich neu gestartet werden, wenn der Prozess unerwartet beendet wird.
- PrivateTmp=true
- /tmp und /var/tmp werden temporär im Namespace gemountet, so dass sie nicht mit anderen Prozessen geteilt werden.
- WantedBy
- sollte im Usermodus von systemd meistens default.target sein. Andere Targets sind z.B. base.target oder timers.target. Für eine komplette Liste:
systemctl list-units --user --type=target
RAM- und CPU-Limits
Auf Wunsch kann man die RAM- und CPU-Ressourcen für den Dienst begrenzen. Dazu trägt man weitere Eigenschaften im Abschnitt Service ein:
[Service]
...
MemoryAccounting=true
CPUAccounting=true
MemoryHigh=512M
MemoryMax=768M
CPUQuota=50%
- MemoryHigh
- Weiches RAM-Limit, das ggf. überschritten werden kann, wenn es unvermeidlich ist.
- MemoryMax
- Hartes, absolutes RAM-Limit.
- CPUQuota
- Maximale Belegung eines CPU-Threads in Prozent. Werte über 100% sind sinnvoll, wenn mehr als ein CPU-Thread verfügbar ist.
Ausführliche Dokumentation der Direktiven
Eine ausführliche Dokumentation der Direktiven findet sich hier:
https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html
systemd Unit starten und stoppen
Nachdem die systemd-Unit definiert ist, soll der Dienst gestartet werden. Für die Verwaltung des Dienstes stehen die folgenden Kommandos zur Verfügung:
Reload
systemctl --user daemon-reload
Die Konfigurationsdateien im Verzeichnis $HOME/.config/systemd/user/ werden neu eingelesen. Dieses Kommando ist nach jeder Änderung einer .service-Datei nötig.
Start und Stopp
systemctl --user start gotosocial.service
bzw.
systemctl --user stop gotosocial.service
sind die Kommandos zum Starten und Beenden des Dienstes.
Enable und Disable
Wenn ein Dienst nach einem Reboot des Servers automatisch gestartet werden soll, muss er aktiviert werden:
systemctl --user enable gotosocial.service
Wenn er nicht automatisch nach einem Reboot starten soll, muss der Dienst entsprechend deaktiviert werden:
systemctl --user disable gotosocial.service
sind die Kommandos, die den Dienst für einen Reboot des Servers aktivieren bzw. deaktivieren.
Status
systemctl --user status
oder
systemctl --user status gotosocial.service
zeigen den Status aller Dienste des Users bzw. eines bestimmten Dienstes an.
Zeitgesteuerte Ausführung mit systemd
Mit Hilfe von systemd können auch wiederkehrende Aufgaben zeitgesteuert automatisiert werden. Cronjobs, die früher für solche Zwecke benutzt wurden, lassen sich also durch systemd Units ersetzen. Neben dem »service-file« wird dazu eine weitere Unit, nämlich ein »timer-file«, mit der Endung ».timer« angelegt und aktiviert.
Einrichten des »service-files«
$ cat $HOME/.config/systemd/user/my-cleanup.service
[Unit]
Description=My Cleanup Service
[Service]
Type=oneshot
ExecStart=%h/bin/cleanup-script
Testen
$ systemctl --user start my-cleanup.service
Einrichten des »timer-files«
$ cat $HOME/.config/systemd/user/my-cleanup.timer
[Unit]
Description=Daily My Cleanup Timer
[Timer]
OnCalendar=daily
RandomizedDelaySec=3600
Persistent=true
[Install]
WantedBy=timers.target
Der RandomizedDelay bewirkt, dass der Prozess zufällig im Zeitraum einer Stunde gestartet wird. Wenn mehrere Timer-Aufgaben täglich (daily) auf einem System gestartet werden, verhindert diese Einstellung, dass alle Prozesse exakt zur gleichen Zeit starten und das System eventuell überlasten.
Die zufällige Verzögerung sollte in einem sinnvollen Verhältnis zur Frequenz der Zeitsteuerung erfolgen. Bei täglich ausgeführten Aufgaben mag eine Stunde (3600 Sekunden) sinnvoll sein. Bei Aufgaben, die stündlich ausgeführt werden, wählt man eine kürzere Verzögerung, zum Beispiel fünf Minuten.
Die Syntax der Datei lässt sich mit diesem Befehl prüfen:
systemd-analyze verify $HOME/.config/systemd/user/my-cleanup.timer
Einzelne Kalendereinträge lassen sich mit Erklärung ausgeben:
systemd-analyze calendar '*:0/2'
Eine ausführliche Dokumentation der Direktiven findet sich hier:
https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html
Aktivieren der zeitgesteuerten Ausführung
Der Timer muss noch aktiviert und gestartet werden:
$ systemctl --user enable my-cleanup.timer --now
RAM Kontingent eines Webspace
Den aktuell belegten RAM eines Webspace xyz00 kann man sich mit dem Befehl
systemctl status pacs-xyz00.slice
ansehen.
Etwa in der fünften Zeile der Ausgabe findet man eine Angabe der Form:
Memory: 58.4M (max: 14.8G available: 14.8G)
Hier sind aktuell 58,4 Megabyte RAM genutzt, es sind 14,8 Gigabyte RAM für den Webspace verfügbar. Der verfügbare RAM ist das gebuchte Kontingent. Das gebuchte Kontigent wird im Shared Hosting deutlich kleiner sein.
Das RAM Kontingent wird in Schritten von jeweils 128 Ḿegabyte gebucht. Änderungen des RAM Kontingents für einen Webspace nimmt der Service unter service@hostsharing.net entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.
weiterführende Links
- https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html
- https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html
- https://documentation.suse.com/smart/systems-management/html/systemd-working-with-timers/index.html#systemd-timer-catchup
- https://wiki.archlinux.org/title/Systemd/Timers#As_a_cron_replacement