September 25, 2005
One of my servers has apache2 and mod_perl on it to play with some crazy stuff like dyamically looking up virtual hosts in postgres, but every time I restart apache2 for whatever reason, it blocks reading /dev/random and never starts up. A little research shows this is mod_perl trying to initialise its UUID generator with some quality system entropy (why? is it strictly necessary? are the UUIDs that important?). The problem is, it never succeeds because this machine never has any entropy:
$ cat /proc/sys/kernel/random/poolsize
$ cat /proc/sys/kernel/random/entropy_avail
It’s a headless box with no serial, mouse, keyboard or USB devices, so the only IO it sees is disk and network. How do I find out what’s eating all the entropy, or does it in fact just never have any due to nothing feeding it in the kernel? What can I do to identify and address the actual source of the problem (ie not just making /dev/random a link to /dev/urandom or patching mod_perl to just read /dev/urandom or use /proc/sys/kernel/random/uuid to make its UUIDs)?
11 responses to “Missing entropy”
Leave a Reply
- March 2023
- November 2022
- May 2022
- February 2022
- June 2021
- January 2021
- August 2019
- October 2018
- July 2017
- May 2010
- October 2009
- August 2009
- July 2009
- March 2009
- January 2009
- July 2008
- June 2008
- April 2008
- May 2007
- January 2007
- December 2006
- June 2006
- April 2006
- March 2006
- November 2005
- October 2005
- September 2005
- August 2005
- July 2005
- May 2005
- April 2005
- March 2005
There are kernel patches for larger entropy pools (more sources). But it probably goes wrong because something else.
My headless box without serial, mice keyboard, usb etc. has a much more available entropy.
I’m not really into this stuff but I would try another kernel and see if the problem still occurs. Goodluck. 🙂
I had the same problem for an embedded system of mine, and just made the network interrupt a source of randomness as well. Contact me via email if your interested in how I did it.
Poking around on a few boxes here (all running 2.6.13) I seem to have a poolsize of 4096. My headless box (1 disk, 3 NICs, most of the activity routing rarely-saturated 2Mbps DSL) reports 3119 for entropy_avail. I reckon something may be eating yours.
It seems mod_perl has (pointlessly, compile-time) random-device selector. If you are in a position to build it yourself that might be the easiest way out.
A userspace solution revolves around reading ambient noise with a cheap microphone to produce entropy on a headless box.
netdev-random is a patch originally created by RML against 2.4. It fills the entropy pool from random bits from your NIC. I used to use PaX and SSP pretty heavily, which sucked entropy, so I was interested in these patches against 2.6. You’ll notice I’ve not touched this stuff in months, included for completeness.
If you are using a kernel of the 2.4 series, the following link hopefully might help you.
I finally upgraded from 2.4 to 2.6 last month on my rackmount server, and instantly found myself out of entropy and blocking on /dev/random, which I’d never had happen under 2.4.
Turns out, according to #kernelnewbies, entropy gathering from the network has been disabled under 2.6 since it could be influenced externally.
There are a couple of ways to fix this. You’ll want to utilize userspace daemons which gather entropy from available resources (keyboard, net, disk, etc)..
There’s egd, rngd, prngd, etc etc. If you are utilizing entropy at a large rate it’d probably be best to use one of these. Otherwise, you can always create some disk activity and the kernel should gather entropy that way. Also its possible that your mobo might have a hardware random number generator. If so you can modprobe and hw_random or check to see if your kernel has support and use the hwrandom node.
is this Apache dynamic vhost lookup Perl module somewhere available for download? I quite interessted in it. 🙂
cwarner, none of the daemons you have mentioned seems to be in Debian, by virtue of apt-cache search. So it looks like the kernel developers – again – leave people out in the rain, only that it this time only catches the 80 % of people with hardware that doesn’t have a hardware rng.
the Debian package rng-tools contains rngd. I just installed it, and can’t yet say how well it works (or even if at all).
it turns out rng-tools won’t be useful; it’s intended for use with a hardware rng. I’ll probably recompile my network driver with SA_SAMPLE_RANDOM enabled in the request_irq call.