Differences

This shows you the differences between two versions of the page.

--- doc:appunti:linux:sa:systemd [2015/09/16 10:39] – [OpenVPN con systemd] niccolo
+++ doc:appunti:linux:sa:systemd [2023/12/13 12:36] – [Sostituto di rc.local] niccolo
@@ Line 1: / Line 1: @@
 ====== Systemd ======
+**[[wp>Systemd|systemd]]** è il nuovo sistema di avvio dei servizi adottato a partire da da **Debian 8 Jessie**. Sostituisce il vecchio **[[https://wiki.debian.org/Debate/initsystem/sysvinit|sysvinit]]**.
+===== Comandi di servizio =====
+Quando si modifica qualche file di configurazione (ad esempio gli //unit files// in ''/lib/systemd/system/'' oppure gli script di compatibilità con il vecchio //sysvinit// contenuti in ''/etc/init.d/'') è necessario notificare ''systemd'' in modo che rilegga tutte le dipendenze, ecc:
+<code>
+systemctl daemon-reload
+</code>
+Per vedere lo stato di una //unit// (ad esempio di un servizio) ed anche le ultime righe di log:
+<code>
+systemctl status snmpd.service
+● snmpd.service - LSB: SNMP agents
+   Loaded: loaded (/etc/init.d/snmpd)
+   Active: active (running) since Fri 2016-04-15 17:08:29 CEST; 3 weeks 6 days ago
+</code>
+Lo stato **loaded** significa che la //unit// è stata presa in carico da systemd, non che sia effettivamente avviata e in esecuzione.
+Lo stato di attivazione **active** oppure **inactive** indica se il servizio sta girando oppure no. I tradizionali script di start/stop in ''/etc/init.d/'' consentono di passare da uno stato all'altro, ma il metodo suggerito è il nuovo:
+<code>
+systemctl stop snmpd.service
+systemctl start snmpd.service
+</code>
+Per **disabilitare** o **abilitare** un servizio (quindi creare i vari link simbolici ''/etc/rc[0123456S].d/'' che attivano il processo ai vari runlevel:
+<code>
+systemctl disable snmpd.service
+systemctl enable snmpd.service
+</code>
+Contrariamente a quanto si potrebbe immaginare i comandi **status** o **is-enabled** non mostrando se il servizio è abilitato o disabilitato. È necessario ispezionare la proprietà **Before** con il comando **show**, che è differente nei due casi:
+<code>
+systemctl disable snmpd
+systemctl show snmpd.service | grep Before
+Before=shutdown.target
+systemctl enable snmpd
+systemctl show snmpd.service | grep Before
+Before=multi-user.target graphical.target shutdown.target
+</code>
 ===== OpenVPN con systemd =====
@@ Line 34: / Line 79: @@
 systemctl start openvpn
 </code>
+===== Unit file, service, device, target, ... =====
+Nella terminologia di //systemd// una **unit** è genericamente una risorsa che il sistema sa gestire. Tali risorse sono definite da alcuni file chiamati appunto **unit file**.
+Gli //unit file// vengono installati dai vari pacchetti nella directory **/lib/systemd/system/**. Se si desidera personalizzare qualcosa di uno unit file è opportuno farlo nella directory **/etc/systemd/system/**, che ha la precedenza su quella di sistema. Se si deve fornire solo dei piccoli snippet di configurazione è consigliato creare una cartella del tipo **/etc/systemd/system/example.service.d/** e metterci all'interno degli opportuni file **.conf**. Ricapitolando:
+  * **/lib/systemd/system/**
+  * **/etc/systemd/system/**
+  * **/etc/systemd/system/example.service.d/**
+Uno //unit file// può descrivere diversi tipi di risorsa, indicato dall'estensione del file stesso. I più comuni sono:
+^ .service | In genere una applicazione (demone) che fornisce un servizio. Contiene informazioni su quando attivarla, le dipendenze, ecc.  |
+^ .device  | Un device viene gestito da systemd in genere se è attivato da **udev** o **sysfs**.  |
+^ .taget   |
+===== Servizi enabled, disabled, masked, ... =====
+Le due condizioni più comuni per un servizio sono **enabled** o **disabled**, a seconda che debba essere avviato automaticamente al boot oppure no.
+La condizione **masked** di alcuni **unit file** è equivalente a //disabled//, ma previene anche l'avvio manuale del servizio. Se un file è disabled i suoi link simbolici sono rimossi, se è masked esso viene linkato a ''/dev/null''.
+===== Starting a service when a filesystem is available an mounted =====
+This solution was tested on **Debian 9 Stretch**.
+We have a filesystem on an **external USB disk**, which is not guaranteed to be present at bootstrap; to avoid hangs or errors during bootstrap, we have the following in **/etc/fstab**:
+<file>
+PARTUUID=92e84ecd-a306-44df-929b-... /data  ext4  auto,nofail  0  2
+</file>
+If the USB disk is not plugged during bootstrap, the filesystem is not mounted and there are not blocking errors (due the **nofail** option). We want to start a service (actually the Kodi Media Center) only if the filesystem is mounted. The relevant lines in the unit file **/etc/systemd/system/kodi.service** are:
+<file>
+# See man systemd.unit for the following directives.
+# This is equivalent of placing an "After" and "Requires" upon "data.mount";
+RequiresMountsFor = /data
+# When systemd starts or stops "data.mount", propagate action to this service.
+PartOf = data.mount
+</file>
+In this way, the Kodi service is not started if the USB disk is not connected. If the device is connected at a later time, the filesystem is automatically mounted and the Kodi service is automatically started.
+===== Modificare Ctrl-Alt-Del con Systemd =====
+Con il vecchio sistema di init **sysvinit** l'azione predefinita dei tasti **Ctrl-Alt-Del** era impostata nel file **/etc/inittab**.
+Nelle nuove versioni di Debian si utilizza **systemd** per l'init del sistema, il vecchio file di configurazione non esiste più. Ecco come associare un **poweroff** invece di un **reboot**:
+<code>
+ln -s /lib/systemd/system/poweroff.target /etc/systemd/system/ctrl-alt-del.target
+</code>
+=== Spiegazione ===
+Le operazioni predefinite sono definite dai file contenuti in **/lib/systemd/system/**, ad esempio si vede che esiste il link simbolico:
+<code>
+ctrl-alt-del.target -> reboot.target
+</code>
+Non è necessario modificare il contenuto di questa directory, si può fare un override creando il link simbolico opportuno nella directory **/etc/systemd/system/**. Invece del **reboot.target** si utilizza l'esistente **poweroff.target**.
+===== Timeout in attesa di un device =====
+Può capitare che il processo di **bootstrap fallisce** perché un device elencato in **/etc/fstab** non risulta disponibile nei tempi richiesti (lentezza del disco? CPU troppo veloce?). In questi casi si può aggiungere in /etc/fstab una opzione di montaggio:
+<file>
+/dev/sda3  /home  ext4  defaults,x-systemd.device-timeout=300s  0  2
+</file>
+===== Verifica Servizi =====
+Alcuni comandi utili per **verificare il funzionamento** dei servizi gestiti da **systemd**.
+Mostra lo stato di tutti i **servizi** e di tutte le **unit**:
+<code>
+systemctl --all --full status
+</code>
+Mostra le **unit** //required// e //wanted// dalla unit specificata:
+<code>
+systemctl --all list-dependencies ntp.service
+</code>
+===== Alternatriva allo script rc.local =====
+Come eseguire uno script all'avvio di un sisetma Systemd.
+Creare una unit Systemd **/etc/systemd/system/my-startup.service**:
+<file>
+# /etc/systemd/system/my-startup.service
+#
+# Service executed once the system has reached the multi-user status.
+#
+#  Type=oneshot         The unit is up after the main process exits.
+#  RemainAfterExit=yes  The service shall be considered active even
+#                       when all its processes exited.
+#
+# Eanble the service with:
+#   systemctl enable my-startup.service
+[Service]
+Type=oneshot
+RemainAfterExit=yes
+ExecStart=/usr/local/sbin/my-startup-script
+[Install]
+WantedBy=multi-user.target
+</file>
+Abilitare la unit e predisporre lo script **/usr/local/sbin/my-startup-script**.
+===== Riferimenti web =====
+  * **[[https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files|
+Understanding Systemd Units and Unit Files]]**
+  * **[[https://askubuntu.com/questions/710420/why-are-some-systemd-services-in-the-masked-state|Why are some systemd services in the “masked” state?]]**