Hello and sorry for the super-late reply, I've tested the patch and it seems to work. Both the Ubuntu 12.04 upstart and the CentOS 6.3 init script work when starting rsyslog with dropped privileges. The PID file now points to the only process that lives.
So I guess it's all fine. The only question I have left is when can we expect to see the patch in RPM&deb packages :D And... if I can help with anything to make that happen, just let me know. Best regards, Radu 2013/3/17 Rainer Gerhards <[email protected]> > On Sat, 2013-03-16 at 13:13 +0100, Michael Biebl wrote: > > 2013/3/16 Rainer Gerhards <[email protected]>: > > > 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. > > > > As much as I'd like to see Ubuntu switch to systemd, atm it looks like > > they'll stick to upstart. > > > > > 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. > > > > I don't think the original syslogd had the ability to drop privileges, > > so it was a non-issue back then. > > > I didn't mean priv drop - I mean that it does not reflect the actual > startup success/status state back to init. > > > > 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. > > > > This is mostly an issue for Ubuntu, and they don't seem to care how it > > is addressed. > > Should I enable the privilege dropping in Debian and should I bother > > enough, I guess I'll either have to cook up a patch or just shut up. > > You are right it's not important enough to bicker about. I just wanted > > to have it mentioned that there is a better/nicer way to do this. > > If a real-world issue shows up, I'll definitely will address it (that's > a prime reason why I asked to try out the patch). However, I hope/think > this will not happen. But, again: if you experience real problems, pls > let me know. That would definitely be a reason to implement some other > mechanism. > > Thanks again for the good thoughts! > 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. > _______________________________________________ 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.
