Date: Fri, 29 Mar 2024 07:46:52 +0000 (UTC) Message-ID: <980904468.12569.1711698412781@change.sos-berlin.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_12568_2073229037.1711698412781" ------=_Part_12568_2073229037.1711698412781 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
If you face the error
Excepti= on in thread "main" java.lang.Exception: connect to database failed: Io exc= eption: Connection reset
or
java.la= ng.RuntimeException: Timeout reached (30s) for process:=20
then you probably are hit by a problem with your entropy pool or network= settings. This problem can occur with any JDBC database connection and is = not limited to use of the Oracle=C2=AE D= BMS. This problem is not related to JobScheduler and here is explained= why this happens and what you can do about this.
The JDBC interface requires random numbers to encrypt the connection str=
ing. Normally the /dev/random
file is used for =
a high quality of randomness. But when the entropy pool is is falling below=
the number of 64 units then /dev/random
will block while=
reading random numbers.
The JDBC interface might be configured to read from the file =
/dev/random
to get random numbers. The difference with the /dev/urandom
does not=
block if no random numbers are available.
You can check available entropy pool units with the command:
cat /pro= c/sys/kernel/random/entropy_avail
The /dev/random
file will deliver the next random numb=
er when the pool has reached more than 64 entropy units and otherwise block=
s any application accessing the entropy pool. Such blocks can delay e.g. a =
JDBC connection to a database and may result in timeouts being exceeded.
Check the entropy pool size (normally 4096) with the command:
cat /pro= c/sys/kernel/random/poolsize
If the "entropy_avail" result is too small (JDBC needs 40 bytes of secur= e random numbers) then you have to increase the pool by producing some envi= ronmental noise. This could be a hurdle, when you operate a headless server= (no console) as the noise is produced by keyboard, mouse etc.
To verify the entropy pool being the root cause of this issue try this (= requires root permission):
rm /dev= /random ln -s /dev/urandom /dev/random
If this solves your problem then the JDBC interface was not able to get = random numbers from the OS in good time. Please note that the effect of the= two given commands is reverted on reboot.
You can check use of random numbers by running the following commands in= two separate console windows:
while t= rue do cat /proc/sys/kernel/random/entropy_avail sleep 1 done
# initi= al test dd if=3D/dev/random of=3D/dev/null bs=3D1024 count=3D1 iflag=3Dfullblock=20 # full test (should rngtest be available) rngtest -c 100 </dev/random
There are two alternative solutions to modify Java security settings or = to modify JobScheduler settings.
Java holds the security configuration with the ./jre/lib/security/=
java.security
file. You can modify this file to point to =
/dev/urandom
instead of /dev/random
like this:
# origi= nal configuration # securerandom.source=3Dfile:/dev/random # updated configuration securerandom.source=3Dfile:/dev/urandom
Should the entropy issue have occurred during installation then create o= r update the JAVA_OPTIONS environment variable like this:
export = JAVA_OPTIONS=3D"-Djava.security.egd=3Dfile:///dev/urandom"
set JAV= A_OPTIONS=3D"-Djava.security.egd=3Dfile:///dev/urandom"
For permanent operation of JobScheduler add the following setting to you=
r JobScheduler's ./config/sos.ini
file:
[java] options =3D -Djava.security.egd=3Dfile:///dev/urandom
For execution of jobs with a JobScheduler Master add to your JobSch=
eduler's ./config/sos.ini
file:
[java] job-options =3D -Djava.security.egd=3Dfile:///dev/urandom <= /pre>
When running jobs with Agents then you can use the following environment=
variables in your Agent's instance start script, e.g. in ./bin/jobsc=
heduler_agent_4445.sh | .cmd
file, like this:
JAVA_OP= TIONS=3D"-Djava.security.egd=3Dfile:///dev/urandom" SCHEDULER_JOB_JAVA_OPTIONS=3D"-Djava.security.egd=3Dfile:///dev/urandom"
set JAV= A_OPTIONS=3D"-Djava.security.egd=3Dfile:///dev/urandom" set SCHEDULER_JOB_JAVA_OPTIONS=3D"-Djava.security.egd=3Dfile:///dev/urandom= "
Alternatively to the above add the similar setting for jobs in the "Java= Options" section of the job definition like this:
<job = java_options=3D"-Djava.security.egd=3Dfile:///dev/urandom"> <script language=3D"java" java_class_path=3D"" java_class=3D"..."/&= gt; <run_time /> </job>
A wrong network configuration can cause delays when executing Java and w= hen accessing a database, e.g. if host name resolution takes too long. = ;
For Unix check the /etc/resolve.conf
configuration file if =
entries for name servers and host name resolution are correct.
Another possible reason for delays could be a huge number of files in /tmp=
directory when SecureRandom.nextBytes(byte[])
is =
invoked.