------
Edit: It looks like a Gentoo bug so feel free to move this topic. See http://forums.gentoo.org/viewtopic.php?t=151105
My problem appears also when rebooting the Linode, not only when (re)strating Apache from ssh.
------

I don't know if this is really a Linode bug or if I should post this to the Gentoo forums. Oh, and I did search the forum before posting but didn't find any relevant info about this.

I installed the Gentoo distro on my Linode 128, synced to the latest portage and now got Apache 2.0.49, PHP 4.3.6-RC2 and MySQL 4.0.18. Apache and MySQL are configured to start at the default level (rc-update add apache default) and for Apache I modified the /etc/conf.d/apache2 so it starts with "-D PHP4" and load the php4 module. I'm not using SSL on apache and I'm using the latest 2.4 kernel (2.4.25)

Now the trouble: If I want to just restart Apache, or reboot my Linode, Apache won't serve any page (even if it loads) untill I ssh again into my Linode.

For example.
1) If I reboot my Linode, then I have to ssh into my Linode and Apache instantly gets working (as soon as I access the 22 port with my ssh client).
2) If I am already into a ssh session and I wish to restart Apache with "/etc/init.d/apache2 restart" or the "stop" and "start" sequence of commands, then apache stops ok, loads up ok (but only one process is seen in top/ps, no child process) and its dead, i.e. if I try to access a web page on my linode, my browser just keeps waiting for an answer but it wont receive any error nor would it die with an error ... Now, as soon as I logout from my ssh session and then ssh again, my browser instantly receives the page. After this, when I look into top or ps there are the normal multiple apache2 child processes.

I found this on the official Gentoo forums:
http://forums.gentoo.org/viewtopic.php?t=151105

It seems to be almost the same issue, but I have problems even when rebooting my Linode, not only when I'm restarting apache from ssh. In that thread the workaround was to kill the auth_digest module which seems to conflict with the ssh seed/random generation (?).
I have the same entry in the error_log:

[Fri Apr 09 13:28:37 2004] [notice] Digest: generating secret for digest authentication ...
[Fri Apr 09 13:36:05 2004] [notice] Digest: done

You see that 8 minutes difference between it started generating the "secret" for digest and "done"? Thats how long it waited untill i SSH-ed into my Linode.

If I remove the auth_digest module it works indeed ok, always. But I did have some pages using digest authentiaction.

I can't say I'm a linux expert so if any more experienced linux user has an idea, please help!

Thanks a lot,
Bogdan

Hi,

It is an entrope problem.

Try switching apache over to use urandom, instead or random.

There is a big thread on entrope on the forum.

Adam

_________________
Programs that crash have been proven to be less useful than those that don't.
• Apple TechNote 117 •

After a couple more searches here and on the official forum, I found a huge amount of data reffering to this problem.

Sorry for the lack of vigilance ...

It is annoying anyway. What's more annoying is that in my case apache won't start even after a fresh reboot (entropy is eaten up that quickly) ...

Yep, that's how it is. It sucks. But I don't think it's only a Gentoo thing (though primarily it seems so).

Oh well, the only real options are to

1. comment out auth_digest_module

or

2. re-emerge apache with:

MY_BUILTINS="--with-devrandom=/dev/urandom" emerge apache

personally I did number 2. while I don't require auth_digest_module right now, i may in the future. and I'm fine with the randomness of urandom...

_________________
Programs that crash have been proven to be less useful than those that don't.

• Apple TechNote 117 •

Yep, i saw that other distros have/had the same issue. Redhat even put urandom by default if im not mitaking.

I went with 1. for the time being.

What's even more weird is why the devs dont do something about this. The bug have been reported to several distros bug-lists, still no one came with a fix .. just workarounds. Still better than having problems tho

Cheers