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 :) 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? Nico --
