This issue doesn't appear to be isolated to Linode, as I'm having the same trouble on another UML host (sorry Chris, I needed some redundancy! Linode IS the best, though) also. This should mean that the problem is directly related to either UML or Gentoo.

I'm fairly certain I've seen mention on the Internet of others with the problem running distros other than Gentoo, but I don't have the time right now to find them... Not sure if they were running under UML or not though...

But I wouldn't be surprised if it was a UML problem (I say this with no knowledge of the actual problem, or anything). It justs seems entirely random, and doesn't appear to happen consistently on two servers running the same setup (even the exact same processes, etc. ) Therefore, to me at least, it seems like it could be some external force at work. I'm not sure how exactly UML interfaces with the kernel in our Linodes, but something is happening...

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

grrrrrr, well, after that experience, and actually having some entropy (and an almost full pool for once!) I went ahead and "emerge -u system", and now ye ole problem is back. The Linode has been running for about 24 hours or so like this, and my entropy is getting eaten again.

So I'm gonna reinstall the Gentoo image, and not do anything, and see if it happens. Maybe one of the packages that gets updated has something to do with it....

I dunno, I'm just fishing now, but getting more and more frustrated...


UPDATE: Just reinstalled Gentoo, end the entropy was growing on its own. The only thing I did is "emerge sync" and now I'm gonna let it sit all weekend (off on a ski trip!). I guess we'll see on Monday if this means anything....

take care all, and have a great weekend. Thanks for all the help, and I hope we can nail this sucker down soon!

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

• Apple TechNote 117 •

FWIW, I'm using Gentoo and Apache2 and my SSL error_log contains entries like:

[Fri Jan 30 13:54:38 2004] [info] Seeding PRNG with 136 bytes of entropy

for every SSL access.

