On Wed, 27.08.14 09:47, HATAYAMA, Daisuke (d.hatay...@jp.fujitsu.com) wrote:
> >Sounds like the right option here... I have now added a slightly > >different patch (1dedb74a2e1d840b531b76b01a76979f3b57456b) that does > >this. > > > > Thanks! But this could still hang in very rare case becuase the reset is > done in a child process after fork(). Please consider the case where the > child process continue sleeping after fork() before resetting signal > handlers until it receives SIGTERM. For such reason, my patch resets > SIGTERM signal handler in the parent systemctl side. Hmm, there's indeed a race here. I add a commit now that will block all signals before forking, and unblocks them afterwards. The new process will hence be created with all signals blocked, and we will hence not lose them until we after we reset the signal handlers... Hope this makes sense? (Blocking the signals temporarily, instead of resetting the signal handlers has the benefit, that we signal masks are per-thread, and not per-process, like signal handlers are. The code hence stays generic enough to not break should the call ever get invoked from a threaded process...) Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
