Le 28/03/2015 17:04, poitr pogo a écrit :
> On Sat, Mar 28, 2015 at 4:15 PM, Isaac Dunham <ibid.ag@???> wrote:
> (...)
>> If you want to *manage* a daemon (ie, do something when it stops, like
>> restarting it), it's very tricky to do it reliably without having a fixed
> It might be tricky if application does not support startup/shutdown procedure.
> That's why I would expect application to provide a script to start/stop it.
> I expect application to be tested on a system it is to be running on,
> so developing a stop/start script is not a big deal comparing to the
> whole test procedure.
It's exactly that script which is tricky; you know, the trick with
pid-files to be sure to not have two or more instances running and be
able to send it signals. Usually this startup script does exactly what
you don't like in daemontool, s6 and other supervisors: give an option
to the daemon to tell it to not orphan itself, so that the script can
use the pid to write the pid-file.
Some daemons are smart enough to create the pid-file themselves;
this adds yet more complexity in every daemon. Why not have an
application which does that for every daemon: create pid-file and then
exec the daemon? The start/stop scrpits in Debian (before Jessie) invoke
start-stop-daemon to do something like that.
>
>> PID; "daemonizing" means close stdin/stdout/stderr, then
>> if (fork()) exit(0);
And the daemon gets orphanned... is there any reason to do that?
>> or some such thing (in other words, create a new process and exit the
>> old one), so you do not have a fixed PID.
>>
>> On Linux, BSD, and older UNIX versions, this can be done thus:
>> daemon(0,0);
>>
> How this can be done in java? ;)
>
> Detaching from terminal, binding to reserved ports, dropping privileges, etc.
>
>
>>> Another s6 limitation - finish script must end in 3 seconds. or will be killed.
>>> Nice for desktop, not a server.
>> sysvinit /etc/init.d/sendsigs actually only allows 1 second.
>>
> I see it is skipping some processes (which have their own upstart
> scripts, and others which are recorded in special file not to be
> killed by sendsigs). So it (sendsigs) is for all the rest of processes
> which do not care about how they should be stopped. Not for that which
> provide its own start/stop scripts.
> In case of s6 it is the limit for the finish script for particular application.
>
> (...)
>> My understanding is that s6 and some of the equivalent packages, such
>> as daemontools, are fairly portable.
>>
>> They are generally not used as a way to offload daemonizing, but as a
>> way to ensure that a service stays started. If you don't need that,
>> you don't need them.
>>
> s6 advertises itself as init replacement.
> I'm not using s6 or daemontools. I do not need them. Just learned
> about them and I'm bit surprised thy tend to replace init instead of
> being a good helpers for those who need them.
>
> IMHO they came into existence cause more and more applications were
> missing "deamon" part, to make sysadmin/programmer life easier. s6 doe
> not support those which daemonize on its own, anyway :)
>
> init has inittab for monitoring application which need continuous
> restart by design like getty.
>
> If a daemon needs to be monitored and restarted when it dies, bug
> should be fixed.
> I expect a deamon to work from start to stop command. No self stopping.
> As workaround nohup, screen, while `true`,etc are enough to keep
> system running until bug is fixed.
I often experience rsyslog stopping for unknown reason, on
Debian-Wheezy servers where it's used to log messages from remote hosts.
I don't intend to debug rsyslog; I would be happy if it was restarted
automatically.
>
> I do not like buggy software, so maybe that's why i do not need s6/daemontools.
>
> just IMHO.
I share your dislike. However I see only one way to not run buggy
software: turn off your computer... as long as software is written by
human beings :-)
A small and do-almost-nothing supervisor is a sensible way to
monitor the daemons. But nobody forces you...
Didier
::
Re: [Dng] Why daemontools is so coo…
