Upgrading Linux? Watch out for changes to the Java JSVC / Commons Daemon.

If you're using JSVC to run your Java daemon processes on Linux, watch out for the change in command options which come with upgrading your Linux distribution.

Shifting from Ubuntu 10.04 to 12.04 / 14.04 (which you should be doing now, as Ubuntu 10.04 reached end of life as of May 1st, 2015) is a simple enough process, but your Java daemons will likely refuse to start after your Linux upgrade completes.

There are two things to watch out for:

First off, if you're using OpenJDK, the Java path has changed between Linux distributions. Where the path was once at:

/usr/lib/jvm/java-6-openjdk

It is now set to be CPU-specific. For example, if running Ubuntu 12.04 / 14.04 on a Linode, you'll find your OpenJDK path is now at:

/usr/lib/jvm/java-6-openjdk-i386

Any scripts you might have which referenced that old path for Java home will need to be updated, or else you'll be presented with a "Cannot locate Java Home" error when attempting to start your Java programs.

The second set of pitfalls relate to JSVC itself.

When calling JSVC, you may be presented with the error "JSVC re-exec requires execution with an absolute or relative path" when attempting to start your Java daemon. As described in that error message, it turns out the full path to JSVC now needs to be specified for the binary on daemon start. So, a command-line call to JSVC should use the full file-and-path of:

/usr/bin/jsvc

rather than just a call to the jsvc binary by itself.

For one final, sneaky change which might trip you up, the working directory for your Java jar also needs to be defined in the JSVC call's options.

For previous versions of JSVC, simply changing to the desired working directory prior to running JSVC was sufficient to define the working directory for the daemon, but that is no longer the case. The working directory must now be explicitly set using the -cwd option of the JSVC command.

it appears the -cwd option was mistakenly left out of the JSVC man pages

That might be a surprise to you if you've been reading the JSVC man page in an attempt to identify what has been going wrong with your JSVC-run Java jar, as it appears the -cwd option was mistakenly left out of the JSVC man pages. Until that JSVC man page omission has been corrected, I'd recommend a read of the command as documented at JSVC's apache.org page if you're looking for a full overview of the new JSVC / Commons Daemon functionality. You can find that page at:

http://commons.apache.org/proper/commons-daemon/jsvc.html

Through that page, you'll discover that JSVC will set your Java jar's working directory to be "/" if the -cwd option is missing (thanks to Arkain on StackOverflow for pointing that out!), which will likely mess up any file i/o in your daemon.

To summarize all of the above with an example of the changes you might need to make to your JSVC call:

If you had a script on Ubuntu 10.04 to start via JSVC a Java jar myJavaProgram.jar using the daemon interface startJSVCDaemonProcess with working directory myWorkingDirectory, running as user myUser and writing out a PID at myPIDFile.pid, your script might previously have read:

cd /srv/myWorkingDirectory

jsvc -user myUser -home /usr/lib/jvm/java-6-openjdk
-pidfile /srv/myWorkingDirectory/myPIDFile.pid
-cp /srv/myWorkingDirectory/myJavaProgram.jar
com.companyname.start.startJSVCDaemonProcess

To have the same functionality using the current JSVC / Commons Daemon under Ubuntu 12.04 / 14.04, you would need to change that script to read:

/usr/bin/jsvc -cwd /srv/myWorkingDirectory
-cp /srv/myWorkingDirectory/myJavaProgram.jar
-java-home /usr/lib/jvm/java-6-openjdk-i386
-user myUser -pidfile /srv/myWorkingDirectory/myPIDFile.pid
com.companyname.start.startJSVCDaemonProcess

By making those changes you will have:

- Called the jsvc binary using the full file-and-path;
- Edited the OpenJDK path for Java Home; and
- Added in the -cwd option to set the daemon's working directory.

You should then find your Java .jar daemon process running as before, but be sure to run your unit tests to confirm the environment change all the same.

To Main Page
Back To Top
To Blog Archive