Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SessionIdGenerator.java

[Bojan Smojver <bo...@binarix.com>]

estutes@eas.san-jose.ca.us wrote:
> Given that tomcat should run for days or weeks at a time, I don't think
> you want to keep /dev/random open. There maybe other processes that also
> need random data during that time.

Are you really sure that other processes are unable to use /dev/random
while Tomcat is using it? It sure doesn't worry my Linux machine. Try
multiple cats on /dev/random. Works just fine. Or maybe I missed
something...

Bojan

Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SessionIdGenerator.java

[Bojan Smojver <bo...@binarix.com>]

estutes@eas.san-jose.ca.us wrote:
> As pointed out by someone else, at some point on a system that is not
> busy processes will hang on /dev/random waiting for their next chance to
> catch some randomness generated by things like mouse moves.  And if you
> are on a server, the mouse may never move. There will be other trips
> into the kernel, but I think a better strategy would be to get a random
> seed and close your particular connection.  What do you think?

I think I've covered that one in one of my other e-mails, but here is
the summary:

- we should document this properly so that all users can make an
informed decision (*very important*, otherwise there's going to be tons
of e-mail about sudden hangs of Tomcat if this was a bad idea) - if I'm
pointed towards the right document I'll submit a patch

- on a real life server the requests to Apache/Tomcat are coming through
network cards which generates 'kernel noise' and therefore /dev/random
shouldn't really block; you don't have to move the mouse or touch the
keyboard to get random data, any kernel driver counts (I just verified
that by pinging my Linux box from another box); usually the disk is
touched as well when you hit the web pages

- the next problem might be a heavily loaded box (ie. will there be
enough random data for all sessions) - usually on a heavily loaded
machine there will be plenty of random data, so I don't think heavily
loaded boxes should be an issue

- I don't think that opening and closing the /dev/random would make much
difference except for the fact that opening/closing might generate some
random data in the kernel; I'll give here one bad scenario with
/dev/random being constantly opened/closed: we open the /dev/random
(let's say this generates some random data) and then attempt to read
that data, but there wasn't generated and the read blocks - back to
square one :-(

Having said all that, it is my belief everyone should test this in their
particular situation to verify if this approach is good for them or not.
Although I can qualify as a Linux user and hardly as a Linux admin, I'm
nowhere close to being a kernel expert. So all of the above could be
pure BS (did you notice these are my initials - funny, ha ;-)

Bojan

Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SessionIdGenerator.java

[es...@eas.san-jose.ca.us]

On 11 Apr, Bojan Smojver wrote:
> estutes@eas.san-jose.ca.us wrote:
>> Given that tomcat should run for days or weeks at a time, I don't
>> think you want to keep /dev/random open. There maybe other processes
>> that also need random data during that time.
> 
> Are you really sure that other processes are unable to use /dev/random
> while Tomcat is using it? It sure doesn't worry my Linux machine. Try
> multiple cats on /dev/random. Works just fine. Or maybe I missed
> something...
> 
> Bojan
As pointed out by someone else, at some point on a system that is not
busy processes will hang on /dev/random waiting for their next chance to
catch some randomness generated by things like mouse moves.  And if you
are on a server, the mouse may never move. There will be other trips
into the kernel, but I think a better strategy would be to get a random
seed and close your particular connection.  What do you think?

=eas=