From 31965364cbb0e86e2dd42748ab5b4385e57842ac Mon Sep 17 00:00:00 2001 From: gcolpart Date: Sat, 7 Jan 2017 15:43:14 +0100 Subject: [PATCH] relecture --- HowtoSystemd.md | 129 ++++++++++++++++++++++++++++-------------------- 1 file changed, 75 insertions(+), 54 deletions(-) diff --git a/HowtoSystemd.md b/HowtoSystemd.md index b8526e5b..d8bbf818 100644 --- a/HowtoSystemd.md +++ b/HowtoSystemd.md @@ -37,28 +37,18 @@ 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). +> *Note* : Les unités sont par défaut dans `/usr/lib/systemd/system/` et `/etc/systemd/system/` (gestion manuelle) ## Gestion des unités -Démarrer une unité : +Démarrer/arrêter/redémarrer une unité : ~~~ # systemctl start -~~~ - -Arrêter une unité : - -~~~ # systemctl stop -~~~ - -Redémarrer une unité : - -~~~ # systemctl restart ~~~ @@ -81,29 +71,19 @@ Savoir si une unité est activée ou non : # systemctl is-enabled ~~~ -> **Note** : Attention, si l'unité est en fait un script d'init dans `/etc/init.d/`, `is-enabled` ne fonctionne pas. +> *Note* : Attention, pour les pseudo-unités (qui sont en fait des scripts dans `/etc/init.d/`), `is-enabled` ne fonctionne pas. -Activer une unité au boot : +Activer/désactiver une unité au boot : ~~~ # systemctl enable -~~~ - -Désactiver une unité au boot : - -~~~ # systemctl disable ~~~ -Masquer une unité, rendant impossible tout stop/start/… : +Masquer/démasquer une unité (_mask_ rend impossible tout stop/start/…) : ~~~ # systemctl mask -~~~ - -Démasquer une unité : - -~~~ # systemctl unmask ~~~ @@ -120,22 +100,28 @@ Recharger systemd pour prendre en compte les unités modifiées : ~~~ -## Gestion de l'alimentation +## Redémarrer ou éteindre un serveur -Éteindre et redémarrer la machine : +Avec systemd, les commandes halt/poweroff/shutdown/reboot n'existent plus ! +Ce sont des désormais des liens symboliques vers **systemctl**. +On conseille donc d'utiliser directement les commandes « natives ». + +Redémarrer le serveur : ~~~ # systemctl reboot ~~~ -Éteindre et couper l'alimentation de la machine : +Éteindre et couper l'alimentation du serveur : ~~~ # systemctl poweroff ~~~ +> *Note* : l'option `--force` permet de killer tous les process sans attendre leur extinction propre (à éviter bien sûr) -# Écriture des unités + +# Rédaction des unités @@ -172,8 +158,7 @@ Alias=sshd.service ## 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_ : +Au lieu de tout ré-écrire, 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` : @@ -182,10 +167,13 @@ Dossier `/etc/systemd/system/varnish.service.d`, fichier `/etc/systemd/system/va 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`. +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] @@ -230,7 +218,7 @@ $ systemctl --user status └─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_ : +Attention, si l'on veut une session persistante 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 @@ -275,10 +263,9 @@ $ systemctl --user stop tomcat export XDG_RUNTIME_DIR="/run/user/$UID" ~~~ + # Utilisation avancée -## Debug - Afficher plein d'informations sur l'unité : ~~~ @@ -309,32 +296,44 @@ Startup finished in 5.019s (firmware) + 6.128s (loader) + 5min 35.864s (kernel) 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`. +Sous Debian 8, l'adoption de systemd est récente et de nombreuses services ont des unités mal écrites. Notamment elles ne gèrent souvent pas les options dans _/etc/default/_ alors qu'un fichier est créé par défaut. -Voir +Exemple avec _bind9_ qui ne gère par les options dans `/etc/default/bind`. +Pour corriger il faut copier l'unité : -## strace Apache impossible +~~~ +# cp -a /lib/systemd/system/bind9.service /etc/systemd/system/ +~~~ -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… +et ajuster la section _[Service]_ : + +~~~ +EnvironmentFile=-/etc/default/bind9 +ExecStart=/usr/sbin/named -f $OPTIONS +~~~ + +puis : + +~~~ +# systemctl daemon-reload +~~~ + +## strace d'un process + +Avant systemd, une astuce efficace pour stracer un démon multi-process était de faire `strace -ff /etc/init.d/ start` …mais ça n'est plus possible avec systemd : il faut désormais détecter le PID du processus père du démon pour faire un `strace -ff -p`. + +Exemple pour faire un strace Apache, on récupère le PID, on lance le _strace_ puis on fait un graceful : + +~~~ +# pstree -pan | grep -v grep | grep apache | head -1 +# strace -ff -s65535 -p +# apache2ctl graceful +~~~ ## networking @@ -372,4 +371,26 @@ 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. \ No newline at end of file +**systemd** ne prend aucune majuscule. Ce n'est pas SystemD ou systemD. + +## Migrer de sysvinit à systemd + +Cette action peut être nécessaire lorsque l'on migre de Debian Wheezy à Jessie. + +~~~ +# apt install systemd-sysv +The following packages will be REMOVED: +sysvinit-core +# reboot +~~~ + +et vérifier que GRUB ne se lance pas avec l'option `init=/lib/sysvinit/init`. + +## Et les scripts dans /etc/init.d/ ? + +Avec systemd, pourquoi reste-t-il des scripts dans `/etc/init.d/` ? + +systemd prend en compte les scripts dans `/etc/init.d/` : + +* les scripts « classiques » sont pris en compte si il n'existe d'unité systemd avec le même nom +* certains scripts sont juste là par compatibilité afin de pouvoir faire `/etc/init.d/foo start/stop/restart/status` mais c'est en fait l'unité systemd qui est prise en compte