:: Re: [Dng] Why daemontools is so coo…
Top Page
Delete this message
Reply to this message
Author: Didier Kryn
Date:  
To: dng
Subject: Re: [Dng] Why daemontools is so cool

Le 29/03/2015 11:15, marc a écrit :
>> No need to mix doubleforking and PID tracking on your
>> program. That should be the duty of whatever daemonizes and manages
>> your program. You know, like Daemontools or s6.
> So there is a very good reason for a deamon to handle its
> own backgrounding: The sensible convention is it that it
> should only background at the instant where it is ready to
> service requests: If there is a long initialisation phase
> it should stay in the foreground - so that things that
> depend on it in turn do not get started too soon. A more
> detailed description of this problem I wrote up a while ago
> at welz.org.za/notes/on-starting-daemons.html.
>
> More fundamentally: If an application has problems calling the
> a daemonize() or fork_parent() function or the handful of system
> calls that make up this, then maybe this a limitation of the
> development environment or language - if calling these this is regarded
> to be hard then one wonders how reliable the rest of the program is.

     Dear Marc,


     This makes sense if we consider the very old way a Linux system was 
run:
         boot; then mount filesystems, them start syslog; then 
initialize network; then start nfs and ssh ...
     then stop daemons in the reverse order, unmount filesystems and 
shutdown.


     A more modern way of starting daemons is to have fine-grained 
dependencies. Instead of waiting until syslogd is started, why not wait 
until the socket /var/log is created, or create it even before starting 
syslogd.


     And furthermore, is it really necessary to wait for anything before 
starting the daemons; why wait until the network is configured to start 
ssh and nfs?


     Things are not going the linear way anymore. The network cable, as 
an example, can be disconnected and reconnected, and the network 
interface de-configured and re-configured, and the ssh daemon will 
survive, and NFS as well. Even you can reboot an nfs server and clients 
having their rootfs nfs-mounted come back to life seemlessly.


     Daemons should be prepared to wait until the needed ressource is 
available; they should even be prepared to see the ressource they need 
disapear and to wait until it shows up again.


     You make a very good point - often forgotten , including by me -  
about daemon's current directory. But about orphanning the daemons, I 
disagree. I used to do like you for my private daemons, and to manage 
pid-files, but it was because I repeated the same scheme by pure 
lazyness. I am decided to now use a supervisor.


     Didier