OpenSolaris

Solaris should have 4.4BSD's daemon() utility function to simplify the
process of writing daemons and reduce the opportunities for coding flaws.
Please note the discussion in 5079306.  A two-phase daemonization strategy
will allow developers to much more easily write SMF-friendly daemons, as
well as provide more flexibility for the daemon author in terms of error
communication, etc.  (There's also been an archived discussion on smf- xxxxx@xxxxx.org about these RFEs and interface extensibility,
under the "smf or inittab" thread.)

N/A

Here's a little analysis of current state:

- There are various demands and motivations for daemonizing function (time
  ordered):
  1. provide daemon(3C) for compatibility with BSDs
  2. offer daemonizing interface to protect the programmers from
     dangerous use of fork() with(out) setsid().
  3. some would want more flexibility in closing descriptors, being able
     to set umask(), (not) redirecting fds 0,1,2 to /dev/null, set templates
     for contracts, etc.
  4. provide SMF friendly daemonizing API/style (not just 1 function)

- Comments:
  #1 Seems to be driving the initial request. These days it primarily
     means better portability of open source apps to OpenSolaris.
  #2 As is mentioned in the comments, the right way to daemonize is this:
     fork()+setsid()+fork(). The original BSD daemon() calls fork()
     just once. The second fork() is done in order to make sure the child
     process is not a session leader and hence cannot regain controlling
     terminal.
  #3 Seems to be nice to have (daemon() flavor with flags instead
     of 2 boolean arguments) but it's not clear whether this is actually
     widely needed. It looks like this should have been done in the early 90's
     when the original daemon() function was conceived.
  #4 Add two new functions (daemonize_start() and daemonize_ready())
     to get along with SMF requirement for daemons to return only when
     really providing the service.

- Feasibility:
  #1 Easy to do, more so that Suggested fix contains in house produced
     daemon() function (no need for incoming open source review)
  #2 We can probably have our daemon() to call fork() twice. This should
     not break any opensource apps ported to OpenSolaris. (One more fork()
     does not hurt)
  #3 Easy to implement, would have to use different name to avoid
     compatibility issues (but daemon() could be implemented on top of this
     function).
  #4 Difficult to design and implement (to fit everyone). Tracked by
     separate RFE 5079306. This is introducing different paradigm so it
     would not be possible to implement daemon() on top of that (it's rather
     orthogonal it seems - 2-phase strategy versus 1-phase call).
This is covered by PSARC/2009/444.