Stackify on Ideas on Software Engineering

Differentiate Java Processes by Working Directory

Sun, 17 Feb 2013 00:00:00 +0000

A lot of server software runs on Java, but the different Java processes are listed as simply Java via commands like top or ps -ef. One feature of the Stackify agent is tracking the running processes on a server. I needed a way to identify what each Java process really was in a fairly simple and concise way, but there isn’t a clear winner in the output of the top or ps commands.

Running ps -ef | grep java will output something nasty, similar to what follows. You can likely figure out what the Java process is actually running from the args — the example below obviously being tomcat — however, it’s not the most readable and doesn’t give a clear and concise value to display to a user in the Stackify web site. The user of the process below also indicates that it is running tomcat, but that won’t be the case for all Java processes.

tomcat7 41298 1 5 18:05 ? 00:00:03 /usr/lib/jvm/default-java/bin/java -Djava.util.logging.config.file=/var/lib/tomcat7/conf/logging.properties -Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/usr/share/tomcat7/endorsed -classpath /usr/share/tomcat7/bin/bootstrap.jar:/usr/share/tomcat7/bin/tomcat-juli.jar -Dcatalina.base=/var/lib/tomcat7 -Dcatalina.home=/usr/share/tomcat7 -Djava.io.tmpdir=/tmp/tomcat7-tomcat7-tmp org.apache.catalina.startup.Bootstrap start

I decided it might work to differentiate the Java processes by working directory, but I wasn’t sure if there was a good way to find the working directory. Through some Google searches I discovered the pwdx command. The pwdx command takes a list of pids as parameters and outputs a row with the pid and the working directory for each pid. The working directory doesn’t work for all situations, but I’ve found it generally gives a concise way of determining what a Java process is actually running. I’m certainly open to suggestions if anyone has a better idea.

Running the pwdx command for the output above — sudo pwdx 41298 — leads to the following output. By combining this with the process name I can give the Java processes a more informative name when displayed in the Stackify website. This Java process would be displayed as Java (/var/lib/tomcat7).

41298: /var/lib/tomcat7

Writing a Good Linux Init Script

Fri, 28 Dec 2012 16:18:45 +0000

A good Linux init script that works across multiple distros is hard to find. Most distros have a sample/skeleton init script to base your own init scripts on, but that requires having a separate init script for each distro. For the Stackify Linux agent I wanted to have a single init script that would work on all common Linux distros. I had a decent init script that worked pretty well for ‘start’ and ‘stop’ commands, but not so much for ‘status’. The ‘status’ command worked on my development machine (Ubuntu) but didn’t work on the other distros I was testing on (CentOS/Redhat/Amazon).

Since one of the things the Stackify Linux agent does is provide information on the different installed services and their statuses, it is important that the status of our own service is correct. As we prepare for the first beta release of the Linux agent, I decided it was time to rewrite the init script. I started with some Google searches on how to create a cross-distro init script, but they mostly led me back to the skeleton init scripts. While having lunch with a former coworker at Fuzzy’s Taco Shop – which I highly recommend – we got to discussing init scripts and he mentioned seeing an “init script to rule them all.”

After lunch, I promptly searched for this legendary script. My search lead me to the One Java init script to rule them all, which is an init script for Java application servers (e.g. Tomcat and JBoss) that will work on most Linux distros. Turns out this script was really close to what I needed since the Stackify Linux agent is a Java application. Many Linux distros have started implementing the Linux Standard Base (LSB) which provides logging methods and a standard way to implement init script statuses. However, since not all versions support LSB, I cannot use those logging methods for my init script.

The nice thing about the Java init script to rule them all is that it checks for the existence of the LSB methods and if they do not exist it provides its own implementation. I was able to base the Stackify agent init script largely on this existing script. The script now works on all of the distros previously mentioned and should also work on most other distros. The status returns the correct status on these distros and returns the correct status code for systems that do support LSB.