Re: rsyslog init script breaks after package upgrade
On Wed, 2014-03-19 at 19:42:55 +0100, Ralf Jung wrote:
> > Going over the original bug report I see this very suspicious line:
> > ,---
> > chrisb@massmail:~$ sudo ls /proc/427/exe -l
> > lrwxrwxrwx 1 root root 0 Dec 6 01:33 /proc/427/exe -> (deleted)/usr/sbin/rsyslogd
> > `---
> > If this is really the contents of the exe symlink, then that's the reason
> > s-s-d cannot find the process. The expected contents of the symlink
> > when the inode has been unlinked should be «/pathname (deleted)».
> I can however confirm this observation. On my server, it says:
> > # ls -lah /proc/$(pidof rsyslogd)/exe
> > lrwxrwxrwx 1 root root 0 Mar 19 19:38 /proc/30211/exe -> (deleted)/usr/sbin/rsyslogd
> > Chris, Ralf, what kind of kernel are you guys using? Is that a custom
> > one? Perhaps heavily patched?
> The system is running on a virtual server provided by Stato. I do not
> have access to the kernel - as in, I cannot (un)load modules or even
> choose my own. As far as I know, they are using OpenVZ for
> visualisation. At least, the root FS has type "vzfs". uname says:
> > # uname -srvmpo
> > Linux 2.6.32-042stab078.27 #1 SMP Mon Jul 1 20:48:07 MSK 2013 i686 unknown GNU/Linux
> I hope this is helpful.
This seems also suspiciously similar to Chris' kernel:
Kernel: Linux 2.6.32-042stab081.5 (SMP w/20 CPU cores)
In which case I'm inclined to say this is a bogus kernel, which
prepends “ (deleted)” instead of appending it. You should report this
to the server provider. And I'm in principle going to just close this
bug report (instead of adding a workaround to s-s-d), as this might
break other userspace programs and should be fixed in the kernel side.