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
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
