> **Note* : Chaque fois qu'une unité est modifié, 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.
La meilleure méthode pour faire ceci est d'utiliser `systemctl edit <unit>`.
Exemple avec ElasticSearch : TODO
# 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`.
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 instaces 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).
Dans un premier temps il faut s'assurer d'avoir le paquet `libpam-systemd` installé. Ensuite si l'on veut que l'utilisateur `foo` ait toujours une session ouverte (pour faire tourner un service) il faut utiliser loginctl :
~~~
# loginctl enable-linger foo
~~~
De cette façon systemd tournera toujours même si l'utilisateur n'est pas connecté.
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…
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"
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 !
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 :