I recently upgraded my webserver, and now Apache isn't starting. I have made no changes to the configuration - the only other this that I did was to install php-curl. My error is this: [:crit] [pid 1574] (38)Function not implemented: AH00141: Could not initialize random number generator There are a few things that I have seen online, but none have lead to a resolution. Anyone have any thoughts? Thanks!
On Tue, Oct 06, 2020 at 05:10:19PM -0400, William Witteman via talk wrote:
I recently upgraded my webserver, and now Apache isn't starting. I have made no changes to the configuration - the only other this that I did was to install php-curl.
My error is this: [:crit] [pid 1574] (38)Function not implemented: AH00141: Could not initialize random number generator
There are a few things that I have seen online, but none have lead to a resolution.
Anyone have any thoughts?
It sounds like either your kernel or glibc are too old (or not configured) to support the getrandom system call. Was the apache built for a different release than you are running? -- Len Sorensen
On Wed, 7 Oct 2020 at 09:44, Lennart Sorensen <lsorense@csclub.uwaterloo.ca> wrote:
On Tue, Oct 06, 2020 at 05:10:19PM -0400, William Witteman via talk wrote:
I recently upgraded my webserver, and now Apache isn't starting. I have made no changes to the configuration - the only other this that I did was to install php-curl.
My error is this: [:crit] [pid 1574] (38)Function not implemented: AH00141: Could not initialize random number generator
It sounds like either your kernel or glibc are too old (or not configured) to support the getrandom system call.
Was the apache built for a different release than you are running?
These are good thoughts - that's what makes this so weird, as I am running standard Debian "testing", and I've got both /dev/random and /dev/urandom. I tried digging into the source of Apache to see if there's a nuance to the call, but I don't know enough about Apache to even find the error code (which I would have thought would be pretty easy, but no.) My temporary work-around has been to change my whole webserver, and got nginx installed and configured for all of my domains, but it's a very brute force approach, and took a couple of hours, as I don't really know nginx.
On Wed, Oct 07, 2020 at 10:03:27AM -0400, William Witteman via talk wrote:
These are good thoughts - that's what makes this so weird, as I am running standard Debian "testing", and I've got both /dev/random and /dev/urandom. I tried digging into the source of Apache to see if there's a nuance to the call, but I don't know enough about Apache to even find the error code (which I would have thought would be pretty easy, but no.)
/dev/random and /dev/urandom are not the same as the getrandom syscall. The /dev files are the old method of getting random numbers.
My temporary work-around has been to change my whole webserver, and got nginx installed and configured for all of my domains, but it's a very brute force approach, and took a couple of hours, as I don't really know nginx.
Did you install apache from testing too? Is everything consistently installed from testing? -- Len Sorensen
On Wed, Oct 07, 2020 at 09:43:37PM -0400, William Witteman via talk wrote:
Yes, it's all from testing - I just apt-get installed it, and didn't do anything clever.
So what kernel version do you have running (uname -a) Which glibc version (dpkg -l libc6) Which apache version (dpkg -l apache2) -- Len Sorensen
On Thu, 8 Oct 2020 at 09:57, Lennart Sorensen <lsorense@csclub.uwaterloo.ca> wrote:
On Wed, Oct 07, 2020 at 09:43:37PM -0400, William Witteman via talk wrote:
Yes, it's all from testing - I just apt-get installed it, and didn't do anything clever.
So what kernel version do you have running (uname -a) Which glibc version (dpkg -l libc6) Which apache version (dpkg -l apache2)
Linux vps62474.vps.ovh.ca 3.16.0-4-amd64 #1 SMP Debian 3.16.51-2 (2017-12-03) x86_64 GNU/Linux ii libc6:amd64 2.31-3 amd64 GNU C Library: Shared libraries ii apache2 2.4.46-1 amd64 Apache HTTP Server Thanks for looking into this!
On Thu, Oct 08, 2020 at 10:23:53AM -0400, William Witteman wrote:
Linux vps62474.vps.ovh.ca 3.16.0-4-amd64 #1 SMP Debian 3.16.51-2 (2017-12-03) x86_64 GNU/Linux ii libc6:amd64 2.31-3 amd64 GNU C Library: Shared libraries ii apache2 2.4.46-1 amd64 Apache HTTP Server
Thanks for looking into this!
That kernel is your problem. That in no way has any business being on debian testing. Current Debian stable uses 4.19. Previous stable was 4.9. 3.16 is from at least 5 years ago and certainly is missing a ton of features required by any system these days. Is this some weird hosted container system? If so, that is too old to be useful for anyone. -- Len Sorensen
On Thu, Oct 08, 2020 at 10:34:12AM -0400, Lennart Sorensen via talk wrote:
On Thu, Oct 08, 2020 at 10:23:53AM -0400, William Witteman wrote:
Linux vps62474.vps.ovh.ca 3.16.0-4-amd64 #1 SMP Debian 3.16.51-2 (2017-12-03) x86_64 GNU/Linux ii libc6:amd64 2.31-3 amd64 GNU C Library: Shared libraries ii apache2 2.4.46-1 amd64 Apache HTTP Server
Thanks for looking into this!
That kernel is your problem. That in no way has any business being on debian testing. Current Debian stable uses 4.19. Previous stable was 4.9. 3.16 is from at least 5 years ago and certainly is missing a ton of features required by any system these days.
Is this some weird hosted container system? If so, that is too old to be useful for anyone.
Actually looking at the kernel version, that is a Debian style version, it is just totally obsolete. Make sure you have the package 'linux-image-amd64' installed, which will keep your kernel at the current debian version whenever you do a proper upgrade. Note a proper upgrade is apt-get dist-upgrade (not apt-get update) or apt full-upgrade (probably preferred these days over apt-get). upgrade only upgrades package versions, but won't install any new package names, while dist-upgrade/full-upgrade will allow new packages to be installed, and since a new kernel version has a new package name (since the version is in the name) you need the full upgrade in order to get a kernel upgrade. upgrade is only valid within a release to get point release updates and security fixes. To go to another release, or in fact anytime when running testing or unstable where things change a lot, the full upgrade is often required. -- Len Sorensen
On Thu, 8 Oct 2020 at 10:43, Lennart Sorensen <lsorense@csclub.uwaterloo.ca> wrote:
On Thu, Oct 08, 2020 at 10:34:12AM -0400, Lennart Sorensen via talk wrote:
That kernel is your problem. That in no way has any business being on debian testing. Current Debian stable uses 4.19. Previous stable was 4.9. 3.16 is from at least 5 years ago and certainly is missing a ton of features required by any system these days.
Good to know! I may have somehow got a bad repository? Here's why I think that: sudo apt full-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. ...and: linux-image-amd64 is already the newest version (5.8.10-1). What's weird is that the apt sources seems pretty standard: sudo head /etc/apt/sources.list deb http://ftp.debian.org/debian/ testing main deb http://security.debian.org/ testing-security main
William Witteman via talk wrote:
On Thu, Oct 08, 2020 at 10:34:12AM -0400, Lennart Sorensen via talk wrote:
That kernel is your problem. That in no way has any business being on debian testing. Current Debian stable uses 4.19. Previous stable was 4.9. 3.16 is from at least 5 years ago and certainly is missing a ton of features required by any system these days.
...
linux-image-amd64 is already the newest version (5.8.10-1).
What's the uptime like on that system? Going past two kilodays is possible; I've done it. But you end up with a seriously ancient kernel underpinning the system. Rebooting once a year or so is probably reasonable. -- Anthony de Boer
On Thu, Oct 08, 2020 at 11:24:08AM -0400, Anthony de Boer wrote:
What's the uptime like on that system?
Going past two kilodays is possible; I've done it. But you end up with a seriously ancient kernel underpinning the system.
Rebooting once a year or so is probably reasonable.
Good point. :) I recently noticed my desktop machine at work had an uptime of about 1 year. I decided it could be rebooted. Funnily enough, the windows laptop never seems to have that problem. -- Len Sorensen
On Thu, Oct 08, 2020 at 11:05:10AM -0400, William Witteman via talk wrote:
Good to know!
I may have somehow got a bad repository? Here's why I think that: sudo apt full-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
...and:
linux-image-amd64 is already the newest version (5.8.10-1).
What's weird is that the apt sources seems pretty standard: sudo head /etc/apt/sources.list deb http://ftp.debian.org/debian/ testing main
deb http://security.debian.org/ testing-security main
OK, what do you get from this: dpkg -l |grep linux-image Maybe you have the new kernel installed, but the boot loader isn't configured to use it. -- Len Sorensen
On Thu, 8 Oct 2020 at 11:38, Lennart Sorensen <lsorense@csclub.uwaterloo.ca> wrote:
OK, what do you get from this:
dpkg -l |grep linux-image
Maybe you have the new kernel installed, but the boot loader isn't configured to use it.
Bingo! I am not sure why, but I'm definitely not getting the latest of the installed images as my default. It's a remote VM from ovh.ca, so I never see a GRUB screen. The uptime is less than two days, because this issue happened after a reboot. Interesting wrinkle, is that I don't seem to have grub or grub2 installed.
On Thu, Oct 08, 2020 at 12:25:34PM -0400, William Witteman via talk wrote:
On Thu, 8 Oct 2020 at 11:38, Lennart Sorensen <lsorense@csclub.uwaterloo.ca> wrote:
OK, what do you get from this:
dpkg -l |grep linux-image
Maybe you have the new kernel installed, but the boot loader isn't configured to use it.
Bingo! I am not sure why, but I'm definitely not getting the latest of the installed images as my default. It's a remote VM from ovh.ca, so I never see a GRUB screen.
The uptime is less than two days, because this issue happened after a reboot.
Interesting wrinkle, is that I don't seem to have grub or grub2 installed.
Hmm, I wonder which bootload it is using then. I think grub2 depends on grub-pc and grub-common. Could also use grub-efi, although I doubt that. Could always install grub2 and see what it does. What do you have in /boot? 'find /boot' should give a list that hopefully isn't too long. -- Len Sorensen
On 2020-10-08 12:46, Lennart Sorensen via talk wrote:
Bingo! I am not sure why, but I'm definitely not getting the latest of the installed images as my default. It's a remote VM from ovh.ca, so I never see a GRUB screen.
The uptime is less than two days, because this issue happened after a reboot.
Interesting wrinkle, is that I don't seem to have grub or grub2 installed.
Hmm, I wonder which bootload it is using then. I think grub2 depends on grub-pc and grub-common. Could also use grub-efi, although I doubt that.
Could always install grub2 and see what it does. What do you have in /boot?
'find /boot' should give a list that hopefully isn't too long.
It sounds like OVH VMs use extlinux, so this article's instructions should help: https://hubesco.com/blog/index.php?article47/update-linux-kernel-on-ovh-vps-... Cheers, Jamon
On Thu, Oct 08, 2020 at 01:48:19PM -0400, Jamon Camisso via talk wrote:
It sounds like OVH VMs use extlinux, so this article's instructions should help:
https://hubesco.com/blog/index.php?article47/update-linux-kernel-on-ovh-vps-...
That's useful. Quite an annoying setup though. -- Len Sorensen
participants (4)
-
Anthony de Boer -
Jamon Camisso -
lsorense＠csclub.uwaterloo.ca -
William Witteman