> Therefore, I would again like to suggest my type of solution (tested, works) : > - Create a pipe before the fork(). > - fork() > - The parent does a "read" from the pipe. It is blocked. > - The child does : > * setsid() /* and is now detached */ > * "write" to the pipe
^ this step is not needed. close() will unblock the read(). > * close pipe > - The parent is unblocked from the "read". It can now close the pipe and > safely exit, since the child is detached. > - Any side affects of the parent exit (e.g. SIGHUP to the pgrp) will have no > effect on the child, since it is detached. Eli is right. You need a hard synchronisation mechanism to ensure that the parent does not return from daemon() before the child has detached; and as far as sync mechanisms go, a pipe works pretty well. However, since you are inside the libc, maybe you guys have access to lighter mechanisms (mutexes?) that do not require opening and closing a pipe. What is certain, though, is that just playing with signal masks won't be enough. (Nobody should use the daemon() function anyway. It's a legacy from the Dark Ages when people did not know better. Nowadays, daemons should not fork themselves, they should be handled by a process supervision framework such as s6, runit, daemontools, perp, Upstart, systemd or launchd.) -- Laurent _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
