Description of problem: During engine-setup, ovirt-aaa-jdbc-tool is called to set admin password. Today I ran several times engine-setup and then engine-cleanup (while debugging an unrelated issue). In the first run, it took 1 second. In consecutive ones, it took much longer - 3:20 minutes on second, 3:57 on third, 6:15 on fourth, 1:45 on fifth. Then after engine-cleanup, stopped postgresql, renamed its data dir, and ran setup again - the tool took 1:31 minutes. Version-Release number of selected component (if applicable): Current master snapshot How reproducible: Not sure Steps to Reproduce: 1. engine-setup 2. engine-cleanup 3. engine-setup Actual results: Second run takes considerably longer Expected results: Should take more-or-less the same time Additional info: Tried running everything under strace, but my /tmp reached 100% in the middle so it failed. Can try again with a larger one, or filter specific syscalls, or whatever.
Created attachment 1138640 [details] setup-cleanup-logs.tar.gz
Ran again with strace and found the reason: it's waiting for /dev/random. Workaround: Added to the script: -Djava.security.egd=file:/dev/./urandom See also: http://stackoverflow.com/questions/137212/how-to-solve-performance-problem-with-java-securerandom
Verified another workaround following Sandro's suggestion - use haveged. Since this one is reasonable IMO, might close wontfix. Still not sure why we need there much random data, leaving for assignee to decide.
We are encrypting password during password-reset command, so we definitely want to use secure random number generator and replacing /dev/random with /dev/urandom is not an option. Also I have never noticed this slowness on real machine. The issue can be seen only when running the tool inside the VM and in this case you could increase entropy of the VM by using virtio-rng or haveged. So I'm closing this as WONTFIX.
AFAIU we are not "encrypting" them but hashing them, and the only thing we need a random number for is the salt. Not sure why using urandom is not an option. Might be missing something, NVM. Using the host rng or some alternative such as haveged is also good enough, considering that many people already have to do that for other reasons.
Just for the record, /dev/urandom is totally acceptable and you do not need to use /dev/random unless you are a security researcher. Additional sources of information why we should prefer /dev/urandom: https://www.2uo.de/myths-about-urandom/ https://pthree.org/2014/07/21/the-linux-random-number-generator/