Product Knowledge Base

Space shortcuts

Page tree

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

If you have the error

 Exception in thread "main" java.lang.Exception: connect to database failed: Io exception: Connection reset

or

 java.lang.RuntimeException: Timeout reached (30s) for process:

You probably have a problem with your entropy pool.

To check it try this

 rm /dev/random
 ln -s /dev/urandom /dev/random

If this solves your problem, jdbc was not able to get random numbers from the os. Please note that the effect of the two given commands is gone on reboot.
This is really a database issue, not a JobScheduler one. But here is explained what happens to bring you to a situation where you can solve the problem.

The fact is, that jdbc reads from dev/random to get random numbers. The difference with /dev/urandom is, that /dev/urandom does not block if no random numbers are available. That is the reason, the two lines above solves your problem (but only until next reboot).

JDBC needs the random numbers to encrypt the connect string.

Normally /dev/random is used for a high quality of randomness. But when the entropy pool is empty reading from /dev/random will block.

You can check your pool with

 cat /proc/sys/kernel/random/entropy_avail

/dev/random will deliver the next random number when the pool has reached more than 64 entropy units.

and the poolsize (normally 4096) with

 cat /proc/sys/kernel/random/poolsize

If the "entropy_avail" is to small (JDBC needs 40 bytes of secure random numbers) you have to increase the pool by producing some environmental noise. This could be a problem, when you have a headless network server (no console) as the noise is produced by keyboard mouse etc.

What you can do is

  • make sure that your entropy pool is big enough
  • add in sos.ini (to have random numbers generated with less security)
 -Djava.security.egd=file:///dev/urandom

 [java]
 options                = -Djava.security.egd=file:///dev/urandom

Also add this to all jobs in the java option section that make use of sos connection classes.

 <job  name="jobtest java_options="-Djava.security.egd=file:///dev/urandom">
    <script  language="java" java_class_path="" java_class="test"/>

    <run_time />
 </job> 

Btw, another possible reason for the timeout could be a huge number of files in /tmp as jdbc tries to list all the files in the /tmp when SecureRandom.nextBytes(byte[]) is invoked.

 

  • No labels