I've installed rsyslog 5.7.0 which has native socket activation support and the unit files from http://0pointer.de/public/systemd-units/. When I run "systemctl start rsyslog.socket", the /dev/log socket is correctly created and running "logger foo" will start the rsyslog service, which takes over /dev/log. If I then kill the rsyslog daemon process (either with kill $pid or systemctl stop rsyslog.service), there is no more /dev/log so the socket activation no longer works. It looks like the socket /dev/log is not correctly given back to systemd/rsyslog.socket.
(In reply to comment #0) > > It looks like the socket /dev/log is not correctly given back to > systemd/rsyslog.socket. After further discussion with mezcalero on irc, this looks like a problem in rsyslog, which unlink's /dev/log on shutdown, whereas it shouldn't do that when in sd socket activation mode.
(In reply to comment #1) > After further discussion with mezcalero on irc, this looks like a problem in > rsyslog, which unlink's /dev/log on shutdown, whereas it shouldn't do that when > in sd socket activation mode. Filed a corresponding bug report in the upstream rsyslog bug tracker: http://bugzilla.adiscon.com/show_bug.cgi?id=200
This is definitely a bug in rsyslog and I'll fix it there.
Hi Lennart, there now is an upstream fix (to be released with 5.7.1 soon), but Michael raised an interesting question that needs your attention. Please see this post: http://bugzilla.adiscon.com/show_bug.cgi?id=200#c6 Rainer
Which question precisely? A stale socket should be fine. I think the only remotely race-free way to handle all of this is to delete the socket in the last possible moment, i.e. right before creating a new one. Ideally we'd even make this atomically, which we probably could do with renaming or so...
BTW, this bug can be closed now, right?
Closing, feel free to reopen if there's still a problem left.
(In reply to comment #6) > BTW, this bug can be closed now, right? Yeah, I think you explained sufficiently why you keep the socket around.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.