I have a Java process which is dying after running for a few days on a Solaris box. The application’s log doesn’t have any info why the process died. Looking at the script that launches the Java process, I see that stdout and stderr are redirected to /dev/null. Is this a good idea in general for Java processes (e.g., where do Java out of memory errors get logged)?
How/Where do I start by debugging my current problem (the process dying)? Should I try redirecting stdout & stderr to a normal file?
nohup $JAVA_HOME/bin/java \
-Xms256m \
-Xmx1024m \
-jar $CRON_HOME/cron.jar > /dev/null 2>&1 &
Definitely send this info to a log file. Redirecting stdout/stderr to
/dev/nullmeans you’re throwing away valuable info. Send the output to either one or two files. It’s probably easier to redirect stderr to stdout so you can interleave the results. As to where you log this info, it’s probably best to ask your system admins, since they will likely have views on where this sort of info should go (and you don’t know yet how much info you’ve got coming out).One particular scenario in which this is valuable is when the JVM itself crashes (as opposed to your application within the JVM). A crash report gets dumped out to stdout and if you’re capturing stdout that’s valuable if only to tell you why the JVM disappeared.