/dev/random not being seeded

I am running Gentoo on my Linode with Apache 2.0.48 and authdigestmodule working OK. My /dev/random and /dev/urandom are both populated and entropy_avail = 343(without any specific action on my part) so this does not seem to be problem that is specific to Linodes.

Okay, so hmmmmm.

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:

http://www.securityfocus.com/archive/1/ … 03-07-27/0">http://www.securityfocus.com/archive/1/330526/2003-07-21/2003-07-27/0

http://www.mail-archive.com/uug-list@uu … 07982.html">http://www.mail-archive.com/uug-list@uug.byu.edu/msg07982.html

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?

Okay, so I know where the dilemma may be. Something is sucking my /dev/random dry real quick.

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

2.4.24-linode19-1um here. Perhaps we should compare stuff running at startup?

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

hey thanks for chiming in mike…

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…

i've only recently installed this gentoo system.

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

wazdog, how frequently do you use screen? You mention having it instaled… I use it two but wouldn't expect it to cause this problem, who knows.

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

i only use screen when emerging stuff, so not too often really!

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.

yes, I'm having 0 entropy too.

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?

yeah, Im always connected via ssh.

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 want to hit the slopes

mike, as i've described above, my entropy never sticks around. I have been able to get it to increase with "du /usr" or "emerge sync", but in then decreases over the next 1-5 minutes to 0.

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!

hey at lest you wont be in a small office all day :)

@blahrus:

hey at lest you wont be in a small office all day :)

oh, i was only half-a$ed complaining… :wink:

:lol:

Just to chime in as well.

I have authdigestmodule running without a problem

but my entropy is 0 as well.

Adam

Yeah, I think that as long as you have entropy when you start apache2 (and auth_digest), then you're fine. (I don't know if it's only the first start, or every restart, that needs to pull some entropy)….

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!…

My entropy has been hovering between 3500 and 3900 all morning. It was in the low hundreds last night and seems to have been replenished while the Linode was idle. It was dipping below 100 early yesterday and nothing has changed to explain the difference.

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.

I guess the issue is that something is eating mine (and mike's) entropy. So even if it does get bumped up during idle time, it is immediately eaten again, therefore always showing 0 entropy_avail.

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?

…

Okay, to give out the solutions I've found to starting Apache2 without commenting out auth_digest.

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.

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.

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…

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…

@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! :?

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)…

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. :x

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…

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

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

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

@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 if you need random integers.

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: no

Bill 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 guess the system writes to the entropy pool through the /dev/random device.

Yeah, I believe it does. My thoughts are that if you were to replace /dev/random with /urandom, then where would urandom gets its entropy. 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.

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! :) oh well, but now I know. thanks.

@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. :D (actually, I feel quite safe enough using urandom all the time, from what I've read it is less safe but only theoretically so, and if it were cracked, you would have more issues than just your keys being susceptable)…

@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 :) ) but haven't even started to think about the kernel. :wink: I wouldn't know what to do here without some help, so any suggestions would be more than welcome!

thanks again for your helpful post,

-j

I hacked together a quick MRTG helper script to monitor system entropy.

#!/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.

Hi,

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.

I spent a few hours last night debugging the entropy problem within the kernel (perhaps not specific to UML). I added printk's all over the place, and indeed, UML is calling the correct random functions to populate entropy.

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

I've been poking around at the /dev/random stuff for a few hours and here's the information I came up with:

* 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:

-- 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

Try increasing the pool-size:

echo 8192 >  /proc/sys/kernel/random/poolsize

@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