I have traced the root cause to be the low entropy on new VM instances, especially if they are headless (a typical cloud server today). To test if one is affected by the problem: head -1 /dev/urandom
If the above command doesn't return immediately with some garbage output, but rather hangs, your server is affected by the problem. Java's SecureRandom initializes by reading from /dev/urandom. Some solution online suggest modifying JCE settings to use /dev/random, but this is less desirable:
It's not guaranteed to always work There can be multiple JVMs, and admin may not always know which install is used by a specific process, and JAVA_HOME might not even be set, leaving him/her guessing It would require manual intervention, which hinders e.g. blueprints functionality (fully automated Ambari install) One solution which worked great for me and didn't require any JDK or code changes was to install the Haveged entropy daemon, which was designed for this problem specifically: http://www.issihosts.com/haveged/ Here's a process for CentOS 7. Similar steps are available for Ubuntu, etc. Haveged packages are in the EPEL repo. Need to install version-specific one for CentOS rpm -Uvh http://download.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-8.noarch.rpm
yum install -y haveged
chkconfig haveged on
service haveged start
After this my secure NiFI cluster reliably restarts within expected time windows.
... View more
