Re: rsyslog init script breaks after package upgrade
Hi!
On Thu, 2014-03-20 at 10:10:29 +0100, Ralf Jung wrote:
> To be honest, the behaviour of OpenVZ seems to make more sense than
> upstream Linux. I mean, what if a file called "/usr/sbin/rsyslogd
> (deleted)" actually exists? There is no way to distinguish whether this
> program was executed from a deleted version of "/usr/sbin/rsyslogd", or
> the current version of "/usr/sbin/rsyslogd (deleted)". The way OpenVZ
> makes it, however, these cases are easy to distinguish: If the link does
> not start with "/", it does not refer to an actually eixsting file.
I've got to agree with that. The problem here is that this really does
not seem to have been an intended change, as I would not have expected
the prepended string to start with " (deleted)/path/name", but with
"(deleted) /path/name" instead. And it breaks the kernel interface.
On Wed, 2014-03-19 at 23:53:53 +0100, Ralf Jung wrote:
> I will contact support, but my experience is that this does not reach
> people who even understand what I am talking about... :-/ I'd probably
> have to know someone in their tech team to actually get this fixed^^ (or
> use the magic password [0])
>
> [0]: https://xkcd.com/806/
Heh, and yeah I guess it will be pretty hard to get this first fixed
in the OpenVZ kernels and propagated to hosting sites, or independently
fixed by any hosting site, given the response to Chris' bug report [B]
(although they could start already changing the checkpoint code to
recognize both string). BTW Chris, thanks for forwarding this!
[B] <https://bugzilla.openvz.org/show_bug.cgi?id=2932>
So, I guess a bit reluctantly, I'm going to add a workaround for
1.17.10, and then try to get that into 1.16.x in wheezy, so that you
guys can have working systems again. That said, I fear this will make
it less likely this might get fixed upstream, and might end up
entrenching this behaviour for good. :/
Thanks,
Guillem
Reply to: