I am having some issues with a Tomcat application server. Before I can get to fixing the problem with the Java application, I need to come up with a cron shell script to restart the server.

I thought this would be a simple endeavor, but the one complication is that the root cause makes Tomcat not shutdown cleanly after executing ./shutdown.sh. The process is still open when I run ps auwwx | grep java | grep org.apache.catalina.startup.Bootstrap

I kill -9 the process (yes, that's bad, but things do come up ok - so far ;) ) and I can restart the server correctly.

I'm not a shell script expert (or novice for that matter) and I need some help with "polling" for a period of time until the ps command above returns null. After a polling period I would do a kill, then a restart.


This is a rough outline of a script that would do what you want. Of course, you'll have to flesh it out and you can change the argument to sleep (shown here as five seconds).

while ps | grep | grep > /dev/null
    sleep 5

You can combine the two greps into one using a regular expression if necessary. Note: when you are doing this sort of thing, you can sometimes get false positives when grep finds itself (although your two greps prevent this). In order to avoid that, you can do grep [s]omething which will find "...something..." but not "grep something" in the output of ps.

  • I think you wanted grep [s]omething , not grep [s]something . – Bill Weiss Dec 16 '09 at 19:18
  • on some system grep [s]something will not work, there you can do a grep something | grep -v grep. it is more complicated but will work. – Christian Feb 2 '10 at 11:10

What you're doing is a patch to not handling Java exceptions properly. I understand wanting to do the restarts, really, I do. If this is a long-term or production project, the world will be a better place if you just catch and handle the errors.

(Tomcat dies if any errors make it all the way back up the call stack.)


We had to solve this exact problem while developing our product Tcat Server to support reliable restarts.

You can download Tcat Server and take a look at tcat6.sh for ideas on how we solved it. If you have specific questions, feel free to post here.

Tcat Server is actually 100% vanilla Tomcat with added features for config mgmt, deployment and diagnostics - would love you to download and see if it meets your needs. Its free to use in development, and can be downloaded from: http://www.mulesoft.com/download-tcat-server-enterprise-tomcat. If you do not want to use the web console, you can use curl to invoke Tcat Server REST API to do the restarts.

Hope this helps.

Disclaimer: I work for MuleSoft and is heavily involved with Tcat Server.


App servers like Tomcat don't like it if webapps behave wrong (doing nasty things with classloaders, memory leaks, starting non-daemon threads etc.) so they cannot shutdown properly when asked to.

First thing, to restart the Tomcat the hard way, may be the "right" thing to do to keep operations running until the app can be fixed. Next thing is to increase log level and check the logfiles for obious spots like OutOfMemoryErrors etc. If you're lucky, the webapp uses logging and may point out what it's doing.

The next thing is to attach a monitoring agent (visualvm.dev.java.net is doing a great job) to the Tomcat instance. You need to enable JMX on server side before you can connect to it remotely. If you're using Suse Linux or alike, don't forget to set the server rmi hostname as system property. Watch the memory consumption, take thread dumps when the servers hangs. When you issue a shutdown request with shutdown.sh and the server does not shut down correctly, take a thread dump and see which threads are running and in what class/method they're right now.

If there's something wrong with memory, you may want to try tweaking the garbage collector settings for the JVM or use another JVM like JRockit. Using a more aggressive GC may help.

Another way is to prevent the app from doing whatever it does wrong - use a Security Manager and tweak the security policy file until the app is working. It may reveal that the app is doing something which it shouldn't do in the first place.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.