[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#708416: Apache2 on 'older' kernels does not work in Debian stable



[Rolling up multiple replies into one to keep the ticket to what it is.
Thanks for the very quick replies and keep up the good job! ]

On 2013-05-15 20:29 , Axel Beckert wrote:
> Control: severity -1 important
> 
> Hi Jeroen,
> 
> Jeroen Massar wrote:
>> Package: apache2
>> Severity: grave
>>
>> When upgrading to Debian stable (the one that is stable today, released
>> recently ;) and when one still has an older kernel (2.6.26-2-686,
>> linux-image-2.6.26-2-686 2.6.26-26lenny2) Apache fails to start
>> mysteriously with:
> 
> I'm sorry, but this is not of RC severity. Debian doesn't support
> dist-upgrades with skipping one release inbetween (at least not
> officially) and hence upgrading with kernels from "oldoldstable" isn't
> really supported either.
> 
> Nevertheless thanks for reporting this issue.

Understandable. I primarily filed this bug so that people can be aware
of this situation when they google for this.

Btw: I have a p200mmx that I once installed as Debian Bo and upgraded
all the way up to the current unstable... yes, that box has been
rebooted in the mean time a few times ;) I guess that truely
demonstrates the power of Debian (dpkg/apt, and of course the many
developers delivering high quality packages!)

>> Please make Apache depend on a 'new' kernel. Apparently that is 2.6.30+
>> or better 3.2+ that provides a certain syscall that is being used.
> 
> This will make the situation worse for many virtual machines where the
> kernel is hosted outside the virtual machine, namely on Xen DomUs
> which don't use pygrub or inside VServers as you cited yourself in the
> second mail:
> http://serverfault.com/questions/496989/apache-in-linux-vserver-wont-start-cant-create-socket
> seems such a case.
> 
> And no, I don't have a better solution for that at the moment.

udev for instance warns about this that one should reboot (which indeed
I ignored). Apache did not warn.

>> $ uptime
>>  16:20:46 up 912 days,  3:38,  2 users,  load average: 3.83, 2.59, 1.33
> 
> :-)
> 
> 	Regards, Axel (sitting only a few kilometers away from you ;-)

Are you sure about that? :) It depends on your definition of 'few', if
'few is >2000km, assuming you mean that you are in .ch, then it is few,
otherwise it is not few :)


On 2013-05-15 21:37 , Arno Töll wrote:> Hi,
>
> On 15.05.2013 18:23, Jeroen Massar wrote:
>> Package: apache2
>> Severity: grave
>
> sorry. No.

I thought it was appropriate as:
"grave
makes the package in question unusable or mostly so, or causes data
loss, or introduces a security hole allowing access to the accounts of
users who use the package."

As it does not start, does not have proper explanation why, I thought
that correct.


[..]
> this is bad luck, but expected. We do not support upgrades skipping a
> version in any way. If you are running a kernel from Lenny, you cannot
> (and should not) expect it is being able to run a much newer user land.

I half-expected this (as it happened with a lot of other stuff before),
but as apt/dpkg do not notify one that one has to reboot and the binary
starts it is not expected.

> You noticed this problem for Apache, but in reality there are plenty of
> packages making use of syscalls introduced in later kernel versions.
> Some random examples include, but are not limited to lvm, udev, libc6
> and by chance many, many more.

Oh yes.

>> Linux andromeda 2.6.26-2-686 #1 SMP Thu Sep 16 19:35:51 UTC 2010 i686
>> GNU/Linux
>>
>> $ uptime
>>  16:20:46 up 912 days,  3:38,  2 users,  load average: 3.83, 2.59, 1.33
>
> I am not sure this is something to be proud of, or even more so telling
> to the public that you are running a kernel which saw no security
> upgrades for 3 years (and yes, there are issues).

That would be proud of Debian allowing user-space upgrades to go forward
and keep the box up and running all the way ;)

There are definitely issues, but a box that works great typically does
not get a reboot. It did so now though, and indeed it was about time.

Note that that box is in an environment that it is really not reachable
from the outside or anything untrusted, thus the risk of a remote or
even local (if one could get access to it) kernel exploit was/is very low.

> There is also consensus in Debian not do depend on any particular kernel
> version.

[That kind of contradicts the 'don't use an old kernel' version ;)
 but I assume you mean "no particular semi-current version" ]

> There is no reliable way to please everyone running Debian in
> every setup. Just to note some random examples, where dependencies
> against a kernel package would break:
>
> - chroots
> - virtual machine environments
> - self-built kernels
>
> And finally, as you noted yourself: Having a kernel INSTALLED and having
> that kernel BOOTED is a different kind of story.

I fully agree, it is a very difficult thing to resolve properly.

> If you still believe this is something which should be addressed, try
> to
> find project-wide consensus. For example, I could imagine that libc6
> maintainers provide a runtime check running in their maintainer
> scripts
> testing the kernel for required interfaces and warning the user if the
> running kernel can not satisfy the requirements of the user land.

While it might be something really cool to have addressed, I do not
think it is worth the effort doing so. As you stated (and yes, I am also
blissfully aware) there are lots of security issues with older kernels
(even if this one is not remotely exposed to them due to it's config and
environment)

As stated above, the primary reason for reporting this, along with a
possible resolution (rebuild libapr1 on the host system, so that libapr1
does not use the new syscalls) is to make people aware when they run
into this problem. Google/Bing/Yahoo will index this and that works for
me and likely others(tm)

Greets,
 Jeroen


Reply to: