-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark,
On 7/30/15 12:59 PM, Mark Eggers wrote: > Comments inline: > > On 7/30/2015 9:16 AM, Christopher Schultz wrote: >> Robert, > >> On 7/30/15 2:28 AM, Robert Jacobs wrote: >>> We have double checked the environment settings we set and the >>> only thing we currently set is JAVA_HOME, which is set to >>> /usr/java/latest . This points to 1.8.0_20-b26. > >>> We also created a new virtual machine via virtualbox, also >>> running RHEL 7.1 and tomcat 8.0.18. We experience the exact >>> same issues as with our vmware virtual machine. Could it be >>> that we are experiencing this because we are using virtual >>> machines? It should not matter, right? Is it related to RHEL >>> 7.1? > >>> We noticed that Tomcat startup times vary in terms of 900ms up >>> to 9000ms on this new virtual machine. > > The 90000ms (90 seconds) is one clue I think. > > >> If you are using SSL, the problem is likely lack of entropy. >> Virtual machines are often hamstrung by virtual devices not >> providing enough noise to gather entropy. Make sure your VM has >> access to the underlying host's entropy source. > >> This can also happen when creating a SecureRandom instance for >> generating session ids. Previously-posted log messages seem to >> show that this is what is happening to you. If you do a lot of >> restarts on a VM in a short period of tie, you can drain your >> entropy source. > > > This is the other clue I think. > >>> We also noticed that Tomcat returns 143 when deploying first >>> webapp (which is the Tomcat docs folder). > >> When does the "143" get returned? Does the JVM exit and produce >> that as the return code? Or is jsvc producing that return code? >> Or is systemctl returning that code? It would be great to know >> what tool is returning this "143". That's not a standard OS exit >> code, at least not on any system I have access to. > > Chris, I did a little looking around, and bash will report a signal > + 128. So 143 is a SIGTERM. Some other process is killing off > Tomcat. Good thought. I wonder if systemctl is running daemon.sh, not getting a response in a certain amount of time, and them killing itself or something equally foolish like that. I must admit I have no experience using daemon.sh or jsvc, so I can't speak from experience. >> When you say "when deploying the first webapp" are you saying >> that the JVM exits when the first web application is trying to >> deploy, or something else? Is there a second web application? >> Does that ever start loading? > > Here's my current working theory. > > As Chris has stated, lots of VM restarts mean that you're probably > short on entropy. If you're short on entropy, you'll need to wait > longer for Tomcat to start up. > > By default, systemd has a 90 second timeout for starting a unit. If > a unit doesn't signal a start-up within that time, systemd will > shut down that service. With a SIGTERM? > You can configure a per-unit start-up time. Do a man 5 > systemd.service to see how. > > It would be better if you could access the underlying entropy > source as Chris has suggested. 90 seconds is a long time to wait. Sounds like a good working theory. - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVuoL9AAoJEBzwKT+lPKRYBHUQAKkgO+aUAPqzkbQnowhAjTNf SJvRZKKa1MKBnyBwFL69dWncCgdzW0Ly3h8m24JgFlKIEtABw5fnbgrYl9cmZPCb NrZTjPdX/wnX/w3OPB1rVygiP/MK4RRLIMsJB1A6mCocxPEjsKhfSMMt84uA14dt MtoUM75+WBC5SexOhTY56XUm1+5Lpkf8j9Labrsw+GXQK/b6x/SMUTDdTE7q+L5q JmTtQha6FQTh0B5vnZr8aawNWmRbqGJxYOYxM7BL0PSzHi1CS+sa1SvSF+J0/5BG M7QN8WIFT4P+FjzXvveYJGeXNHWLu9A5pRmUWothyJQGFNVqVZyF98V6KrkjOO81 4wqezad2g/K6QfQdw99YT4ihLba8ZfYNZSqEus34/txb8+DJIrebHVl5yeHl4wv/ 5OHFETWfTKwQWgSFOYADb0v2f4gARNsVtCCa32TB1NaLdxZBrL0o9xzjul2D0ETr c3J+Po1nnSi1J0HKqByMndGzCieB35wCDbPAdmTpnfzXa2MgMuDCb08TsHj7HZ8N 5ae5pR6JlTosttzLAgcPYTeM71MaU6nmg4SIFjeqFY0C9/PYHu7iiHLxqGNtBk4q n8fD4HL4tQ5y47lXCmA/ehAJq7YQXnYJ3J3oazqO2p6a1Cm2ENpoPfTZZp4m/1v7 2s0Yg9yM/z10N26wI/W3 =rM46 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
