Re: C'est là tout le problème

Et pour cause, c'est pas son job. Regarde plutôt du coté de runit ou daemontools.

Ouais, génial. Donc il faut changer d'init, ou au moins avoir plusieurs outils pour tenter de savoir si un service est démarré ou non (pratique...).

Not My Problem

And this is about all SysV init actually does. Other problems that might be addressed by the init system are delegated to other programs.

For example, starting processes on socket connections has to be done by inetd or xinetd. If you want to monitor a service and restart it when it fails, you have to use supervisor or circus. And so on.

But the service script does not know about services started from those programs, so the admin is left with multiple different places to look for whether a service is running, or even what services are running at all.

Similarly, SysV init simply expects each and every service to re-implement common functionality instead of implementing it itself once.

This starts with the requirement of every service having to daemonize itself. This is not a trivial task, requiring 15 separate steps to do correctly. Even the system call daemon(7) is discouraged because it forgets some of the steps.

All services that open TCP ports below 1024 are expected to start as root, open the socket, and drop user privileges by themselves. Generally, dropping user privileges and setting up a chroot has to be done by services. Logging is another aspect that every service gets to re-implement badly.

Between the limited functionality SysV offers, and the convoluted and baroque way in which it is implemented, there has to be a better way.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)