Nicolas Williams wrote:
> On Mon, Aug 17, 2009 at 03:50:49PM -0700, Alan Coopersmith wrote:
>> Darren Reed wrote:
>>> One could argue that the original daemon() does not offer much flexibility
>>> and that this approach to daemonization is actually not sufficient in SMF
>>> world. While this is true, it is out of scope of this case to provide modern
>>> alternative.
>> While providing an alternative interface is both out-of-scope, and missing
>> the point of providing a BSD/Linux compatible interface, have you discussed
>> with the SMF team whether daemon() should be putting the process into a new
>> process contract?
>
> That would probably be a bad thing to do by default. Much code calls
> daemon() -- if you try to make a non-transient service out of a program
> that does call daemon(), and daemon() does place it in a separate
> process contract, then the daemon's original process contract will
> empty, causing the restarter to restart the service, which is...
> probably not what you want :)
Okay - I was thinking in the context of when you manually start a daemon
from your login session, and the daemon() call is used to divorce it from
your process group so it doesn't get SIGHUP'ed when your shell dies.
As long as it's been thought about and determined to be doing something
reasonable, that's good enough for me.
+1 on this, as someone who has to maintain upstream code with autoconf
checks for daemon() that are pretty much only for Solaris these days,
as all other supported platforms already have it.
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
