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.
Sure, even if the OpenVZ interface is more sensible, that doesn't mean they can just change it. And the mainline kernel is probably bound by backwards-compatibility guarantees. If only such considerations were made before an interface is fixed in the kernel for all time... > 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> User support told me they forwarded the issue to the tech staff (which positively surprised me) - and that's the last I heard about this issue. I doubt they would want to patch this without upstream's consent (for good reason), and since upstream doesn't want to change it either... we're kind of stuck, it seems. > 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 for this. Of course, as already mentioned, start-stop-daemon is not the only affected tool. Another example I stumbled upon is checkrestart. :-/ Kind regards Ralf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
