I am building a project using Hudson. I have few jar files which i want to sign with the timestamp using Ant SignJar task. It works like a charm when there is no timestamp - it takes about 2-3 seconds for one file. The problem appears when i add the 'tsaurl' attribute to SignJar task. Then timestamp takes few MINUTES for one file. I tried to use different timestamp servers and it did not help. Does anybody know why is it taking so much time? And first of all, is there any way to fix this issue?
1 Answers
The main problem I had with jarsign taking too long (on Linux, at least) was the kernel entropy pool drying up. At this point, the process blocks until more entropy arrives. This leads to the symptoms you are seeing of the jarsigner process sitting there not eating CPU time but not doing much either.
At some point (from 1.5 to 1.6 AFAIK), Java went from using /dev/urandom
to /dev/random
. Real entropy is actually a scarce resource on modern computers - lots of RAM decreases disk activity, smart programs that cache things decrease network activity. I'm told that on a virtual machine (like many build servers live on) that entropy collection rates can be even lower.
You can either
- Reconfigure Java back to using
/dev/urandom
(if you're not paranoid) - Deploy a means of injecting additional entropy into
/dev/random
I went for option B : I installed the randomsound
package for my chosen distro (Ubuntu). This samples your mike for whitenoise and uses it to inject entropy into /dev/random
when it runs dry. The main downside to this is that it blocks the mike for other uses. There are other ways of getting extra entropy, like copying a disk to /dev/null
, or doing a package update (lots of disk and network traffic). You may want to kit one or more of your servers out with a hardware RNG and install something that can serve entropy-as-a-service to the others. Or even a USB soundcard and randomsound
would work (lots of whitenoise in a server room...)
For option A, you can set property
-Djava.security.egd=file:/dev/./urandom
(note the extra dot - this is to workaround a "smart" bit of code that assumes you want /dev/random
even if you don't say so : see : https://bugs.openjdk.java.net/browse/JDK-6202721 )

- 2,244
- 18
- 20