[This is a dedicated box but I'm a former Linode user].

So my Gentoo system has been up and running for over 72 hours now with the default Linode setup (NO emerge -u system), and all is fine. If I connect, I can check the entropy and will have some; consecutive checks usually lead to an INCREASE in entropy.

This little experiment leads me to wonder if something that gets updated in the recent Gentoo packages is the culprit? Below is what Gentoo wants to update:

localhost root # emerge -upv system

These are the packages that I would merge, in order:

Calculating system dependencies ...done!
[ebuild     U ] sys-apps/groff-1.18.1-r4 [1.18.1-r3] +X -cjk 
[ebuild     U ] sys-devel/libperl-5.8.2 [5.8.0] +berkdb +gdbm 
[ebuild     U ] dev-lang/perl-5.8.2-r1 [5.8.0-r12] +berkdb -doc +gdbm -threads 
[ebuild     U ] sys-devel/gettext-0.12.1 [0.11.5-r1] +nls 
[ebuild     U ] sys-devel/binutils-2.14.90.0.7-r4 [2.14.90.0.6-r6] +nls -bootstrap -build 
[ebuild     U ] sys-libs/ncurses-5.3-r5 [5.3-r2] -debug 
[ebuild     U ] sys-devel/gcc-config-1.3.4 [1.3.3-r1] 
[ebuild     U ] sys-devel/gcc-3.2.3-r3 [3.2.3-r2] -static +nls -bootstrap -java -build 
[ebuild     U ] sys-libs/glibc-2.3.2-r9 [2.3.2-r1] +nls -pic -build 
[ebuild     U ] app-arch/bzip2-1.0.2-r3 [1.0.2-r2] -build -static -debug 
[ebuild     U ] sys-devel/m4-1.4-r1 [1.4] +nls 
[ebuild     U ] sys-devel/autoconf-2.58 [2.57-r1] 
[ebuild     U ] sys-devel/automake-1.7.7 [1.7.5-r2] 
[ebuild     U ] sys-apps/coreutils-5.0.91-r4 [5.0-r3] +nls -build -acl -selinux -static 
[ebuild     U ] sys-apps/debianutils-1.16.7-r4 [1.16.7-r3] -static -build 
[ebuild     U ] dev-libs/openssl-0.9.7c-r1 [0.9.6k] 
[ebuild  N    ] dev-lang/python-2.3.3  +ncurses +gdbm +ssl +readline -tcltk +berkdb -bootstrap -ipv6 -build -ucs2 -doc 
[ebuild     U ] sys-apps/portage-2.0.49-r21 [2.0.49-r15] -build 
*** Portage will stop merging at this point and reload itself,
    recalculate dependencies, and complete the merge.

[ebuild     U ] net-misc/dhcpcd-1.3.22_p4-r2 [1.3.22_p4-r1] -build -static 
[ebuild     U ] net-misc/rsync-2.6.0 [2.5.6-r3] 
[ebuild     U ] net-misc/wget-1.9-r2 [1.8.2-r2] +ssl +nls -static -ipv6 -debug -socks5 
[ebuild     U ] sys-apps/kbd-1.08-r5 [1.06-r1] +nls 
[ebuild     U ] sys-apps/diffutils-2.8.4-r4 [2.8.4-r3] +nls -build -static 
[ebuild     U ] sys-fs/e2fsprogs-1.34 [1.33] +nls -static 
[ebuild     U ] sys-apps/file-4.06 [4.02] 
[ebuild     U ] sys-apps/shadow-4.0.3-r9 [4.0.3-r7] +pam -selinux 
[ebuild     U ] sys-apps/slocate-2.7-r5 [2.7-r2] 
[ebuild     U ] sys-apps/gawk-3.1.3-r1 [3.1.3] +nls -build 
[ebuild     U ] sys-apps/man-pages-1.65 [1.60] 
[ebuild     U ] sys-apps/procps-3.1.12-r1 [3.1.9] -selinux 
[ebuild     U ] sys-apps/util-linux-2.11z-r8 [2.11z-r6] +crypt +nls -static +pam 
[ebuild     U ] sys-apps/which-2.16 [2.14] 
[ebuild     U ] net-misc/openssh-3.7.1_p2-r1 [3.7.1_p2] -ipv6 -static +pam +tcpd -kerberos -skey -selinux -X509 

Now that IS a lot o' stuff, and doesn't really narrow anything down much, but could be a start...

I'm gonna post something on the Gentoo forums, see if I can't reach any conclusions over there...

UPDATE: I also ran through all my logs, and found nothing glaring (though I'm not sure if I'd know what to find... but nothing like what alphs. listed)...

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

• Apple TechNote 117 •

It appears the only way to tell would be to update things one by one.

From looking though the list I would start with openssh and openssl updates.

Adam

This lack of entropy problem is not specific to Gentoo or UML. I had the problem on a RedHat 9 machine functioning as a headless server, and I've seen a number of other situations.

The difference between /dev/random and /dev/urandom is that /dev/random will block if there is no entropy available to generate 'truly random' data. /dev/urandom will never block, but will utilize a pseudo-random number generator to create at least enough entropy to satisfy the current request for data. If entropy is available, /dev/urandom will be just as secure, however if no entropy is available, 'in theory' /dev/urandom will be less secure.

You ought to be able to find out what is depleting your entropy by running 'fuser -v /dev/random' This should give you the PID and name of any processes feeding off of /dev/random, and should give a clearer picture of where it's going. In general, I've found that bind (named), any SSL startup (including pops, imaps, and HTTPS), and any other services that might encrypt something or use random data will contribute to the depletion of entropy.

If you're having trouble getting apache to start, you can try this in your ssl.conf:

SSLRandomSeed connect file:/dev/urandom 512

To get bind to feed off /dev/urandom, you can add this to your options:

random-device "/dev/urandom"

I don't know all the best ways to help generate more entropy, but urandom is a temporary way around the problem.

Thanks for chiming in sorenson, I tried the 'fuser -v /dev/random' and got nothing.

The problem isn't a lack of entropy per se (I believe), but rapidly decreasing entropy for no apparent reason (which is backed up by the nil results of the above command).

All distros will have problems if there is no entropy, but entropy shouldn't just leak away (to my knowledge), it should happily stay in /dev/random until called for. But my problem is that if I do any action to increase my entropy, it will immediately start rapidly decreasing until it hits zero (which it does within minutes), then of course the problems start...

So there has got to be a bug somewhere. The only thing that I have running that (I believe) would even want entropy is sshd, and that should only call for entropy on connection (?)...

hmmmmm...

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

• Apple TechNote 117 •

Sorry, I had hoped it might help figure out where it was all disappearing to, but it doesn't look promising. Incidentally, I've got a similar problem on one of my headless servers at work, so I think it must be a pretty widespread problem. Our server has 0 entropy, and I cannot get it to generate any at all.

Another thing to try is to run lsof and see if _that_ shows anything holding /dev/random open. Since there appears to be a kernel bug, this probably won't show anything useful, but it's nice to check anyway. Strange that there are machines where random performs flawlessly, but others can't get entropy or can't hold onto it. On most machines, it should be possible to exhaust all entropy ('cat /dev/random > /dev/null' for example), and then watch the available entropy climb back to 4096 over the next few seconds.

It should be possible to obtain entropy from other sources and inject it into the pool, however I haven't had much luck with this either. There's definitely a bug out there somewhere. Sorry I don't have an answer or solution.

--
Frank Sorenson
http://www.tuxrocks.com/

Has anyone found any online refs for this? I'd like to learn more, but am not quite prepared (hah!) to dive into the kernel source yet.

I have found some sparse references, but no extended discussions on the problem. Most people just say to use /dev/urandom, but that's a weak solution (cuz I'd rather actually solve the problem, not just resort to a workaround... and I can't seem to replace /dev/random with urandom anyways!).

I too am searching, because I have thought about posting something on the kernel and UML mailing lists, but I'm not very knowledgable with source and stuff, and wanted something to back me up. Unfortunately, google turns up little related info...

The only links seem to be SMP machines, and usually Gentoo (but not always).

anyways, I posted a couple of links early in this thread, and am still seaching for more info. If anyone finds more, please post links here...

thanks
- j

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

• Apple TechNote 117 •

As I'm still pretty new at this all, I'd thought I'd post the output of 'lsof' here, to see if anyone else notices anything off... (As sorenson said above, it probably is worthless, as I'm thinking this is kernel-related as well, but who knows...

localhost root # lsof
COMMAND     PID USER   FD   TYPE     DEVICE    SIZE      NODE NAME
init          1 root  cwd    DIR       98,0    4096         2 /
init          1 root  rtd    DIR       98,0    4096         2 /
init          1 root  txt    REG       98,0   32952     31536 /sbin/init
init          1 root  mem    REG       98,0   96943    127254 /lib/ld-2.3.2.so
init          1 root  mem    REG       98,0 1491628    127235 /lib/libc-2.3.2.so
init          1 root   10u  FIFO        0,7               662 /dev/initctl
keventd       2 root  cwd    DIR       98,0    4096         2 /
keventd       2 root  rtd    DIR       98,0    4096         2 /
ksoftirqd     3 root  cwd    DIR       98,0    4096         2 /
ksoftirqd     3 root  rtd    DIR       98,0    4096         2 /
kswapd        4 root  cwd    DIR       98,0    4096         2 /
kswapd        4 root  rtd    DIR       98,0    4096         2 /
bdflush       5 root  cwd    DIR       98,0    4096         2 /
bdflush       5 root  rtd    DIR       98,0    4096         2 /
kupdated      6 root  cwd    DIR       98,0    4096         2 /
kupdated      6 root  rtd    DIR       98,0    4096         2 /
jfsIO         7 root  cwd    DIR       98,0    4096         2 /
jfsIO         7 root  rtd    DIR       98,0    4096         2 /
jfsCommit     8 root  cwd    DIR       98,0    4096         2 /
jfsCommit     8 root  rtd    DIR       98,0    4096         2 /
jfsSync       9 root  cwd    DIR       98,0    4096         2 /
jfsSync       9 root  rtd    DIR       98,0    4096         2 /
mdrecover    10 root  cwd    DIR       98,0    4096         2 /
mdrecover    10 root  rtd    DIR       98,0    4096         2 /
kjournald    11 root  cwd    DIR       98,0    4096         2 /
kjournald    11 root  rtd    DIR       98,0    4096         2 /
devfsd      157 root  cwd    DIR        0,7       0         1 /dev
devfsd      157 root  rtd    DIR       98,0    4096         2 /
devfsd      157 root  txt    REG       98,0   36184     31583 /sbin/devfsd
devfsd      157 root  mem    DEL       98,0             31433 /var/tmp/portage/glibc-2.3.2-r9/image/lib/ld-2.3.2.so
devfsd      157 root  mem    DEL       98,0             31499 /var/tmp/portage/glibc-2.3.2-r9/image/lib/libdl-2.3.2.so
devfsd      157 root  mem    DEL       98,0             31490 /var/tmp/portage/glibc-2.3.2-r9/image/lib/libc-2.3.2.so
devfsd      157 root  mem    DEL       98,0             31498 /var/tmp/portage/glibc-2.3.2-r9/image/lib/libnss_compat-2.3.2.so
devfsd      157 root  mem    DEL       98,0             31511 /var/tmp/portage/glibc-2.3.2-r9/image/lib/libnsl-2.3.2.so
devfsd      157 root    3r   CHR        8,0                 2 /dev/.devfsd
syslogd     682 root  cwd    DIR       98,0    4096         2 /
syslogd     682 root  rtd    DIR       98,0    4096         2 /
syslogd     682 root  txt    REG       98,0   31992     79226 /usr/sbin/syslogd
syslogd     682 root  mem    DEL       98,0             31433 /var/tmp/portage/glibc-2.3.2-r9/image/lib/ld-2.3.2.so
syslogd     682 root  mem    DEL       98,0             31490 /var/tmp/portage/glibc-2.3.2-r9/image/lib/libc-2.3.2.so
syslogd     682 root  mem    DEL       98,0             31368 /var/tmp/portage/glibc-2.3.2-r9/image/lib/libnss_files-2.3.2.so
syslogd     682 root    0u  unix 0xa04a1b00              2393 /dev/log
syslogd     682 root    1w   REG       98,0    2341     30712 /var/log/auth.log
syslogd     682 root    2w   REG       98,0    7912     30713 /var/log/syslog
syslogd     682 root    3w   REG       98,0      55     30714 /var/log/daemon.log
syslogd     682 root    4w   REG       98,0    7723     30715 /var/log/kern.log
syslogd     682 root    5w   REG       98,0       0     30716 /var/log/lpr.log
syslogd     682 root    6w   REG       98,0       0     30717 /var/log/mail.log
syslogd     682 root    7w   REG       98,0       0     30718 /var/log/user.log
syslogd     682 root    8w   REG       98,0       0     30719 /var/log/uucp.log
syslogd     682 root    9w   REG       98,0       0     30720 /var/log/imapd.log
syslogd     682 root   10w   REG       98,0       0     30721 /var/log/mail.info
syslogd     682 root   11w   REG       98,0       0     30722 /var/log/mail.warn
syslogd     682 root   12w   REG       98,0       0     30723 /var/log/mail.err
syslogd     682 root   13w   REG       98,0       0     47486 /var/log/news/news.crit
syslogd     682 root   14w   REG       98,0       0     47487 /var/log/news/news.err
syslogd     682 root   15w   REG       98,0       0     47488 /var/log/news/news.notice
syslogd     682 root   16w   REG       98,0     127     30724 /var/log/debug
syslogd     682 root   17w   REG       98,0    7547     30725 /var/log/messages
syslogd     682 root   18w   REG       98,0       0     30726 /var/log/ppp.log
klogd       684 root  cwd    DIR       98,0    4096         2 /
klogd       684 root  rtd    DIR       98,0    4096         2 /
klogd       684 root  txt    REG       98,0   23964     79227 /usr/sbin/klogd
klogd       684 root  mem    DEL       98,0             31433 /var/tmp/portage/glibc-2.3.2-r9/image/lib/ld-2.3.2.so
klogd       684 root  mem    DEL       98,0             31490 /var/tmp/portage/glibc-2.3.2-r9/image/lib/libc-2.3.2.so
klogd       684 root    0r   REG        0,2       0      4110 /proc/kmsg
klogd       684 root    1u  unix 0xa04a1780              2435 socket
dhcpcd      778 root  cwd    DIR       98,0    4096         2 /
dhcpcd      778 root  rtd    DIR       98,0    4096         2 /
dhcpcd      778 root  txt    REG       98,0   39716     31584 /var/tmp/portage/dhcpcd-1.3.22_p4-r2/image/sbin/dhcpcd (deleted)
dhcpcd      778 root  mem    DEL       98,0             31433 /var/tmp/portage/glibc-2.3.2-r9/image/lib/ld-2.3.2.so
dhcpcd      778 root  mem    DEL       98,0             31490 /var/tmp/portage/glibc-2.3.2-r9/image/lib/libc-2.3.2.so
dhcpcd      778 root    0u   CHR        1,3                12 /dev/null
dhcpcd      778 root    1u   CHR        1,3                12 /dev/null
dhcpcd      778 root    2u   CHR        1,3                12 /dev/null
dhcpcd      778 root    3u  sock        0,0              2513 can't identify protocol
dhcpcd      778 root    4u  IPv4       2514               UDP *:bootpc 
sshd        864 root  cwd    DIR       98,0    4096         2 /
sshd        864 root  rtd    DIR       98,0    4096         2 /
sshd        864 root  txt    REG       98,0  353228     79161 /var/tmp/portage/openssh-3.7.1_p2-r1/image/usr/sbin/sshd (deleted)
sshd        864 root  mem    DEL       98,0             31433 /var/tmp/portage/glibc-2.3.2-r9/image/lib/ld-2.3.2.so
sshd        864 root  mem    REG       98,0   34045     32903 /usr/lib/libwrap.so.0.7.6
sshd        864 root  mem    DEL       98,0             31509 /lib/libpam.so.0.75
sshd        864 root  mem    DEL       98,0             31499 /var/tmp/portage/glibc-2.3.2-r9/image/lib/libdl-2.3.2.so
sshd        864 root  mem    DEL       98,0             31432 /var/tmp/portage/glibc-2.3.2-r9/image/lib/libutil-2.3.2.so
sshd        864 root  mem    REG       98,0   73505     32834 /usr/lib/libz.so.1.1.4
sshd        864 root  mem    DEL       98,0             31511 /var/tmp/portage/glibc-2.3.2-r9/image/lib/libnsl-2.3.2.so
sshd        864 root  mem    DEL       98,0             32461 /var/tmp/portage/openssl-0.9.7c-r1/image/usr/lib/libcrypto.so.0.9.6
sshd        864 root  mem    DEL       98,0             31515 /var/tmp/portage/glibc-2.3.2-r9/image/lib/libcrypt-2.3.2.so
sshd        864 root  mem    DEL       98,0             31490 /var/tmp/portage/glibc-2.3.2-r9/image/lib/libc-2.3.2.so
sshd        864 root  mem    DEL       98,0             31498 /var/tmp/portage/glibc-2.3.2-r9/image/lib/libnss_compat-2.3.2.so
sshd        864 root    0u   CHR        1,3                12 /dev/null
sshd        864 root    1u   CHR        1,3                12 /dev/null
sshd        864 root    2u   CHR        1,3                12 /dev/null
sshd        864 root    3u  IPv6       2592               TCP *:ssh (LISTEN)
agetty      877 root  cwd    DIR        0,7       0         1 /dev
agetty      877 root  rtd    DIR       98,0    4096         2 /
agetty      877 root  txt    REG       98,0   14840     31570 /var/tmp/portage/util-linux-2.11z-r8/image/sbin/agetty (deleted)
agetty      877 root  mem    DEL       98,0             31433 /var/tmp/portage/glibc-2.3.2-r9/image/lib/ld-2.3.2.so
agetty      877 root  mem    DEL       98,0             31490 /var/tmp/portage/glibc-2.3.2-r9/image/lib/libc-2.3.2.so
agetty      877 root  mem    DEL       98,0             31368 /var/tmp/portage/glibc-2.3.2-r9/image/lib/libnss_files-2.3.2.so
agetty      877 root    0u   CHR        4,0               647 /dev/vc/0
agetty      877 root    1u   CHR        4,0               647 /dev/vc/0
agetty      877 root    2u   CHR        4,0               647 /dev/vc/0
lsof       5303 root  cwd    DIR       98,0    4096     31526 /root
lsof       5303 root  rtd    DIR       98,0    4096         2 /
lsof       5303 root  txt    REG       98,0   96816     99570 /usr/sbin/lsof
lsof       5303 root  mem    REG       98,0   96943    127254 /lib/ld-2.3.2.so
lsof       5303 root  mem    REG       98,0 1491628    127235 /lib/libc-2.3.2.so
lsof       5303 root    0u   CHR      136,1              1284 /dev/pts/1
lsof       5303 root    1u   CHR      136,1              1284 /dev/pts/1
lsof       5303 root    2u   CHR      136,1              1284 /dev/pts/1
lsof       5303 root    3r   DIR        0,2       0         1 /proc
lsof       5303 root    4r   DIR        0,2       0 347537416 /proc/5303/fd
lsof       5303 root    5w  FIFO        0,5            567405 pipe
lsof       5303 root    6r  FIFO        0,5            567406 pipe
lsof       5304 root  cwd    DIR       98,0    4096     31526 /root
lsof       5304 root  rtd    DIR       98,0    4096         2 /
lsof       5304 root  txt    REG       98,0   96816     99570 /usr/sbin/lsof
lsof       5304 root  mem    REG       98,0   96943    127254 /lib/ld-2.3.2.so
lsof       5304 root  mem    REG       98,0 1491628    127235 /lib/libc-2.3.2.so
lsof       5304 root    4r  FIFO        0,5            567405 pipe
lsof       5304 root    7w  FIFO        0,5            567406 pipe
sshd      22180 root  cwd    DIR       98,0    4096         2 /
sshd      22180 root  rtd    DIR       98,0    4096         2 /
sshd      22180 root  txt    REG       98,0  353228     79161 /var/tmp/portage/openssh-3.7.1_p2-r1/image/usr/sbin/sshd (deleted)
sshd      22180 root  mem    DEL       98,0             31433 /var/tmp/portage/glibc-2.3.2-r9/image/lib/ld-2.3.2.so
sshd      22180 root  mem    REG       98,0   34045     32903 /usr/lib/libwrap.so.0.7.6
sshd      22180 root  mem    DEL       98,0             31509 /lib/libpam.so.0.75
sshd      22180 root  mem    DEL       98,0             31499 /var/tmp/portage/glibc-2.3.2-r9/image/lib/libdl-2.3.2.so
sshd      22180 root  mem    DEL       98,0             31432 /var/tmp/portage/glibc-2.3.2-r9/image/lib/libutil-2.3.2.so
sshd      22180 root  mem    REG       98,0   73505     32834 /usr/lib/libz.so.1.1.4
sshd      22180 root  mem    DEL       98,0             31511 /var/tmp/portage/glibc-2.3.2-r9/image/lib/libnsl-2.3.2.so
sshd      22180 root  mem    DEL       98,0             32461 /var/tmp/portage/openssl-0.9.7c-r1/image/usr/lib/libcrypto.so.0.9.6
sshd      22180 root  mem    DEL       98,0             31515 /var/tmp/portage/glibc-2.3.2-r9/image/lib/libcrypt-2.3.2.so
sshd      22180 root  mem    DEL       98,0             31490 /var/tmp/portage/glibc-2.3.2-r9/image/lib/libc-2.3.2.so
sshd      22180 root  mem    DEL       98,0             31498 /var/tmp/portage/glibc-2.3.2-r9/image/lib/libnss_compat-2.3.2.so
sshd      22180 root  mem    CHR        1,5                14 /dev/zero
sshd      22180 root  mem    CHR        1,5                14 /dev/zero
sshd      22180 root    0u   CHR        1,3                12 /dev/null
sshd      22180 root    1u   CHR        1,3                12 /dev/null
sshd      22180 root    2u   CHR        1,3                12 /dev/null
sshd      22180 root    3r  FIFO        0,5            467110 pipe
sshd      22180 root    4u  IPv6     467099               TCP li3-113.members.linode.com:ssh->YahooBB123.bbtec.net:1167 (ESTABLISHED)
sshd      22180 root    5w  FIFO        0,5            467110 pipe
sshd      22180 root    6u   CHR        5,2                21 /dev/ptmx
sshd      22180 root    7u   CHR        5,2                21 /dev/ptmx
sshd      22180 root    8u   CHR        5,2                21 /dev/ptmx
bash      22182 root  cwd    DIR       98,0    4096     31526 /root
bash      22182 root  rtd    DIR       98,0    4096         2 /
bash      22182 root  txt    REG       98,0  722496     31126 /bin/bash
bash      22182 root  mem    REG       98,0   96943    127254 /lib/ld-2.3.2.so
bash      22182 root  mem    REG       98,0   13708    126781 /lib/libdl-2.3.2.so
bash      22182 root  mem    REG       98,0 1491628    127235 /lib/libc-2.3.2.so
bash      22182 root  mem    REG       98,0   33784    127249 /lib/libnss_compat-2.3.2.so
bash      22182 root  mem    REG       98,0   89590    127247 /lib/libnsl-2.3.2.so
bash      22182 root  mem    REG       98,0   40981    127248 /lib/libnss_nis-2.3.2.so
bash      22182 root  mem    REG       98,0   43049    127241 /lib/libnss_files-2.3.2.so
bash      22182 root    0u   CHR      136,1              1284 /dev/pts/1
bash      22182 root    1u   CHR      136,1              1284 /dev/pts/1
bash      22182 root    2u   CHR      136,1              1284 /dev/pts/1
bash      22182 root  255u   CHR      136,1              1284 /dev/pts/1

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

• Apple TechNote 117 •

There is nothing like bring an old thread back to life.

I booted gentoo using the new 2.6 kernel and it took ages for apache2 to load, a lot longer than it did under 2.4

I removed random and added a symlnk to urandom and apache2 started almost straight away.

It may not be as secure but does make things happen a lot quicker.

Adam

You may have also broken your system.

It is best to recreate /dev/random (mknod /dev/random c 1 8) and to tell Apache to use something besides /dev/random. IE: the following

#SSLRandomSeed startup file:/dev/random  512
SSLRandomSeed startup file:/dev/urandom 512
#SSLRandomSeed connect file:/dev/random  512
SSLRandomSeed connect file:/dev/urandom 512

You should also consider filing a bug report with Gentoo.

Bill Clinton

I agree. I had tried to do this earlier, with not so good results. That's my main problem here. Is there a way to get the whole system to use /dev/urandom instead of /dev/random? I've gotten Apache2 to use it with a specific command in the Apache config, but I want the whole system to use /dev/random with no more action on my part ...




There have been bug reports filed with Gentoo, but they claim it is not a Gentoo issue. I'm not sure of the particulars of why, but I have noticed people using other distros (Debian, IIRC) having the same issues. It does seem to happen more often with Gentoo, but I tend to think it is a kernel issue. And sadly, it seems that 2.6 hasn't fixed it. (The reason I say it is a kernel issue is from reading tons of email threads from the people who implemented it in the kernel, and seeing their issues with it. It seems like something that never got much thought put into it (by way of implementation), and hasn't been looked at much since. )

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

• Apple TechNote 117 •