/dev/random not being seeded
(i.e. having to comment out authdigestmodule in apache2 in order to get apache2 to spawn child processes)
I came across the following info:
In effect, apache2 needs to read some data from /dev/random in order to generate keys when starting up authdigest, and can't because there is no entropy in /dev/random, so the startup fails. One solution is to comment out the authdigest_module, and the other is to populate /dev/random.
This is where I am having trouble. Suggestions on the Gentoo forums include running du /usr in order to seed the random with the disk access… but this fails on my Linode. I have a feeling it's because our kernel doesn't have direct hardware access because it is running under UML. Is this a reasonable assumption?
And if so, any suggestions on how to populate /dev/random and /dev/urandom ? This can be a problem for many other programs other than just apache2, because any program that relies on random data may fail…
So does anyone else have any info in /dev/random, or is this just a Gentoo problem. If my above assumptions are correct, it may be a Linode problem in general…
(One can go to /proc/sys/kernel/random and read entropy_avail to see if they have any info in random. If it says "0", you don't…)
thanks
- j
60 Replies
Wonder why I can't get /dev/random to populate? Any suggestions anyone?
From what I've read, disk access should populate /dev/random, that's why I read "du /usr" should work. But it doesn't for me.
In further researching, I've found these threads, one guy runs under UML and has no problems:
Anyone else having problem with /dev/random? How else does /dev/random get populated? Shouldn't the kernel populate it, as well as just about all other disk access, etc?
pclissold, which kernel are you running under? From what I've read, this may be a kernel issue…
Also, what bad things can happen with no entropy? I know apparently apache has problems with auth_digest, and Ive read ssl over apache wont work right. Also, ssh uses /dev/random, so what effect should this have on my ssh session Im using now?
Sorry for all the questions, I'm just at a loss for what to do, and cant' even find any more info out there…
thanks
- j
p.s. on last question, how does one find out which processes are calling /dev/random for entropy?
No sooner do i post that long-ass reply above, but i reboot my linode again, and immediately go off to "/proc/sys/kernel/random/entropy_avail" and now I have some. I run "du /usr" to kick it up, and it does.
But immediately starts plummeting, and goes completely empty in about 60-120 seconds.
So what may be sucking it dry so fast? What would be constantly accessing it? Any ideas? How do I find out what processes are calling it?
At least now, running "du /usr" will repopulate it, at least temporarily…
@wazdog:
pclissold, which kernel are you running under? From what I've read, this may be a kernel issue…
Currently running 2.4.24-linode20-1um
michael@orion michael $ ls /etc/runlevels/default/
apache2 courier domainname hostname iptables local mysql net.eth0 net.lo netmount ntpd pdnsd sshd sysklogd vcron
nothing there would strike me as being the problem right off. As for adding entropy lots of stuff do it. Disk and other i/o and cpu usage are the big ones though. This seems odd. What kernel are you using and what do you have starting up at boot wazdog?
pclissold could you also paste your list of applications starting up?
wazdog: sorry for not replying sooner, was out of town
@mikegrb:
pclissold could you also paste your list of applications starting up?
peter@fremont peter $ ls /etc/runlevels/default
apache2 courier-imapd courier-imapd-ssl courier-pop3d courier-pop3d-ssl domainname hostname local mysql net.eth0 net.lo netmount postfix saslauthd sshd sysklogd
my defaults are
hobbes root # ls /etc/runlevels/default/
domainname hostname local mysql net.eth0 net.lo netmount sshd sysklogd webmin
mike, are you showing 0 entropy as well? or are you stocked up?
i'm running 2.4.24-linode20-1um as well…
Here is what i've done so far (been keeping a log, so hey, guess it'll come in handy!):
emerge sync && emerge screen && emerge -u system && emerge -u world && emerge gentoolkit
emerge apache2 php modphp mysql postfix bind bindtools webmin
and that's about it. I've had some other stuff pulled in by php, but nothing major. only started apache2 up once, and got only one child, so went searching on the gentoo forums…
--
okay, i just checked my other gentoo host (on another linode host) and the entropy seems fine now, BUT I know for a fact that I had the apache2 problem on that host as well, but in that case, I've commented out auth_digest….
and no, apache2 is not currently running on the host that has the entropy problem (and it's back down to zero and not rising whatever i do…)
weird.
- j
pclissold, do you use screen?
Here is the output of pstree, listing all running processes:
michael@orion michael $ pstree
init-+-agetty
|-apache2-+-13*[apache2]
| `-apache2---nph-irc.cgi
|-authdaemond.pla---5*[authdaemond.pla]
|-bdflush
|-courierd---courierd-+-courierdsn
| |-courieresmtp---courieresmtp
| |-courierfax
| |-courierlocal
| `-courieruucp
|-courierfilter
|-3*[courierlogger]
|-couriertcpd---couriertls---imapd
|-couriertcpd
|-couriertls
|-cron---cron---startserver.sh---sleep
|-devfsd
|-gim.pl
|-infobot
|-ircd---4*[servlink]
|-jfsCommit
|-jfsIO
|-jfsSync
|-keventd
|-kjournald
|-klogd
|-ksoftirqd_CPU0
|-kswapd
|-kupdated
|-mdrecoveryd
|-mysqld_safe---mysqld---mysqld---6*[mysqld]
|-ntpd
|-pdnsd---pdnsd---2*[pdnsd]
|-screen-+-bash---irssi
| |-bash---mutt
| `-bash---pstree
|-screen---bash---irssi
|-screen-+-bash---irssi
| `-bash
|-sshd---3*[sshd---sshd---bash---screen]
`-syslogd
Okay, I just stopped all services, except those that run by default on caker's setup… then ran "emerge sync" to get some entropy, and got up to 600 (the highest Ive ever noticed, which isnt good, eh, cuz I should have up to 4k, right?)
But it's slowly fading away. Not as fast as before, but its constantly decreasing…
this is all i got going now
hobbes root # pstree
init-+-agetty
|-bdflush
|-devfsd
|-dhcpcd
|-jfsCommit
|-jfsIO
|-jfsSync
|-keventd
|-kjournald
|-klogd
|-ksoftirqd_CPU0
|-kswapd
|-kupdated
|-mdrecoveryd
|-sshd---sshd---bash---pstree
`-syslogd
Should my entropy be seeping away? Is ssh or something else constantly requesting it? I was under the impression it was only really used to create keys, etc…
thanks for helping
-j
p.s. sorry for asking again, but mike are you having the entropy problem too, or just the apache2 startup problem?
@mikegrb:
pclissold, do you use screen?
Never on this Linode.
pclissold, do you mind posting pstree output?
entropy could be being used by ssh. I know the server has a key that is regenerated every hour or some such. I don't know if it continues to use entropy, I wouldn't imagine so. Do you normally have an ssh session open pclissold and wazdog? I normally have at least one normally two or three.
Edit:
doing du -sh /usr and checking during and after show no entropy available. What does a normal pstree look like for you wazdog? With normal stuff running do you still see some entropy available after du /usr or do you see none?
At the rate mine entropy decreases, ssh would have to be regenerating keys every minute…
i don't know, weird.
I just went through my log files, nothing suspect, but hey, how would I know really? This one's got me stumped…
(though i did verify that this IS the reason authdigest wont work… in my apache errorlog, apache choked on: "[Sun Jan 25 13:49:43 2004] [notice] Digest: generating secret for digest authentication …")
- j
okay, off to bed, gotta hit the slopes tomorrow morning. i'll check back in a day… thanks all, take care
I wasn't even able to get it to increase until after I'd rebooted 2 or 3 times, then all of a sudden "du /usr" would cause an increase, where previously it had no effect…
fremont root # pstree
init-+-apache2---11*[apache2]
|-authdaemond.pla---5*[authdaemond.pla]
|-bdflush
|-4*[courierlogger]
|-4*[couriertcpd]
|-devfsd
|-jfsCommit
|-jfsIO
|-jfsSync
|-keventd
|-kjournald
|-klogd
|-ksoftirqd_CPU0
|-kswapd
|-kupdated
|-login---bash---pstree
|-master-+-pickup
| `-qmgr
|-mdrecoveryd
|-mysqld_safe---mysqld---mysqld---2*[mysqld]
|-saslauthd---4*[saslauthd]
|-sshd---sshd---sshd---bash---mutt
`-syslogd
I usually have at least one ssh session running.
@blahrus:
I want to hit the slopes
yeah, it'll be nice, but it's gonna be a long day. I teach English in a \ junior high here in japan (and speak VERY little japanese myself) and tomorrow the entire 8th grade is going to "ski school" and I get to help teach! I'm excited, but kinda worried. I'm a good skier, and not a bad ski instructor,… but if I get beginners, the language barrier + ski terror is gonna be hard to overcome…
anyways, it'll still be a good time i hope!
@blahrus:
hey at lest you wont be in a small office all day
:)
oh, i was only half-a$ed complaining…
I have authdigestmodule running without a problem
but my entropy is 0 as well.
Adam
Just from what I scanned around the net though, not having entropy can do some wacky things to your system, and you may not realize why. So I think we need to figure out what's going on here soon!…
The likely causes of entropy depletion:
generation of session keys for SSL, etc (support for this theory: users of headless machines reporting IMAP-SSL mail folders take ages to open when entropy_avail is too low - you have to wait for a system event to generate some more randomness),
randomisation of TCP initial sequence numbers (although the TCP stack doesn't block when entropy_avail is too low).
The likely causes of too little entropy being generated:
Linode hosts (and other remote servers) are headless so there are no keyboard or mouse event interrupts which are two of the main entropy sources on workstations (this is a known problem and was addressed by adding network activity timing as an entropy source),
Linodes use ATA RAID arrays with caches in the controllers and perform disk caching at the host level, thus generating a lot less interrupts than an standard ATA controller coupled with small system caches (support for this theory: the first use (today) of du /usr pumped the entropy up from 3666 to 3825, the second time (around a minute later) and the third time (ten minutes later) it had no effect),
Use of NIC interrupt timing as an entropy source used to be a kernel compile time option with the default set to 'off' - perhaps caker can tell us if this is on in our kernels? - plus Linode NICs have large packet queues, reducing entropy generation even if it is on plus (again) not all NIC drivers pass the data to the kernel anyway.
Question:
How is the (hardware derived) data needed for entropy generation passed from the host to the Linodes? (Do all Linodes see all interrupt timing data, only data related to their own operations or does UML fake this somehow?)
@pclissold:
- Use of NIC interrupt timing as an entropy source used to be a kernel compile time option with the default set to 'off' - perhaps caker can tell us if this is on in our kernels?
Which kernel option is this?
@pclissold:
plus Linode NICs have large packet queues, reducing entropy generation even if it is on plus (again) not all NIC drivers pass the data to the kernel anyway.?
e1000 in polling mode
@pclissold:
Question:
How is the (hardware derived) data needed for entropy generation passed from the host to the Linodes? (Do all Linodes see all interrupt timing data, only data related to their own operations or does UML fake this somehow?)
Looking at the UML source, it appears (to me at least) that each UML has its own random sub-system, not relying on the host for available entropy. Interrupts are kept private to each UML, so reads/writes to UBD devices and your ethernet device will generate interrupts (among other things).
-Chris
@caker:
@pclissold:
- Use of NIC interrupt timing as an entropy source used to be a kernel compile time option with the default set to 'off' - perhaps caker can tell us if this is on in our kernels?
Which kernel option is this?
I was thinking of CONFIGNETRANDOM but now I'm at home and have had another look I don't think it's relevant to this discussion.
Right now my server is running nothing but the default processes that are in caker's setup, and something is taking up my entropy. Tonight, when I get home, I will set up a new disk image with a clean install, and see if I have this problem. It should work correctly out-of-the-box, right?
pclissold, how old is your system? I'm sure you've done lots of configuring to it, but have you done anything that you think might be related to this?
…
First:
@bugs.gentoo.org:
modauthdigest needs 20 bytes of raw entropy to start
So if you can get your entrophy up temporarily, then Apache2 should work fine until next restart?
Secondly, re-emerge Apache2 with the following options:
@forums.gentoo.org:
MY_BUILTINS="–with-devrandom=/dev/urandom" emerge apache
So, this is apparently "less secure", but negliably so?
Third, solve all entropy problems by moving /dev/random and creating a link from /dev/urandom to /dev/random.
Again, of questionable security, see above.
Fourth, recompile the kernel to use another source of random data.
This would probably not be any use, because it seems our issue isn't creating random entropy, but maintaining it…
Anyway, hopefully someone will figure out why we are losing entropy at crazy rates. I'm working on it, but am really stuck. Scouring the internet, I've found many people suffering the same issues, but no reasons for these issues, and only the solutions listed above. I'm still hunting, though…
- j
@wazdog:
pclissold, how old is your system? I'm sure you've done lots of configuring to it, but have you done anything that you think might be related to this?
System was built Dec 2003 - Gentoo with the following USE flags:
USE="-oss -apm -arts -avi -cups -foomaticdb -gtk -imlib -kde -gnome -mad -mikmod -motif -opengl -qt -svga -truetype -X -xmms -xv acl apache2 cscope curl imap innodb java maildir mysql perl sasl socks5"
I installed and configured the usual suspects (apache2, courier, cyrus-sasl, mysql, postfix), all from the standard portage tree. Nothing out of the ordinary.
The /dev/random vs /dev/urandom debate raged in the kernel list a few years ago. The consensus appeared to be that /dev/urandom is sufficient unless either:
SHA1 was compromised, or
the NSA was after you.
In case 1, SSH (and we all) are screwed regardless of our choice of entropy source. In case 2, you probably have more important things to worry about than Linode security.
cat /proc/sys/kernel/random/entropy_avail
and I had some. Did the ole "du /usr", got a bunch more. AND IT STAYED. kept catting the avail, and it actually grew sometimes.
My pstree is the exact same as the one I posted above, so what is up here? weird.
I guess I'm just going to start over. Not a fun prospect, but I want to figure out what is causing this, so I guess I'll check after EVERY thing I do…
- j
p.s. by the way, anyone know how I'd go about replacing /dev/random with /dev/urandom? I was going to just mv /dev/random and then create a link to urandom, but I can't move /dev/random…
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…
@wazdog:
okay, i just reinstalled Gentoo from the LCP. first thing I did when connecting, was
cat /proc/sys/kernel/random/entropy_avail
and I had some. Did the ole "du /usr", got a bunch more. AND IT STAYED. kept catting the avail, and it actually grew sometimes.
…
I guess I'm just going to start over.
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!
[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].
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)…
From looking though the list I would start with openssh and openssl updates.
Adam
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.
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…
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
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
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
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
@adamgent:
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.
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
> You may have also broken your system.
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 …
> You should also consider filing a bug report with Gentoo.
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. )
@wazdog:
Is there a way to get the whole system to use /dev/urandom instead of /dev/random?
Long story short: no
@wazdog:
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.
"Fixing" the problem isn't that hard. What you need to do is generate lots of activity in a semi-random fashion to add to the "entropy pool" at boot time, just enough to hold you over the boot process (we have to assume that once the boot process is done, server activity alone will be enough to continually feed /dev/random and /dev/urandom).
I'm no expert on this, so I can't really give much meaningful advice. The one small piece of advice I can give is to hit up http://www.random.org
Bill Clinton
@Bill Clinton:
"Fixing" the problem isn't that hard. What you need to do is generate lots of activity in a semi-random fashion to add to the "entropy pool" at boot time, just enough to hold you over the boot process (we have to assume that once the boot process is done, server activity alone will be enough to continually feed /dev/random and /dev/urandom).
Actually, no. Go back and read the previous posts here. Generating entropy may be a problem for some people (I have seen reports on the Internet about that), but I personally don't have that problem, and I don't think that is what others here are having problems with either.
My problem is that something is eating up my entropy, and doing it really quickly. And this happens when I have next to nothing running (i.e. the default programs that come in the Linode Gentoo base image). The only thing I see that may use random entropy is ssh, but I can't see any reason why it would be constantly taking entropy. It is my understanding it needs some when it first negotiates a connection, in order to generate keys or something. Not constantly.
I can go from a full entropy pool (4k or so) to 0 in less than 5 minutes. There is absolutely nothing that should use entropy that fast. It'd be useless if so, because it sure can't be refilled at anywhere near that rate.
I dunno, I've just given up. It's annoying, but I've switched Apache over to urandom, and just have to hope that nothing else is getting borked because of this problem…
-j
@Bill Clinton:
@wazdog:Is there a way to get the whole system to use /dev/urandom instead of /dev/random?
Long story short: noBill Clinton
There's no magic about /dev/random and /dev/urandom, they're just character devices:
$ ls -l /dev/*random
crw-rw-rw- 1 root root 1, 8 Feb 2 07:03 /dev/random
cr--r--r-- 1 root root 1, 9 Feb 19 06:56 /dev/urandom
So 'rm /dev/random; mknod -m 666 /dev/random c 1 9'
should do the trick. Since I've not tried this, I'll add the usual caveats: YMMV, AFAIK, IANAL,OIMMBCTTA.
One more serious caveat. Once you've done this, I strongly suggest that you not use this box to generate anything requiring long-term security, such as GPG keys, SSL certificates, etc.
Hmmm, and I don't know why the permissions are different, or why anything would want +w on /dev/random. Maybe I just did something screwy on my box.
I don't know if this is accurate or not, it's just a guess on my part.
Anyway, what I want is a way to tell the whole system to go to /dev/urandom when it needs entropy. Then if there is some in /dev/random, it'll get pulled in automatically, and if there isn't, then urandom will generate some. There really should be some way to do this, though I don't think there is now…
@wazdog:
AFAIK, urandom pulls entropy from /random if there is any and then makes up its own when it runs out. Replacing /dev/random completely would seem to force urandom to always make up the random digits, which may or may not be a good idea.
Nope, that's not how it works. /dev/urandom always provides values from a psuedo-random number generator. It does, however, get the seed for the PRNG from the true entropy pool, and, IIRC, occasionally re-seeds, depending on how heavily it's used. What I don't remember is whether or not kernal reads from the entropy pool directory or via the character device, and if it does from the character devices, whether it actually opens /dev/random or just c1,8 directly. If it does open /dev/random, then my former suggestion wouldn't work.
Also /dev/random doesn't get it's entropy via writes to /dev/random. Even if it did, you sure wouldn't want anyone except root to write to it. The entropy pool is "restocked" via internal kernel events, such as the timing of the arrival of network packets, disk accesses, and so forth. Anyway, I think the 666 permission on /dev/random is a Debian artifact; on the RH machines I looked at, it's 644.
As for whether or not the PRNG is "good enough", it depends on your use. But that's why I suggested that using it to generate keys that require long-term security was not a good idea.
Are the accounting modules availabie in the Linode kernels? If so, you can enable accouting and (I think) track which processes are opening /dev/random and sucking down your entropy pool.
@SteveG:
Nope, that's not how it works. /dev/urandom always provides values from a psuedo-random number generator. It does, however, get the seed for the PRNG from the true entropy pool, and, IIRC, occasionally re-seeds, depending on how heavily it's used. What I don't remember is whether or not kernal reads from the entropy pool directory or via the character device, and if it does from the character devices, whether it actually opens /dev/random or just c1,8 directly.
Cool, thanks for chiming in. Yeah, as I said, my understanding is sub-par, and apparently wrong!
@SteveG:
As for whether or not the PRNG is "good enough", it depends on your use. But that's why I suggested that using it to generate keys that require long-term security was not a good idea.
Well, the way its working on my system, (and a few others that have posted here), there is no option to use /dev/random. Believe me, I'd prefer it, but nothing I do has allowed me to keep entropy stocked for longer than 5 minutes, and I can't find anything on the Net to help. oh well… so much for security.
@SteveG:
Are the accounting modules availabie in the Linode kernels? If so, you can enable accouting and (I think) track which processes are opening /dev/random and sucking down your entropy pool.
I don't know. I am rather new to Linux. I'm a fast learner (I think
thanks again for your helpful post,
-j
#!/usr/bin/perl -w
open(ENTROPY, ";
close ENTROPY;
chomp $entropy;
printf("%d\n%d\n", $entropy, $entropy);
The relevant bits of my MRTG config file are as follows:
## Monitor system entropy
Target[meat.entropy]: `/usr/local/mrtg/entropy.pl`;
Title[meat.entropy]: available entropy
MaxBytes[meat.entropy]: 4096
PageTop[meat.entropy]:
# available entropy
ShortLegend[meat.entropy]: b
Legend1[meat.entropy]: Available Entropy (bits)
LegendI[meat.entropy]: Entropy
Options[meat.entropy]: growright,gauge,noo,noscale
Maybe someone will find this helpful. I've been running it for a little while and it shows my entropy pool staying full, but I'm not running Gentoo.
I've solved the problem by getting the content of /dev/random of my workstation (plenty of random data there) to my server. I have a script that I'd be happy to share for loading the data into the entropy pool. With some crontab work transfer is painless and fully automatic.
What I can't figure out is why in Gentoo, doing "cat /proc/sys/kernel/random/entropyavail" reduces entropy with each successive cat. If I don't touch entropyavail, it will go up, but as soon as I start cat'ing it, it goes down…
Rebooting into Debian (same kernel version), it doesn't have this problem. entropy_avail continues to rise, no matter how many times I cat the file.
So where the heck does this point towards?
-Chris
@caker:
indeed, UML is calling the correct random functions to populate entropy.
Well, that's a good sign! sort of…
@caker:
What I can't figure out is why in Gentoo, doing "cat /proc/sys/kernel/random/entropyavail" reduces entropy with each successive cat. If I don't touch entropyavail, it will go up, but as soon as I start cat'ing it, it goes down…
My thoughts exactly. I have always assumed that there was something else sucking down the entropy, but upon further consideration, that makes no sense. lsof shows nothing accessing it.
Could cat be guilty? Could it be disfunctional in Gentoo? As stated before, this isn't solely a Linode problem, others in the Gentoo forums echo the problems. (It also appears in other distros, but much more rarely. It could be a different cause for people complaining of similar issues with other distros…)
@caker:
Rebooting into Debian (same kernel version), it doesn't have this problem. entropy_avail continues to rise, no matter how many times I cat the file.
Is anyone else out there (on Linode) experiencing this problem and NOT on Gentoo?…
@caker:
So where the heck does this point towards?
Heck if I know…
@wazdog:
Could cat be guilty? Could it be disfunctional in Gentoo? As stated before, this isn't solely a Linode problem, others in the Gentoo forums echo the problems. (It also appears in other distros, but much more rarely. It could be a different cause for people complaining of similar issues with other distros…)
This is where I'm boggled… Nothing in userspace should cause this, but about only thing I can think of is a problem on gentoo with glibc, and the open/read library calls. The odd thing is that proc files are 'special', handled by the kernel -- it does the same thing regardless of distro..
I suppose comparing "strace cat entropy_avail" on different distros might be of some use…
-Chris
* 1) Most of the services on my system are using /dev/urandom instead of /dev/random.
****2)**** Readin from /dev/urandom depletes /dev/random by however many bytes you read–if there is any.
****3)**** Entropy is replenished by disk activity only. Network traffic has no effect.
****4)**** For some unknown reason, every e-mail that comes in depletes the entropy pool by 2048 bytes. WTF is up with that?</u></list> <u>I've had cacti monitoring my entropy pool overnight. This is what it looks like:
~~![](<URL url=)
(Note: This pic is a link to the generated version, not a static one. What you're looking at is the latest graph.)
I cannot understand why one e-mail would deplete the entropy pool by 2k, and it's going to take a while to track down what's doing it. Between sendmail, milters and the delivery agent there are a lot of possible contenders. Anyway, as you can see, when the system sits around and no mail is coming in, the entropy pool does grow.
Chris, is there any way to get entropy from network activity? I've seen a bunch of posts on the subject (here and elsewhere on the Internet) but have not yet found any really useful information. Mostly vague references to some kernel patches somewhere. Maybe it's in 2.6–does anyone know if it is?
Anyway, that's my $0.02 on the subject. If I find the culprit to the 2k of entropy per e-mail I'll post it here.
-- James~~
@irgeek:
Chris, is there any way to get entropy from network activity? I've seen a bunch of posts on the subject (here and elsewhere on the Internet) but have not yet found any really useful information. Mostly vague references to some kernel patches somewhere. Maybe it's in 2.6–does anyone know if it is?
I've looked at the UML code, and indeed interrupts caused by network activity is hooked into the entropy generating code. It might just be that it's not enough of a time difference to generate reliable randomness, but I don't fully understand the code.
Jeff Dike (uml dev) seems to think hooking the host's entropy pool into UML is the solution, but, I'm worried about a single UML depleting the pool. Jeff's response is "UML doesn't do enough random things to generate enough entropy". I'd like to see a solution where the entropy-generating code is a little less picky (but not easy enough to not be random)…
-Chris
@caker:
Jeff Dike (uml dev) seems to think hooking the host's entropy pool into UML is the solution, but, I'm worried about a single UML depleting the pool.
I can see your concern. Adding a hardware entropy device to the system may be a reliable option. If the servers have audio cards, that could work. If not, there are several available on the market. Heck, with a little help from my profs at school (I'm currently studying Electrincal Engineering) I could build one for you.
@caker:
Jeff's response is "UML doesn't do enough random things to generate enough entropy".
I think he's correct. From what I can tell, the default sources of entropy (disk, mouse and keyboard activity) aren't nearly enough. Especially since disk activity is more expensive on a UML machine than a real host. I don't want to bog the whole host down by trying to read/write files with a daemon just to generate entropy.
As for network activity generating entropy, I don't think it's turned on in the kernel I'm using. I'll try booting into the latest kernel and see if it works there. That alone will probably solve this since I don't have much disk activity, but there are a couple of small files hosted on my machine which are included in friend'd signatures on very busy forums. These would generate a lot of network interrupts without a lot of traffic.
– James