tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Windows Path Not Found for urandom
Date Thu, 30 Aug 2012 19:55:11 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeff,

On 8/30/12 10:13 AM, Jeffrey Janner wrote:
>> -----Original Message----- From: Christopher Schultz
>> [mailto:chris@christopherschultz.net] Sent: Wednesday, August 29,
>> 2012 4:05 PM To: Tomcat Users List Subject: Re: Windows Path Not
>> Found for urandom It should happen once, but I suppose anything
>> is possible -- especially if you have an ... odd deployment
>> configuration.
>> 
> [Jeff Janner] I assumed twice/context, because that is how many
> PNFs I see with the file missing (as it should be under windows).
> This is just at startup, before any client access attempts.

I was wondering if maybe you have a broken configuration that is
deploying each webapp twice.

>>> My real problem is somewhere else.  On login, we call 
>>> request.getSession, which I'm pretty sure is generating a new 
>>> sessionid (verified by turning off cookies), and thus
>>> generating the first PNF. On bad login credentials, we
>>> invalidate() the session, which I'm guessing is doing the
>>> second PNF.
>> 
>> Invalidating the session shouldn't require any entropy to be
>> read, so I wouldn't expect any failure.
>> 
> [Jeff Janner] I wouldn't think so either. What I should have said 
> was, we call session.invalidate() and then generate an error page. 
> Maybe it's something in the error page code that's generating the 
> second PNF.

If your error page is a JSP that does not have session="false"
specified, then you may be creating a new session.

>>> Overall, I'm thinking nothing to worry about, right?
>> 
>> If I were you, I'd delete the file and move on with my life: the
>> error message will go away and otherwise the system will operate
>> exactly as before.
>> 
>> - -chris
> 
> The PNFs won't go away, and that really is my ultimate goal. Of 
> course, you only see them if you're a paranoid individual running
> a process monitoring tool.

Right. Tomcat just does a File.exists() so the JVM must be performing
an operation that causes a PNF. I would have thought that
File.exists() would be using an OS-level function that does not
generate errors when the path does not exist, but there's nothing you
can really do about that, eh?

> The real thing is under Windows, Tomcat shouldn't be looking for a 
> /dev/urandom file, or anything equivalent since it doesn't exist.
> So it spends a few cycles looking for it anytime it thinks it needs
> it, when really it should just not even look for it, or look for it
> once and remember it doesn't have one. Personally, I can live with
> wasting a few cycles, but can everyone?

No, it just wastes those cycles the first time it tries to initialize
the entropy source. After that, it should be smooth sailing.

The reason this code isn't OS-specific is that it works properly under
OSs that support /dev/urandom and (usually) silently falls-back to
another strategy when that path doesn't exist (or won't work properly,
like when you have an empty file in there).

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlA/xR8ACgkQ9CaO5/Lv0PCgZgCgwL6wdwtt9zpispX/MJ+zVlR5
IpsAn2hld5xSDytuDk6a5XcxD+9UwsO9
=VTzk
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message