On Fri, 16 Sep 2016 15:22:25 +0100
KatolaZ <katolaz@???> wrote:

> On Fri, Sep 16, 2016 at 03:51:43PM +0200, Didier Kryn wrote:
>
> [cut]
>

> >     Nobody supervises pid1, OK? So why would the supervisor need to
> > be supervised? It is supposed to be rock solid. Note that it can be
> > barely relaunched by sysvinit in the same way as getty.

> >
>
> Yep, but if a supervisor dies, all his children will be orphaned, and
> even if init respawns the supervisor, this might not imply that all
> the supervisor's children are respawn :)
>
> I personally don't care at all about supervision systems, since I find
> them completely useless in most of the common applications. I have
> written a couple of custom ones, back in the days, but just for really
> mission-critical stuff, where a process failing to do something meant
> potentially damaging costly devices. And in that case the most logical
> thing to do was to have part of the supervision managed by pid1.
>
> But I am sure that 99.9999% of the users do not need supervisors in
> 99.9999% of the cases...

I wouldn't say 99.9999%. I think everyone running wpa_supplicant can
benefit from having it respawnable, because it crashes at the slightest
excuse, and respawning makes it available whenever needed.

Supervisors have more benefits than just respawning. They're easier to
understand. They're easier to turn on and off in a wide variety of
situations. They're more trackable via ps axjf. With supervisors, you
don't need to deal with PID files. And, perhaps coolest of all, if
you're running processes off a supervisor, you can make your own daemon
simply by writing a program that runs in the foreground, and the
supervisor will "daemonize" it, instead of having to write your program
to doublefork itself.

SteveT

Steve Litt
September 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28