On Mon, 2009-08-17 at 18:02 -0500, 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 :)
Exactly. > A new flag for daemon() to cause the daemon to be placed in a new > process contract, might be OK, but what would use it? It would have to be a separate function introduced by a separate project. This function must have the same signature and semantics as the BSD version. -Seb
