On Mon, Aug 17, 2009 at 04:19:58PM -0700, Garrett D'Amore wrote: > This is particularly true given that daemon() is, as noted, insufficient > in the modern "Solaris" way of doing things.
The modern Solaris way of starting daemons does not care if you use daemon() or not. SMF's notion of process contracts exists in part to deal with the existence of daemon() in the first place. (Process contracts also deal with detecting process death in multi-process services, ...) More interesting are the __init_daemon_priv()/__fini_daemon_priv() functions in libc. But even then, services which don't need to drop privs after initialization are OK as is, and ones that do can do it without the help of those two helpers. > I'm disinclined to support an interface that is substandard *and* which > does not share widespread adoption in the FOSS community. In general daemon() is not powerful enough. Often one wants the process that calls it to not exit until the progeny forked by daemon() has completed additional initialization, or perhaps one should not call daemon() until sundry initialization is complete. But daemon() is quite common. Its absence is usually well-tolerated (#ifndef HAVE_DAEMON ...). But still, we should provide it. > If I've misunderstood about the availability of daemon() in Linux, > please feel free to correct me. Otherwise I'd be punching the derail > button on this case. It's there in libc in RHEL5. Nico --
