On Fri, Nov 11, 2011 at 2:22 PM, Lennart Poettering <mzerq...@0pointer.de> wrote: > On Fri, 11.11.11 14:12, Miloslav Trmač (m...@volny.cz) wrote: > >> On Fri, Nov 11, 2011 at 2:05 PM, Lennart Poettering >> <mzerq...@0pointer.de> wrote: >> > Note that only double-forking >> > will properly detach a process from the parent it is started from on >> > Unix, and hence is not an option but mandatory to do >> >> In the traditional SysV, the process executing /etc/init.d/$service >> will exit immediately afterwards. Isn't that structurally equivalent >> to double-forking within the service? > > No. > > In SysV it is expected that when you run "/etc/init.d/foobar start" and > this command completes the service is fully initialized, the PID file > written and the service accessible. That means that you need to double > fork and in the parent process wait until initialization is > complete. I can just as well wait in the single-fork parent, can't I?
> On top of that, you need to invoke setsid() between the two forks, which > you can't really do if you only have one fork(). Again, I should be able to do this in the ultimate child just the same - the concept of "orphaned process group" (and the related SIGHUP/SIGCONT behavior) only triggers for process groups within a single session, and the controlling TTY behavior should not matter for daemons (although I do agree that having the session leader exit is a little safer because it ensures that the daemon won't randomly obtain a controlling TTY). I can see only one difference - starting the daemon from a command line within a user's session without double forking would leave the process "attached" to the user's session in the process tree; however, given that the process was not actually started by the service management system in that case, this might arguably be considered a correct behavior - and in any case doesn't really matter for anything. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
