Re: Using daemontools to supervise Tomcat
Just an FYI: I utilized Will's wonderful instructions and now have Tomcat supervised by Daemontools. the 'svc' command even works for HUP'ing and such! Ben Ricker On Fri, 2002-10-11 at 16:30, Will Hartung wrote: From: camccuk [EMAIL PROTECTED] Sent: Friday, October 11, 2002 8:08 AM Does anyone have any experience with using Dan Bernstein's daemontools to supervise Tomcat? I've had real trouble getting this to work with either startup.sh or catalina.sh but I'm putting this down to the fact that I'm no genius with unix processes... I don't really understand what the issue is here, but I plead ignorance in that I haven't worked with the DJB tools in a while. But, as I recall, the tools simply execute the program using the (by default) 'run' script. When run exits, for whatever reason, the tools fire it back up. Now the tomcat startup scripts fire the java process off in the background, but as I recall there is an option to NOT do that, and simply have tomcat.sh stay in the foreground. It seems to me that a few simple tweaks to tomcat.sh, linked to 'run' in the proper spot, and it should Just Work. Lemme look. This man has a bad heart. Angina Pectoris, but we have the cure...Yes. Here they are... Yes, here it is, just start catalina.sh with the run option, and it doesn't fork into the background. #!/bin/sh # daemontools run script for Tomcat cd /usr/local/java/jakarta-tomcat-4.0.4/bin # start tomcat in the foreground, redirect stderr to stdout for logging. exec ./catalina.sh run 21 Copy or link this script to /services/tomcat/run, and it should fire right up. Untested, but it should work. Multilog should work with this as well, as the 'run' option doesn't redirect stdout or stderr, whereas the (default) 'start' option does. Since multilog only listens to stdin, the script redirects stderr to stdout so it can be captured as well. You need to setup the log directory properly, as mentioned in DJBs faq. The key is to keep the java process in the foreground for the 'run' script. supervise puts it in the background for you, so that's why the run script doesn't need to. Regards, Will Hartung ([EMAIL PROTECTED]) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Using daemontools to supervise Tomcat
From: camccuk [EMAIL PROTECTED] Sent: Friday, October 11, 2002 8:08 AM Does anyone have any experience with using Dan Bernstein's daemontools to supervise Tomcat? I've had real trouble getting this to work with either startup.sh or catalina.sh but I'm putting this down to the fact that I'm no genius with unix processes... I don't really understand what the issue is here, but I plead ignorance in that I haven't worked with the DJB tools in a while. But, as I recall, the tools simply execute the program using the (by default) 'run' script. When run exits, for whatever reason, the tools fire it back up. Now the tomcat startup scripts fire the java process off in the background, but as I recall there is an option to NOT do that, and simply have tomcat.sh stay in the foreground. It seems to me that a few simple tweaks to tomcat.sh, linked to 'run' in the proper spot, and it should Just Work. Lemme look. This man has a bad heart. Angina Pectoris, but we have the cure...Yes. Here they are... Yes, here it is, just start catalina.sh with the run option, and it doesn't fork into the background. #!/bin/sh # daemontools run script for Tomcat cd /usr/local/java/jakarta-tomcat-4.0.4/bin # start tomcat in the foreground, redirect stderr to stdout for logging. exec ./catalina.sh run 21 Copy or link this script to /services/tomcat/run, and it should fire right up. Untested, but it should work. Multilog should work with this as well, as the 'run' option doesn't redirect stdout or stderr, whereas the (default) 'start' option does. Since multilog only listens to stdin, the script redirects stderr to stdout so it can be captured as well. You need to setup the log directory properly, as mentioned in DJBs faq. The key is to keep the java process in the foreground for the 'run' script. supervise puts it in the background for you, so that's why the run script doesn't need to. Regards, Will Hartung ([EMAIL PROTECTED]) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Using daemontools to supervise Tomcat
I tried to get Daemontools running for Jserv (which is pretty similar) and had no luck. My guess is that you might be able to get it to work if you pass all the env variables using daemontools and just launch java. However, since java is not a normal daemon, you will probably need fghack to do it. I myself gave up; the thought of creating all those environment variables was just too much, so I just rolled my own PID monitor whcih I am porting to Tomcat. Basically, it will grep out the PID and write to a file which I watch with a cronjob process. HTH, Ben Ricker On Fri, 2002-10-11 at 10:08, camccuk wrote: Hello all, Does anyone have any experience with using Dan Bernstein's daemontools to supervise Tomcat? I've had real trouble getting this to work with either startup.sh or catalina.sh but I'm putting this down to the fact that I'm no genius with unix processes... Having said that, DJB's documentation isn't the most encouraging in the world... I've got Tomcat 4.0.4 with daemontools 0.7 Any pointers very welcome, cam __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ben Ricker [EMAIL PROTECTED] Wellinx.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Using daemontools to supervise Tomcat
--- Ben Ricker [EMAIL PROTECTED] wrote: I tried to get Daemontools running for Jserv (which is pretty similar) and had no luck. My guess is that you might be able to get it to work if you pass all the env variables using daemontools and just launch java. However, since java is not a normal daemon, you will probably need fghack to do it. I myself gave up; the thought of creating all those environment variables was just too much, so I just rolled my own PID monitor whcih I am porting to Tomcat. Basically, it will grep out the PID and write to a file which I watch with a cronjob process. I'b be interested to see that Ben - one of the problems I had trying something similar was that when tomcat gets swapped out, it appears on the process list as [java] and there is *no way* to my knowledge (or that of the various usenet groups/lists etc that I pestered) of getting back the command line to see which instance of the JVM you are dealing with - this was a problem for me on a machine running at least two JVMs. I had to use fghack already to stop supervise trying to start tomcat dozens of time but I still couldn't get multilog to work and supervise seemed to act weirdly afterwards (although svstat worked ok and svscan got into a confused state trying to start the run script in the logging subdirectory - something supervise won't do for me) BTW, I have a run script for kicking off JServ which I'll send you off-list in case its of any use... Cheers, cam __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Using daemontools to supervise Tomcat
You can see more info on your Tomcat processes by increasing the column
display of ps. For example, on a RedHat box, use ps -ef --cols=300 |grep
java and you can see the full command line used to start Tomcat. In my
environment (multiple, distinct Tomcats) there is a different server.xml for
each instance. Using the --cols option makes it trivial for me to see
exactly which instance is which, and obtain the PID of the instance in
question for stopping purposes.
In addition, Tim Funk posted back in June a roll-your-own solution for
getting the PID of Tomcat anytime you want, from whatever tool you desire,
which I will repost here. It's not absolutely thorough with every exact
line of code you need, but it should be sufficient for a really good start.
It's a nice little tip/trick:
begin repost of Tim's PID solution
For what its worth - I created (and use) a LifecycleListener that runs
on startup which logs the process ID into a file called tomcat.pid.
Which is created by a shell script called writepid.sh. Below is all the
code to get this to work. This code also assumes your current working
directory is $CATALINA_HOME.
--Begin code
import org.apache.catalina.LifecycleEvent;
/**
* A helper for getting the PID of java so shutting down tomcat is MUCH
* easier.
*/
public class PidLifeCycle implements org.apache.catalina.LifecycleListener {
public void lifecycleEvent(LifecycleEvent event) {
if (start.equals(event.getType())) {
try {
Runtime.getRuntime().exec(/bin/sh bin/writepid.sh);
} catch(Throwable e) {
e.printStackTrace();
}
}
}
}
--End Code
The code above will launch the following shell script. Should be in the
bin/ directory of your tomcat installation.
--Begin Shell script
echo $PPID logs/tomcat.pid
--End Shell script
Then add the following into server.xml
--Begin server.xml snippet
Listener className=PidLifeCycle /
--End server.xml snippet
end repost of Tim's PID solution
John
-Original Message-
From: camccuk [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 11, 2002 1:49 PM
To: Tomcat Users List
Subject: Re: Using daemontools to supervise Tomcat
--- Ben Ricker [EMAIL PROTECTED] wrote:
I tried to get Daemontools running for Jserv (which is
pretty similar)
and had no luck. My guess is that you might be able to get
it to work if
you pass all the env variables using daemontools and just
launch java.
However, since java is not a normal daemon, you will probably need
fghack to do it.
I myself gave up; the thought of creating all those environment
variables was just too much, so I just rolled my own PID
monitor whcih I
am porting to Tomcat. Basically, it will grep out the PID
and write to a
file which I watch with a cronjob process.
I'b be interested to see that Ben - one of the problems I had
trying something
similar was that when tomcat gets swapped out, it appears on
the process list
as [java] and there is *no way* to my knowledge (or that of
the various usenet
groups/lists etc that I pestered) of getting back the command
line to see which
instance of the JVM you are dealing with - this was a problem
for me on a
machine running at least two JVMs.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Using daemontools to supervise Tomcat
--- Turner, John [EMAIL PROTECTED] wrote: You can see more info on your Tomcat processes by increasing the column display of ps. For example, on a RedHat box, use ps -ef --cols=300 |grep java and you can see the full command line used to start Tomcat. This is true John (I use ps -auxf!), *except* when a process is swapped out - I lost a lot of hair over that one... In my environment (multiple, distinct Tomcats) there is a different server.xml for each instance. Using the --cols option makes it trivial for me to see exactly which instance is which, and obtain the PID of the instance in question for stopping purposes. In addition, Tim Funk posted back in June a roll-your-own solution for getting the PID of Tomcat anytime you want, from whatever tool you desire, which I will repost here. It's not absolutely thorough with every exact line of code you need, but it should be sufficient for a really good start. It's a nice little tip/trick: Many thanks for posting this - having the PID is definitely the way to go... cam __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Using daemontools to supervise Tomcat
No problem, glad to help. Thanks to Tim for the tip, it has come in handy. John -Original Message- From: camccuk [mailto:[EMAIL PROTECTED]] Sent: Friday, October 11, 2002 2:01 PM To: Tomcat Users List Subject: RE: Using daemontools to supervise Tomcat which I will repost here. It's not absolutely thorough with every exact line of code you need, but it should be sufficient for a really good start. It's a nice little tip/trick: Many thanks for posting this - having the PID is definitely the way to go... cam -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Using daemontools to supervise Tomcat
On Fri, 2002-10-11 at 12:48, camccuk wrote: --- Ben Ricker [EMAIL PROTECTED] wrote: I'b be interested to see that Ben - one of the problems I had trying something similar was that when tomcat gets swapped out, it appears on the process list as [java] and there is *no way* to my knowledge (or that of the various usenet groups/lists etc that I pestered) of getting back the command line to see which instance of the JVM you are dealing with - this was a problem for me on a machine running at least two JVMs. Actually there is. I use a -Dafoo to give the process a unique identifier. This sets a marker on the process but does nothing for the JVM itself. To find a process ID, I would use 'pgrep -f foo' and the PID is returned (this is on Unix, btw). Also , when you do the '-Dafoo' as the first arg to the JVM, it appears in 'ps -ef'. Here is how I do it: I setup the java command line like so: /usr/local/jdk/bin/java \ -Da=Ftp \ -cp $PROP_DIR:$EXT_INT_JAR:$NET_COMPONENTS_JAR:$LOG4J_JAR \ com.usrx.extinterface.ftp.FTPService $PROPERTIES_FILES \ $LOG_FILE 21 Then I do this: pgrep -fn Ftp $PIDFILE Technically, you do not need the 'n', as that denotes the newest process. You can get by with just the -f. Finally, I run the following script through cron every minute. The variables should be self-explanatory. For security reasons, I cannot divulge the whole setup. Basically, this snippet below monitors 7 JVMs and if they are not running, restarts them. It has worked flawlessly for a long time. -Begin Snippet-- for i in $* do eval BASEDIR=$`echo BASEDIR_$i` eval PIDFILE=$BASEDIR/$`echo PIDFILE_$i` eval PNAME=$`echo PNAME_$i` eval CHECKFILE=$BASEDIR/$`echo CHECKFILE_$i` eval START=$BASEDIR/$`echo START_$i` if [ -f $PIDFILE ] ; then PID=`cat $PIDFILE` if [ x$PID != x ] kill -0 $PID 2/dev/null ; then STATUS=$PNAME ($PID) running RUNNING=1 else STATUS=$PNAME ($PID?) NOT running RUNNING=0 fi else STATUS=$PNAME (no pid file) NOT running RUNNING=0 fi if [ $RUNNING = 0 ]; then if [ -f $CHECKFILE ] ; then if [ `cat $CHECKFILE` = 0 ] ; then echo $STATUS - restart failed. | mail -s $PNAME alert $RECIPIENTS logger -p local0.crit -t pidmonitor.sh $STATUS: restart failed. echo 1 $CHECKFILE fi cd $BASEDIR $START start else echo $STATUS - will attempt to start. | mail -s $PNAME alert $RECIPIENTS logger -p local0.crit -t pidmonitor.sh $STATUS: attempting to start. touch $CHECKFILE echo 0 $CHECKFILE cd $BASEDIR $START start fi else if [ -f $CHECKFILE ] ; then /bin/rm $CHECKFILE echo $STATUS | mail -s $PNAME alert $RECIPIENTS logger -p local0.crit -t pidmonitor.sh $STATUS fi fi done --End Snippet-- I had to use fghack already to stop supervise trying to start tomcat dozens of time but I still couldn't get multilog to work and supervise seemed to act weirdly afterwards (although svstat worked ok and svscan got into a confused state trying to start the run script in the logging subdirectory - something supervise won't do for me) You will have to use fghack because java does not act like a daemon usually does. A daemon usually puts itself into the background after executing. Java does not. That is what fghack does. Unfortunately, as the web site for daemontools says, if you use fghack, it will disable your ability to use svc and will make all the other commands pretty useless. Daemontools works great with daemons that act like daemons; it works like hell with programs that don't. -- Ben Ricker [EMAIL PROTECTED] Wellinx.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
