Rainer Weikusat via Dng <dng@???> writes:
> Steve Litt <slitt@???> writes:

[...]

>> Traditionally, this type of daemon would remain in foreground until it
>> was functional, and then doublefork itself, at which time sysvinit
>> would run the next daemon.
>
> That's an urban myth. There is no such convention and "daemon readiness"
> isn't a well-defined concept.

To illustrate this with three examples I know out of my head:

BIND (the Berkeley Internet Naming Daemon) daemonizes itself before it
reads and parses its configuration including any configured zone
files. In case this fails because of syntax errors or missing include
files, it'll log corresponding messages to syslog and exit. Because of
this, it's important to check the syslog after starting it to make sure
it really started and will actually serve requests.

The suricata IDS/ IPS forks itself into the background after reading its
configuration file but before reading and parsing any rule files. With a
suitably large set of rules, it can take more than a minute until it's
actually ready to do anything.

The BSD-derived Linux ftpd daemonizes itself after parsing command-line
options and connecting to syslog, ie, before it even tries to open its
listening socket.