Voir aussi :

• Debian-systemd

Design - supervision system vs service manager vs system manager - “hard” and “soft” dependencies.

• https://davmac.wordpress.com/2018/10/26/on-the-vagaries-of-init-systems/
• init system and service manager https://chimera-linux.org/docs/faq#what-is-the-projects-take-on-systemd

Init process :

• https://wiki.gentoo.org/wiki/Comparison_of_init_systems
• https://github.com/davmac314/dinit/blob/master/doc/COMPARISON

Init process pour les conteners :

• https://cloud.theodo.com/en/blog/docker-processes-container
• https://ahmet.im/blog/minimal-init-process-for-containers/
• https://github.com/antontkv/docker-and-pid1

L'entrypoint devrait être un init tel que “catatonit”

Something like dumb-init or tini can be used if you have a process that spawns new processes and you don't have good signal handlers implemented to catch child signals and stop your child if your process should be stopped etc.

If your process doesn't spawn new processes (e.g. Node.js), then this may not be necessary.

I guess that MongoDB, PostgreSQL, ... which may run child processes have good signal handlers implemented. Otherwise there would have been zombie processes and someone would have filed an issue to fix this.

Only problem may be the official language images, like node, ruby, golang. They don't have dumb-init/tini in it as you normally don't need them. But it's up to the developer which may implement bad child execution code to either fix the signal handlers or use helper as PID 1.

Source : https://stackoverflow.com/questions/37374310/how-critical-is-dumb-init-for-docker

Voir :

• https://blog.saintmalik.me/dumb-init/

Voir :

• tini
• dumb-init
• catatonit (recommandé), utilisé par Podman - inspiré de tini et de dumb-init
• pid1 (paquet pid1) https://github.com/fpco/pid1

Voir :

• Notes dinit
• Notes Supervisor
• runit - fonctionnalités de base incluse dans Busybox - https://wiki.archlinux.org/title/Runit
• S6
• SystemD

Voir :

• my_init