wiki/HowtoSystemd.md

---
categories: system sysadmin
title: Howto systemd
...

* Manpages : <https://www.freedesktop.org/software/systemd/man/index.html>

[systemd](https://www.freedesktop.org/wiki/Software/systemd/) est un gestionnaire de services (le fameux démon avec le PID 1) en alternative au System V. Il est installé par défaut depuis Debian 8. Son utilisation a suscitée des débats au sein de l'équipe, mais nous l'utilisons sur tous nos serveurs en Debian 8.


# Utilisation de base

## Statut systemd

Afficher le statut :

~~~
# systemctl status
~~~

Lister les unités qui tournent :

~~~
# systemctl
# systemctl list-units
~~~

Lister les unités en échecs :

~~~
# systemctl --failed
~~~

Lister les unités installées : 

~~~
# systemctl list-unit-files
~~~

> **Note** : Les unités sont dans `/usr/lib/systemd/system/` (emplacement par défaut) et `/etc/systemd/system/` (géré par l'administrateur).


## Gestion des unités

<https://www.freedesktop.org/software/systemd/man/systemd.unit.html>

Démarrer une unité :

~~~
# systemctl start <unité>
~~~

Arrêter une unité :

~~~
# systemctl stop <unité>
~~~

Redémarrer une unité : 

~~~
# systemctl restart <unité>
~~~

Recharger la configuration d'une unité : 

~~~
# systemctl reload <unité>
~~~

Afficher le statut d'une unité :

~~~
# systemctl status <unité>
# systemctl status <unité> -l
~~~

Savoir si une unité est activée ou non :

~~~
# systemctl is-enabled <unité>
~~~

> **Note** : Attention, si l'unité est en fait un script d'init dans `/etc/init.d/`, `is-enabled` ne fonctionne pas.

Activer une unité au boot : 

~~~
# systemctl enable <unité>
~~~

Désactiver une unité au boot : 

~~~
# systemctl disable <unité>
~~~

Masquer une unité, rendant impossible tout stop/start/… : 

~~~
# systemctl mask <unité>
~~~

Démasquer une unité : 

~~~
# systemctl unmask <unité>
~~~

Afficher la man page correspondante au service de l'unité : 

~~~
# systemctl help <unité>
~~~

Recharger systemd pour prendre en compte les unités modifiées : 

~~~
# systemctl daemon-reload
~~~


## Gestion de l'alimentation

Éteindre et redémarrer la machine : 

~~~
# systemctl reboot
~~~

Éteindre et couper l'alimentation de la machine : 

~~~
# systemctl poweroff
~~~


# Écriture des unités 

<https://www.freedesktop.org/software/systemd/man/systemd.service.html>

## Modifier une unité 

~~~
# cp -a /lib/systemd/system/<service>.service /etc/systemd/system/
# vim /etc/systemd/system/<service>.service
# systemctl daemon-reload
~~~

Exemple avec ssh.service sous Debian 8 :

~~~
[Unit]
Description=OpenBSD Secure Shell server
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Service]
EnvironmentFile=-/etc/default/ssh
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure

[Install]
WantedBy=multi-user.target
Alias=sshd.service
~~~

> **Note** : Chaque fois qu'une unité est modifiée, il est nécessaire de recharger systemd avec `systemctl daemon-reload`.


## Modifier partiellement une unité

On peut « override » une partie de l'unité en créant un fichier dans `/etc/systemd/system/unit.d/` qui précisera les modifications à faire.  
Exemple avec l'unité de _varnish_ :

Dossier `/etc/systemd/system/varnish.service.d`, fichier `/etc/systemd/system/varnish.service.d/varnish.service` :

~~~
[Service]
ExecStart=/usr/sbin/varnishd -a 0.0.0.0:80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,16G -p thread_pools=8 -p thread_pool_add_delay=2 -p thread_pool_min=500 -p thread_pool_max=5000
ExecReload=/etc/varnish/reload-vcl.sh
~~~
	
# Utiliser les templates d'unités

On peut créer/utiliser des templates d'unités. Cela permet de gérer à la volée des instances de services. Par exemple pour _redis_ via `/etc/systemd/system/redis@.service`.

~~~
[Unit]
Description=Advanced key-value store instance %i
After=network.target

[Service]
Type=forking
ExecStart=/usr/bin/redis-server /etc/redis/%i.conf
ExecStartPost=/bin/chgrp %i /var/run/redis/%i.sock
ExecStop=/usr/bin/redis-cli shutdown
Restart=always
User=redis
Group=%i

[Install]
WantedBy=multi-user.target
~~~

`%i` correspond au nom d'instance après le `@`.
On pourra ensuite démarrer l'instance foo et bar avec :

~~~
# systemctl start redis@foo redis@bar
~~~


# systemd par utilisateur

systemd fonctionne avec le PID 1. Mais il est aussi possible de lancer des instances par utilisateur avec le paramètre `--user`. C'est très pratique pour donner les droits à un utilisateur de gérer lui-même ses services (instances _Tomcat_ par exemple).  
Il faut avoir le paquet `libpam-systemd` installé : une session systemd est lancée quand on est connecté à la machine :

~~~
$ systemctl --user status
● bar
    State: running
     Jobs: 0 queued
   Failed: 0 units
    Since: ven. 2016-12-23 21:15:33 CET; 1 weeks 6 days ago
   CGroup: /user.slice/user-1001.slice/user@1001.service
           ├─1758 /lib/systemd/systemd --user
           └─1760 (sd-pam)  
~~~

Attention, si l'on veut une session permanente pour un utilisateur, il faut l'activer avec `loginctl` (si l'on ne fait pas cela, les services lancés via `systemctl --user` seront coupés à la déconnexion). Par exemple pour l'utilisateur _foo_ :

~~~
# loginctl enable-linger foo
~~~

Exemple d'unité utilisateur pour _Tomcat_ :

`/etc/systemd/user/tomcat.service`

~~~
[Unit]
Description=Tomcat %u.
After=network.target

[Service]
WorkingDirectory=/home/%u
Environment="CATALINA_BASE=/home/%u/tomcat"
EnvironmentFile=/home/%u/tomcat/conf/env
UMask=0002
ExecStart=/usr/share/tomcat7/bin/startup.sh
ExecStop=/usr/share/tomcat7/bin/shutdown.sh
ExecStopPost=/bin/sh -c date | /usr/bin/mail -s "%H/%u : Shutdown instance" foo@bar.com
Type=forking

[Install]
WantedBy=default.target
~~~

L'utilisateur pourra ainsi gérer lui-même le service :

~~~
$ systemctl --user enable tomcat
$ systemctl --user start tomcat
$ systemctl --user status -l tomcat
$ systemctl --user restart tomcat
$ systemctl --user stop tomcat
~~~

*Note* : pour pouvoir gérer `systemctl --user` via `sudo -iu foo`, on conseille de mettre dans `/etc/profile.d/systemd.sh` :

~~~
export XDG_RUNTIME_DIR="/run/user/$UID"
~~~

# Utilisation avancée
	
## Debug

Afficher plein d'informations sur l'unité :

~~~
# systemctl show <service>
~~~

_Debug_ au démarrage accessible sur _tty9_ :

~~~
# systemctl enable debug-shell
~~~

Débug d'une unité :

~~~
# systemctl stop unit
# SYSTEMD_LOG_LEVEL=debug /lib/systemd/unit
~~~

Analyser ce qui prend du temps au démarrage :

~~~	
# systemd-analyze 
Startup finished in 5.019s (firmware) + 6.128s (loader) + 5min 35.864s (kernel) + 20min 3.148s (userspace) = 25min 50.160s
# systemd-analyze blame | head -3
2.029s systemd-udev-settle.service
1.400s docker.service
1.215s uml-utilities.service
~~~

# Migrer de sysvinit à systemd

Cette action est souvent requise lorsque l'on migre de Debian Wheezy à Jessie.  

~~~
# apt install systemd-sysv
The following packages will be REMOVED:
sysvinit-core
# reboot
~~~

Vérifier que GRUB ne se lance pas avec l'option `init=/lib/sysvinit/init`.


# FAQ

## Bind9

Sous Debian 8, l'unité par défaut ne gère par les options dans `/etc/default/bind`.

Voir <http://trac.evolix.net/infogerance/wiki/HowtoDebian/MigrationWheezyJessie#Bind>

## strace Apache impossible

Une astuce efficace pour stracer un serveur de type Apache était : `strace -s65535 -ff /etc/init.d/apache2 restart`. Ensuite on joue la requête et on des infos (impossible à faire en prod bien sûr!).
Avec systemd, le strace ne suit pas les forks malgré `-ff`. À voir pourquoi systemd empêche ça…

## networking

Sous Debian 8, le démarrage du système se bloque complètement (dead lock) si l'initialisation de process dépendant du réseau (comme NFS, NTP, firewalling…) se fait avant que le réseau soit démarré.
Notamment quand ils sont démarrés via des hooks dans `/etc/network/if-*/`… Cela n'était pas bloquant avec SysV, cf https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754218#30

Astuces « bourrin » : ajouter `exit 0` dans `/etc/init.d/networking` et voir le souci via `systemctl status networking -l` ; modifier `JobTimeoutUSer` => `systemctl show networking -p JobTimeoutUSer`

## Failed to get D-Bus connection: Unknown error -1

Si en utilisant `systemctl` vous obtenez une erreur "Failed to get D-Bus connection: Unknown error -1" vérifiez si vous êtes bien passé à systemd et n'êtes resté à sysvinit !

## systemd-fsck : Dependency failed

Vous obtenez _systemd-fsck : Dependency failed for File System Check on /dev/disk/foo_ ?

Par défaut, `systemd-fsck` attend 1m30 l'accès à chaque device disque. Pour diverses raisons (accès à un SAN externe, etc.) cela peut échouer, vous aurez alors :

~~~
systemd[1]: Job dev-disk-by\x2dlabel-foo.device/start timed out.
systemd[1]: Timed out waiting for device dev-disk-by\x2dlabel-foo.device.
systemd[1]: Dependency failed for /backup.
systemd[1]: Dependency failed for Local File Systems.
systemd[1]: Triggering OnFailure= dependencies of local-fs.target.
systemd[1]: Dependency failed for File System Check on /dev/disk/by-label/foo.
~~~	

Vous pouvez alors ajouter différentes options via le fstab, du type :

~~~
LABEL=foo    /foo ext4    defaults,nofail,x-systemd.device-timeout=120 0 0
~~~	

Notamment `nofail` pour éviter que cela fasse échouer votre séquence de boot !

## systemd VS systemD VS SystemD

**systemd** ne prend aucune majuscule. Ce n'est pas SystemD ou systemD.