-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris,
On 7/30/2015 1:03 PM, Christopher Schultz wrote: > 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? It appears to be so - according to the documentation on freedesktop.org. If the unit doesn't exit after a SIGTERM, then systemd issues a SIGKILL. This appears to be configurable - see man 5 systemd.kill for particulars . Like the start-up timeout, this can be configured per unit as well. > >> 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 /mde/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVupUnAAoJEEFGbsYNeTwtXJMIAIGgRZs/gUoXFi2HmyVa2Cwm dH1zsdi1Y9EfAqg9JYAdKN2s9EZ28xUMJRPRntun8JWWrEQCN60vVIxTgxog28+S lXkMVrEPhGPLpgRKka513mO9eyI4SVcGWgmuqIK6Q0/2uobiad+cg24KmjAfytU1 xbQzYb5V8rnw1zqIJko4AQYGA2cuF08auwYTdtQdBVBR/afmpOw4DVwOyH3ltqCZ k667JD7N5hG/Kus+vTwr/qoXqunKVoAKXQnTRazYVhKkN0h3WgaRsYfq8qiW0VB6 Jwv6I8p0Suhg5/PujxAvcpXb+wuUTbM4ajnRjQ7shawSV9b/uuq8+b3S1geOX/8= =5I2B -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
