Service Management in Systemd

Mostra i comandi di base systemctl start e systemctl stop e spiega come persistono le modifiche allo stato.

Per avviare un servizio, utilizzare il comando systemctl start:

sudo systemctl start sshd

Per arrestare un servizio, utilizzare il comando systemctl stop:

sudo systemctl stop sshd

La modifica dello stato di un servizio dura solo mentre il sistema rimane allo stesso stato.

Se si arresta un servizio e quindi si modifica la destinazione dello stato del sistema su una destinazione in cui il servizio è configurato per l'esecuzione (ad esempio, effettuando il reboot del sistema), il servizio viene riavviato. Analogamente, l'avvio di un servizio non consente al servizio di avviarsi dopo un riavvio. Vedere Abilitazione e disabilitazione dei servizi.

Spiega come abilitare, disabilitare, mascherare e annullare la maschera dei servizi in modo che inizino (o rimangano fermati) durante il reboot.

È possibile utilizzare il comando systemctl per abilitare o disabilitare un servizio all'avvio al boot del sistema, ad esempio:

sudo systemctl enable httpd

Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service.

Il comando enable attiva un servizio creando un collegamento simbolico per la destinazione di stato del sistema di livello inferiore alla quale viene avviato il servizio. Nell'esempio precedente, il comando crea il collegamento simbolico httpd.service per la destinazione multi-user.

La disabilitazione di un servizio rimuove il collegamento simbolico:

sudo systemctl disable httpd

Removed /etc/systemd/system/multi-user.target.wants/httpd.service.

Per verificare se un servizio è abilitato, utilizzare il comando secondario is-enabled come illustrato negli esempi seguenti:

systemctl is-enabled httpd

disabled

systemctl is-enabled sshd

enabled

Dopo aver eseguito il comando systemctl disable, il servizio può comunque essere avviato o interrotto da account utente, script e altri processi.

Tuttavia, se è necessario assicurarsi che il servizio non possa essere avviato inavvertitamente, ad esempio da un servizio in conflitto, utilizzare il comando systemctl mask come indicato di seguito.

sudo systemctl mask httpd

Created symlink from '/etc/systemd/system/multi-user.target.wants/httpd.service' to '/dev/null'

Il comando mask imposta il riferimento al servizio su /dev/null. Se si tenta di avviare un servizio mascherato, si riceverà un errore come mostrato nell'esempio seguente:

sudo systemctl start httpd

Failed to start httpd.service: Unit is masked.

Per ricollegare il riferimento al servizio al file di configurazione dell'unità di servizio corrispondente, utilizzare il comando systemctl unmask:

sudo systemctl unmask httpd

Per ulteriori informazioni, vedere la pagina del manuale systemctl(1).

Dettagli dei comandi systemctl is-active e status per il controllo dell'integrità del servizio e dei gruppi di controllo.

Per verificare se un servizio è in esecuzione, utilizzare il comando secondario is-active. L'output sarebbe attivo o inattivo, come mostrato negli esempi riportati di seguito.

systemctl is-active httpd

active

systemctl is-active sshd

inactive

Il comando secondario status fornisce un riepilogo dettagliato dello stato di un servizio, incluso un albero che visualizza i task nel gruppo di controllo (CGroup) implementato dal servizio:

systemctl status httpd

httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: active (running) since ...
     Docs: man:httpd.service(8)
 Main PID: 11832 (httpd)
   Status: "Started, listening on: port 80"
    Tasks: 213 (limit: 26213)
   Memory: 32.5M
   CGroup: /system.slice/httpd.service
           ├─11832 /usr/sbin/httpd -DFOREGROUND
           ├─11833 /usr/sbin/httpd -DFOREGROUND
           ├─11834 /usr/sbin/httpd -DFOREGROUND
           ├─11835 /usr/sbin/httpd -DFOREGROUND
           └─11836 /usr/sbin/httpd -DFOREGROUND

Jul 17 00:14:32 Unknown systemd[1]: Starting The Apache HTTP Server...
Jul 17 00:14:32 Unknown httpd[11832]: Server configured, listening on: port 80
Jul 17 00:14:32 Unknown systemd[1]: Started The Apache HTTP Server.

Un cgroup è una raccolta di processi associati tra loro in modo da poter controllare l'accesso alle risorse di sistema. Nell'esempio, cgroup per il servizio httpd è httpd.service, che si trova nella slice system.

Le slice dividono cgroups in un sistema in categorie diverse. Per visualizzare la slice e la struttura gerarchica cgroup, utilizzare il comando systemd-cgls.

systemd-cgls

