Bug 1384006

Description of problem:
SWnightly installation fails with "Tomcat failed to start properly or the installer ran out of tries.  Please check /var/log/tomcat*/catalina.out for errors." It takes 131 seconds to tomcat to start. Problem is in org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom taking too long.


Version-Release number of selected component (if applicable):
tomcat-8.0.36 at F24


How reproducible:
sometimes


Steps to Reproduce:
1. Install Spacewalk


Actual results:
Sometimes spacewalk-setup fails with:
# spacewalk-setup --non-interactive --answer-file=answer-file --clear-db --external-postgresql
[...]
* Restarting services.
Tomcat failed to start properly or the installer ran out of tries.  Please check /var/log/tomcat*/catalina.out for errors.
# tail -n 5 /var/log/rhn/rhn?installation.log'
Shutting down spacewalk services...
Done.
Starting spacewalk services...
Job for spacewalk.target canceled.
Done.


Expected results:
Either it should work or installer should have an option to use /dev/urandom instead, or documentation .../HowToInstall should mention what is the workaround and/or how to check if your system has enough entropy or default timeout for spacewalk.target should be increased (90 seconds by default if I understand it [1] correctly).

[1] Wait for Tomcat is performed by "/usr/lib/systemd/system/spacewalk-wait-for-tomcat.service" and that has "type=oneshot", so according to `man systemd.service`, "TimeoutSec=" is not relevant here. Where I believe it is relevant is for "/usr/lib/systemd/system/spacewalk.target" where default "DefaultTimeoutStartSec=90s" from `man systemd-system.conf` probably causes the cancel.


Additional info:
I have no idea on what would be right solution here. I'm just trying to make sure we are not bitten by this from time to time in our automation.

jdobes pointed me to explanation on https://wiki.apache.org/tomcat/HowTo/FasterStartUp - there is something about it in Entropy Source section