Hi Michael, On Sat, 2013-03-16 at 00:48 +0100, Michael Biebl wrote: > 2013/3/15 Rainer Gerhards <[email protected]>: > >> 2013/2/19 Rainer Gerhards <[email protected]> > > This patch: > > > > http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=0114b531b38b16db98b04b680017d6c758987fd9 > > > > (for v7-stable) should also fix the hang. I'd appreciate if you could give > > it a try and report back. > > > > I still think, using a separate communication channel to signal the > parent process to terminate is better then using kill in the child. > If I read the change correctly, you've just moved the kill(ppid) > before the privilege drop, right? > But I think the parent should be signaled to terminate *after* the > child is fully ready to process requests.
You are technically correct. However, I think that it is not worth the extra effort to setup this communication channel. Reasons are: 1) init is going away As it looks, almost all distros will move towards systemd, and with that this functionality is actually no longer used at all. So I doubt it makes sense to put effort into something that's already scheduled to go away. 2) signaling is as it is for 20+ years Most importantly, any errors encountered during the config read phase are not signaled back. This is the same since the beginning of syslogd. So I doubt it is vital to fix it right now. 3) After the patch, the kill is done almost at the same place as previously I moved it slighly in front of the privilege drop, and also in front of binding the listener ports. However, all the hard plumbing is already done, so on a usual system, the full init state should be reached within an instant - definitely fast enough for the init system. In conclusion, I think the current state is good enough, and I think the time required to implement a new signaling mechanism is better spent on some other point of the long todo list. And, yes, I agree it is not an awful lot of work, but doing it right requires some time (and not doing it right wouldn't be better than what we have right now). Of course, code contributions are happily accepted. Please let me know if my reasoning is wrong. Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
