Newbie needs help with starting Java daemons at boot up time.

[Alex MacKay]

Demographics:
I am running on a HP-UX.
I have built 3 shell scripts to run as daemons when the box is booted.
The scripts are located in /sbin/init.d.
All 3 scripts are using the same job name ???aceacct1???.
The main function of the script is to start the java vm (Sun 1.3) and run an application
coded in Microsoft J++ ( realize there will be some people seeing red).

Problem description:
When I start the scripts from a HyperTerminal session they all start fine, the application runs without any problems. There are no issues at all.
When I start the script via the root at boot up time, one of the scripts will not start properly and dies. I start the same scripts whether manually or via boot up.
I use the same account to start all 3 scripts manually and at boot time.

Application description:
The application is a logging application with three pieces. It is a lightweight application that uses port and socket processing for communication. Thus the application can run on separate box or the same box. I am developing the scripts on the same box.

Script description:
The only difference in the scripts is the main class that the vm starts, and where that class exists. Here, is it ConfigurationService.


Code:

/usr/bin/su - aceacct1 -c " . .profile; /opt/java1.3/bin/java com.allstate.infrastructure.configuration.internals.Conf
igurationService &"
rval=$?;
set_return;
;;


At this point, the only thing I can think of is that there was something set up incorrectly or missed that deals with the authority.

[A. Clay Stephenson]

Almost certainly it is your su - aceacct1 rather than simply su aceacct1. I know - you want to run aceacct1's .profile so that his environment is set up BUT the problem with that is that there are are number of commands like tset, tabs ... that expect an interactive environment - which you ain't. The best solution is to create a file, e.g. /usr/local/bin/myenv.sh that sets and exports any needed variables. Make sure that there are no returns or exits in this file. You then source this file (e.g. . /usr/local/bin/myenv.sh) in both your init.d script and aceacct1's .profile.

[Mike Stroyan · Accepted solution]

Your "daemon" is probably just dying because it recieves a SIGHUP signal when the /sbin/rc completes. To properly daemonize a process it needs to ignore SIGHUP. You can do that with java by just using the nohup command to start java-
nohup java MyClass
or
nohup java MyClass >/dev/null 2>/dev/null

It looks like the recently added "java -Xrs" option may also prevent SIGHUP termination, but I haven't experimented with it.

[Alex MacKay]

To Mike Stroyan or anybody else actually.
Mike, your answer was 100% correct and fixed the problem entirely. I have been trying to read about nohup with limited success. Can you explain in detail exactly what is happening? If anyone can I would appreciate it.

[Mike Stroyan]

The classical SIGHUP use is for a person logging out of a terminal session. The SIGHUP signal is sent to all the processes that were using that terminal as their "controlling tty". It tells the processes to react to the logout.
The rc scripts are run by a shell process that is a "process group leader", so when it exits the descendent processes are also sent a SIGHUP. Programs that want to be long running "daemon" processes need to prevent that SIGHUP from killing them. They can either change their process group or change their reaction to SIGHUP. Changing the process group can be done with any of setsid, setpgid, setpgid2, or setpgrp. (Everyone seems to want to invent their own way to do that.)
There are even more ways for a process to change its reaction to a signal. There are many, many functions for setting signal handling. The "java -Xrs" option uses some of those functions to change signal handling.
Plus, the signal handling can actually be fixed up by a starting command without rebuilding the program. The nohup command actually sets the signal handling for SIGHUP
to SIG_IGN instead of the default SIG_DFL, which would exit for SIGHUP. nohup then runs the command that you give it. That inherits the SIG_IGN, so your java command will successfully ignore the SIGHUP that it gets when rc exits.

[Allan Pincus]

Alex,

I had a similar problem starting a http daemon. The solution was to use "nohup" but I had to call out the whole path

/usr/sbin/nohup

So if Mike's solution does not appear to work right away, it may be that your PATH variable is not including /usr/sbin

Once I called out the correct path, everything works.

nohup means "no hangup" when the shell that started the process quits. It will continue to run in the background.

- Allan

[Alex MacKay]

In resonse to Allen and Mike, I probably was not clear. I did use the "nohup" command and that fixed the problem completely. I did not have to specify the path with nohup, the path variables had been set for usr, etc.
So in the script I have

nohup /opt/java1.3/bin/java classpath/class &


This was the first Java daemon started at boot up etc., that we had that I am aware of. None of the other boot up scripts/daemons have this problem. But then again, they are not java. Can I assume this only applies to Java daemons or are the other cases where booting up will require the "nohup" command?

[Alex MacKay]

Can anyone tell me how I get the rabbit in the hat applied to Mike's first answer since that is the answer that solved the problem. THANKS...