Control group /:
-.slice
├─user.slice
│ └─user-1000.slice
│   ├─user@1000.service
│   │ └─init.scope
│   │   ├─6488 /usr/lib/systemd/systemd --user
│   │   └─6492 (sd-pam)
│   └─session-7.scope
│     ├─6484 sshd: root [priv]
│     ├─6498 sshd: root@pts/0
│     ├─6499 -bash
│     ├─6524 sudo systemd-cgls
│     ├─6526 systemd-cgls
│     └─6527 less
├─init.scope
│ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 16
└─system.slice
  ├─rngd.service
  │ └─1266 /sbin/rngd -f --fill-watermark=0
  ├─irqbalance.service
  │ └─1247 /usr/sbin/irqbalance --foreground
  ├─libstoragemgmt.service
  │ └─1201 /usr/bin/lsmd -d
  ├─systemd-udevd.service
  │ └─1060 /usr/lib/systemd/systemd-udevd
  ├─polkit.service
  │ └─1241 /usr/lib/polkit-1/polkitd --no-debug
  ├─chronyd.service
  │ └─1249 /usr/sbin/chronyd
  ├─auditd.service
  │ ├─1152 /sbin/auditd
  │ └─1154 /usr/sbin/sedispatch
  ├─tuned.service
  │ └─1382 /usr/libexec/platform-python -Es /usr/sbin/tuned -l -P
  ├─systemd-journald.service
  │ └─1027 /usr/lib/systemd/systemd-journald
  ├─atd.service
  │ └─1812 /usr/sbin/atd -f
  ├─sshd.service
  │ └─1781 /usr/sbin/sshd

system.slice contiene servizi e altri processi di sistema. user.slice contiene processi utente che vengono eseguiti all'interno di cgroup transitori denominati scopi.

Nell'esempio, i processi per l'utente con ID 1000 vengono eseguiti nell'ambito session-7.scope nella slice /user.slice/user-1000.slice.

È possibile utilizzare il comando systemctl per limitare la CPU, l'I/O, la memoria e altre risorse disponibili per i processi nei cgroup di servizi e di ambito. Vedere Controllo dell'accesso alle risorse di sistema.

Per ulteriori informazioni, vedere le pagine del manuale systemctl(1) e systemd-cgls(1). Vedere anche Utilizzo di Systemd per la gestione dei gruppi di controllo.

Mostra come utilizzare systemctl set-property e systemd-run per assegnare limiti di CPU e memoria a servizi e ambiti.

Utilizzare il comando systemctl per controllare l'accesso di un cgroup alle risorse di sistema, ad esempio:

sudo systemctl [--runtime] set-property httpd CPUShares=512 MemoryLimit=1G

CPUShare controlla l'accesso alle risorse CPU. Poiché il valore predefinito è 1024, un valore pari a 512 dimezza l'accesso al tempo CPU di cui dispongono i processi in cgroup. Analogamente, MemoryLimit controlla la quantità massima di memoria che può essere utilizzata da cgroup.

In alternativa, è possibile modificare le impostazioni delle risorse per un servizio sotto l'intestazione [Service] nel file di configurazione del servizio in /usr/lib/systemd/system. Dopo aver modificato il file, fare in modo che systemd ricarichi i file di configurazione e quindi riavviare il servizio:

sudo systemctl daemon-reload
sudo systemctl restart service

È possibile eseguire comandi generali all'interno degli ambiti e utilizzare systemctl per controllare l'accesso di questi cgroup transitori alle risorse di sistema. Per eseguire un comando incluso in un ambito, utilizzare il comando systemd-run:

sudo systemd-run --scope --unit=group_name.scope [--slice=slice_name]

Se non si desidera creare il gruppo sotto la slice system predefinita, è possibile specificare un'altra slice o il nome di una nuova slice. L'esempio seguente esegue un comando denominato mymonitor in mymon.scope sotto myslice.slice:

sudo systemd-run --scope --unit=mymon.scope --slice=myslice mymonitor

Running as unit mymon.scope.

È quindi possibile utilizzare systemctl per controllare l'accesso di un ambito alle risorse di sistema allo stesso modo di un servizio. Tuttavia, a differenza di un servizio, è necessario specificare l'estensione .scope, ad esempio:

sudo systemctl --runtime set-property mymon.scope CPUShares=256

Per ulteriori informazioni, vedere Utilizzo di Systemd per la gestione dei gruppi di controllo e le pagine del manuale systemctl(1), systemd-cgls(1) e systemd.resource-control(5).

Descrive come eseguire l'override dei file delle unità pacchettizzate e creare snippet drop-in in /etc/systemd/system.

Per modificare la configurazione dei servizi systemd, copiare i file con le estensioni .service, .target, .mount e .socket da /usr/lib/systemd/system a /etc/systemd/system.

Dopo aver copiato i file, è possibile modificare le versioni in /etc/systemd/system.

I file in /etc/systemd/system hanno la precedenza sulle versioni in /usr/lib/systemd/system. I file in /etc/systemd/system non vengono sovrascritti quando si aggiorna un pacchetto che tocca i file in /usr/lib/systemd/system.

Per ripristinare la configurazione systemd predefinita per un determinato servizio, è possibile rinominare o eliminare le copie in /etc/systemd/system.

Un altro approccio per modificare la configurazione di un servizio è quello di creare un file drop-in. Con questo approccio, è possibile conservare l'unità originale modificando parametri specifici dell'unità.

Creare file drop-in in /etc/systemd/system/unit_name.d/, dove la directory unit_name.d è un'unità esistente, quindi assegnare ai file drop-in un'estensione di file .conf.

Ad esempio: /etc/systemd/system/unit_name.d/name_of_drop-in.conf. systemd legge il file .conf e applica le impostazioni all'unità originale.

Le sezioni seguenti descrivono le diverse parti di un file di unità di servizio che è possibile modificare e personalizzare per un sistema.