My Application Server (on Fedora Linux) would not restart after I changed the DB structure on the MySQL backend & imported an updated solution.
I have tried to start it manually but no success.
Typing "./servoy_server.sh & " seizes the terminal and does not complete.
Running a log file simply shows…
Loading servoy.properties from /usr/local/servoy/servoy.properties
Loading - Done
The repository (on SYBASE) seems to be running ok, as I can access it from my local Developer with no problems.
The SYBASE log shows…
I. 05/08 13:27:43. Running on Linux 2.4.20-021stab028.17.777-enterprise #1 SMP Tue Jul 19 19:31:27 MSD 2005
I. 05/08 13:27:44. Database server started at Mon May 08 2006 13:27
I. 05/08 13:27:44. Trying to start SharedMemory link ...
I. 05/08 13:27:44. SharedMemory link started successfully
I. 05/08 13:27:44. Trying to start TCPIP link ...
I. 05/08 13:27:44. Starting on port 2638
I. 05/08 13:27:44. TCPIP link started successfully
I. 05/08 13:27:44. Now accepting requests
I have since deleted SERVOY and re-installed a fresh copy (now 2.2.5) (SYBASE DB as well)…BUT the problem persists.
I’ve run out of ideas and would appreciate some pointers.
Thanks…
You can add a -DSTACKTRACE=true to the java command line in servoy_server.sh. This will give more information as to where the problem may be.
Thanks for the suggestion…but where exactly in the .sh file do I put the trace option
Right after “java”, i.e., “java” becomes “java -DSTACKTRACE=true”…
Thanks…I tried this but there was no additional info in server.log
All it reports is…
Loading servoy.properties from /usr/local/servoy/servoy.properties
Loading - Done
Is there any other logging I can set up or look at ?
More info…
Looking at the processes running after kicking of the .sh script I see these
root 25139 0.0 0.0 2000 916 pts/1 S 16:38 0:00 /bin/sh ./servoy_server.sh -DSTACKTRACE=true
root 25140 0.3 0.5 221020 23080 pts/1 S 16:38 0:01 java -DSTACKTRACE=true -Djava.awt.headless=true -classpath .:lib/commons-collections.jar:lib/c
root 25141 0.0 0.5 221020 23080 pts/1 S 16:38 0:00 java -DSTACKTRACE=true -Djava.awt.headless=true -classpath .:lib/commons-collections.jar:lib/c
root 25142 0.0 0.5 221020 23080 pts/1 S 16:38 0:00 java -DSTACKTRACE=true -Djava.awt.headless=true -classpath .:lib/commons-collections.jar:lib/c
root 25143 0.0 0.5 221020 23080 pts/1 S 16:38 0:00 java -DSTACKTRACE=true -Djava.awt.headless=true -classpath .:lib/commons-collections.jar:lib/c
root 25144 0.0 0.5 221020 23080 pts/1 S 16:38 0:00 java -DSTACKTRACE=true -Djava.awt.headless=true -classpath .:lib/commons-collections.jar:lib/c
root 25147 0.0 0.5 221020 23080 pts/1 S 16:38 0:00 java -DSTACKTRACE=true -Djava.awt.headless=true -classpath .:lib/commons-collections.jar:lib/c
root 25148 0.0 0.5 221020 23080 pts/1 S 16:38 0:00 java -DSTACKTRACE=true -Djava.awt.headless=true -classpath .:lib/commons-collections.jar:lib/c
root 25149 0.0 0.5 221020 23080 pts/1 S 16:38 0:00 java -DSTACKTRACE=true -Djava.awt.headless=true -classpath .:lib/commons-collections.jar:lib/c
root 25151 0.0 0.5 221020 23080 pts/1 S 16:38 0:00 java -DSTACKTRACE=true -Djava.awt.headless=true -classpath .:lib/commons-collections.jar:lib/c
root 24513 0.0 0.0 2244 772 pts/1 R 16:44 0:00 ps -aux
Not sure what this tells me…any ideas ?
This shows that Servoy is running. Strange that nothing is happening in the logs. Are you sure your servoy.properties file is correct? Does it list all the database servers? Can you connect to the local http or rmi ports of the Servoy Server? (telnet localhost 1099 and telnet localhost 8080)?
Did you change the mysql database version? Do you have the right jdbc driver for that version?
can you
kill -QUIT
where is the process id of the servoy java process which has as parent process id the servoy_servoy.sh script.
In the log you should have a stack dump which if you mail it to me, I can look at what it’s doing.
Thanks
Hi,
It seems your entropy source is blocking in a read:
"main" prio=1 tid=0x0805b948 nid=0x4dfb runnable [bfffb000..bfffb8bc]
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(FileInputStream.java:194)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:220)
at java.io.BufferedInputStream.read(BufferedInputStream.java:277)
- locked <0x447b95c8> (a java.io.BufferedInputStream)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:183)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:222)
at java.io.BufferedInputStream.read(BufferedInputStream.java:277)
- locked <0x447b93f8> (a java.io.BufferedInputStream)
at sun.security.provider.SeedGenerator$URLSeedGenerator.getSeedByte(SeedGenerator.java:467)
at sun.security.provider.SeedGenerator.getSeedBytes(SeedGenerator.java:137)
at sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:132)
at sun.security.provider.SecureRandom.engineGenerateSeed(SecureRandom.java:112)
at sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:169)
- locked <0x447b8ec0> (a sun.security.provider.SecureRandom)
at java.security.SecureRandom.nextBytes(SecureRandom.java:381)
- locked <0x447b8300> (a java.security.SecureRandom)
at org.doomdark.uuid.UUIDGenerator.getDummyAddress(UUIDGenerator.java:116)
- locked <0x447b8190> (a java.lang.Object)
at org.doomdark.uuid.UUIDGenerator.generateTimeBasedUUID(UUIDGenerator.java:237)
at com.servoy.j2db.server.ApplicationServer.main(Unknown Source)
Try adding the following flag to the java commandline:
-Djava.security.egd=file:/dev/urandom
That got things moving again ! All ports OK now and Servoy Server & Client up again.
Thanks very much for your help.
So it would appear to be a Java Security issue, if I understand you correctly ?
[/code]
Well it’s a bit Java and a bit OS and a bit Servoy. Basically, Java by default uses a secure source for random bits when using the standard random generator in java.util. By default this is /dev/random on unix, and on some unixes (Fedora Linux, FreeBSD) a read blocks until there is enough entropy to give you truly, cryptographically secure random bits. In this case we’re not using the random data for security purposes but for UUID (unique identifier) generation; so it’s not really necessary to user /dev/random, and we can use /dev/urandom which never blocks. But we have to tell java this.
Thanks for the explanation…Excellent !
This will be useful in case anyone else comes across this.
Is there anything one should do to correct the situation where /dev/random is usable again ? Not really my strong point this area.
Thanks again.
Nope, /dev/urandom is fine. Not all OS-es have /dev/urandom and a blocking /dev/random, otherwise we could change the default flag to use /dev/urandom.