improve protection against duplicate instances

[davidelang]

currently when rsyslog starts, it checks to see if a pidfile exists, and if it exists, rsyslog refuses to start.

However, if rsyslog crashes or is killed with a -9, it does not have a chance to remove the pidfile and so a replacement cannot be started

As an enhancement, rather than just depending only on the existance of a pid file, rsyslog should look in the pid file and check to see if there is a process running with that pid (ideally if it's an rsyslog process, but at least that some process with that pid exists on the system), if there is no process with that pid, rsyslog should log a warning that there was a orphaned pid file and overwrite it.

[smowafy]

I'm interested in this issue, if it's possible I can take it over.

Disclaimer: This would be my first meaningful contribution in a C project, so in case I took it please excuse me in case I was a little slow on this one.

[davidelang]

go for it! The Adiscon team has such a long to-do list that they won't mind you taking this, and it's an issue that's been around forever, so it's not a pressing bug that needs to get fixed immediatly. David Lang

[rgerhards]

At least in theory, rsyslog should already do exactly that: https://github.com/rsyslog/rsyslog/blob/master/tools/rsyslogd.c#L326

Might it be that due to some SELinux or similar rsyslog has no permissions to send the signal to itself? Or Priv Drop? Not sure if we can come around this via a non-privileged interface.

[davidelang]

My idea was not any attempt to communicate between instances, merely that if a pid file exists, look at the pid in it and if such a pid doesn't exist on the system, consider the pidfile orphaned and act like it didn't exist if you do a normal kill, rsyslog has a chance to clean up after itself and remove the pid file, if you do a kill -9 it doesn't and the pid file remains David Lang

[rgerhards]

El mié., 9 oct. 2019 a las 9:32, David Lang (<notifications@github.com>) escribió:

My idea was not any attempt to communicate between instances, merely that if a pid file exists, look at the pid in it and if such a pid doesn't exist on the system, consider the pidfile orphaned and act like it didn't exist

This is exactly what the mentioned code does (or intends to do ;-)). Rainer

…

if you do a normal kill, rsyslog has a chance to clean up after itself and remove the pid file, if you do a kill -9 it doesn't and the pid file remains David Lang — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3892?email_source=notifications&email_token=AALJ3CY7W3ZRMA2D4OVOD2DQNWCKBA5CNFSM4I6XHMU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAW57SI#issuecomment-539877321>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AALJ3C6DJDMVUNBNYCG4IXDQNWCKBANCNFSM4I6XHMUQ> .

[skupkosk]

Some reading about new pidfd in Linux 5.1 kernel. https://lwn.net/Articles/794707/ https://kernel-recipes.org/en/2019/talks/pidfds-process-file-descriptors-on-linux/ Use of lock pid file might help too https://linux.die.net/man/3/pidfile Or the systemd instantiated service will make it possible to manage the multiple instances. http://0pointer.de/blog/projects/instances.html The systemd service might look like: [Unit] Description=Syslog Service %i instance Documentation=man:rsyslogd(8) Documentation=http://www.rsyslog.com/doc/ ConditionPathExists=/etc/rsyslog-%i.conf [Service] Type=notify ExecStart=/usr/sbin/rsyslogd -n -f /etc/rsyslog-%i.conf StandardOutput=journal [Install] WantedBy=multi-user.target Alias=syslog-chroot.service

…

On Wed, Oct 9, 2019 at 9:16 AM Rainer Gerhards ***@***.***> wrote: At least in theory, rsyslog should already do exactly that: https://github.com/rsyslog/rsyslog/blob/master/tools/rsyslogd.c#L326 Might it be that due to some SELinux or similar rsyslog has no permissions to send the signal to itself? Or Priv Drop? Not sure if we can come around this via a non-privileged interface. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3892?email_source=notifications&email_token=ACDUHFR2KR2LVN4INMXRXZLQNWANNA5CNFSM4I6XHMU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAW4WPA#issuecomment-539872060>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACDUHFVVZEYXTGJ4ALN3PNDQNWANNANCNFSM4I6XHMUQ> .