Différences

Ci-dessous, les différences entre deux révisions de la page.

--- technique:docker:good_practices:init [2020/10/13 14:51] – qduchemi
+++ technique:docker:good_practices:init [2020/10/13 16:03] (Version actuelle) – qduchemi
@@ Ligne 1: / Ligne 1: @@
 {{indexmenu_n>25}}
 # Utiliser un système d'initialisation
+<bootnote warning>Si vous utilisez un script shell comme entrypoint, la documentation sur [[technique:docker:good_practices:multi|les entrypoints et les processus multiples]] sera utile en premier lieu.</bootnote>
 ## Problématique
@@ Ligne 25: / Ligne 27: @@
 Sauf... pour le processus de PID 1. Dans ce cas, il n'y a pas de comportement par défaut.
-<bootnote important>Concrètement, lorsque l'on fait un `docker stop`, un `SIGTERM` est envoyé au processus de PID 1. Si celui-ci n'a pas de *handler* pour `SIGTERM`, il ne se passe rien, et au bout d'un timeout assez long (~30 secondes), Docker envoie un `SIGKILL`.</bootnote>
+<bootnote important>Concrètement, lorsque l'on fait un `docker stop`, un `SIGTERM` est envoyé au processus de PID 1. Si celui-ci n'a pas de *handler* pour `SIGTERM`, il ne se passe rien car il n'y a pas de comportement par défaut, et au bout d'un timeout assez long (~30 secondes), Docker envoie un `SIGKILL`.</bootnote>
 Or, la plupart des applications lancées avec le PID 1 (par exemple Python) n'ont pas de *handlers*.