In this case I will postpone adding the changed upstart script into the packages. However it seems save legit to remove the "-c5" parameter from rsyslog.default so far.
Best regards, Andre Lorbach > -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of Radu Gheorghe > Sent: Freitag, 21. Dezember 2012 12:53 > To: rsyslog-users > Subject: Re: [rsyslog] Privilege drop makes stopping it (via Ubuntu upstart) > to > hang > > Right! Thanks for your input, Michael! > > I was just about to send the files when I thought if my changes wouldn't > break the "traditional" init script. And it would - init script waits > indefinitely. > So I've added "-n" to the upstart conf instead of the /etc/default file, to > prevent such issues. > > Attached you can find the two modified files. But as Michael pointed out, this > seems a bit hackish. For example, the init script doesn't work with dropped > privileges, either. It just stands there indefinitely. > > Sure, we can add --background to start-stop-daemon in there, but we'd have > the same issues as with the upstart script. What's more, it wouldn't know > whether rsyslog started successfully (got that from `man start-stop- > daemon`). > > Would it be an option to write the parent PID in the PID file in case of > dropped privileges? I think that would help the restarting part and scripts > can > remain untouched. > > Best regards, > Radu > > > > > 2012/12/21 Michael Biebl <[email protected]> > > > 2012/12/21 Radu Gheorghe <[email protected]>: > > > Thanks Rainer! It actually works like that, if you comment out > > > "expect fork" from /etc/init/rsyslog.conf > > > > Just wanted to mention that removing the forking has an unpleasant > > side-effect: > > > > Forking in daemons is usually a way to signal that it has setup its > > communication channels (sockets to read from etc). > > Upstart would only fire the "rsyslog started" event once that fork > > happened. > > Now, removing forking from the upstart job file means, upstart fires > > "rsyslog started" as soon as the binary has been spawned but this > > doesn't necessarily mean it is ready yet to listen on /dev/log. > > Subsequent daemons relying on syslog are possibly started too early > > and there is a chance that you lose syslog messages as the startup > > sequence has become racy. > > So removing the forking from the upstart job file has some > > consequences you need to be aware of. > > (fwiw, systemd solves that problem rather nicely). > > > > Cheers, > > Michael > > > > -- > > Why is it that all of the instruments seeking intelligent life in the > > universe are pointed away from Earth? > > _______________________________________________ > > 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.
