> -----Original Message----- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Thursday, August 30, 2012 2:55 PM > To: Tomcat Users List > Subject: Re: Windows Path Not Found for urandom > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jeff, > > On 8/30/12 10:13 AM, Jeffrey Janner wrote: > >> -----Original Message----- From: Christopher Schultz > >> [mailto:ch...@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. > [Jeff Janner] Sorry, standard windows installer version. Replaced the ROOT.xml file in catalina_home\Catalina\localhost with my own pointing to an exploded directory outside the install directory.
> >>> 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. > [Jeff Janner] That's highly likely, as it's the error page we use for all errors. I'm not one of the developers, but I would think you'd leave that out for an in-app error page that didn't invalidate the session. So that makes sense. Sounds like the Tomcat session generation routine is always looking for /dev/urandom whenever it is called. > >>> 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? > [Jeff Janner] The tool basically reports everything that's going on at the Windows level, so I can see why it picks up on the PNF on the exists() not finding it. There's never an error logged anywhere. Like I said, the tool is for profilers and paranoids. > > 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). > It just seems that it does it everytime the session is created that is causing the issue with my customer. If Tomcat could remember that the file doesn't exists once per boot, but then again, on systems where the file does exist, you want to keep checking in case it disappears or is temporarily removed - though who in their right mind would do that!
