Problem getting program to start on boot

[Marshall_5]

Hey everyone....
Ok, I have a program that I need to start on boot. I've put a script in /sbin/init.d. I've linked to that script in /sbin/rc3.d. I can start the program from the command line just fine using:
/sbin/rc3.d/S901Script start
or
/sbin/init.d/myScript start

Both of these start up my program and it runs great. However, it will not start at boot. In /etc/rc.log it shows that the program started ok, ie. its prints the echo statements that are in the 'start' case. However, I know the program did not start because ps -aef does not show it, and the other computer on the network with which it should be communication is not recieving.
I've scoured Google Groups for an answer and have been unable to find one. I just found this forum and hope one of you has an idea.
Some things I've tried are to put nohup on the line in the startup script so that my program doesn't get killed when the rc script dies. I tried putting the path in my script incase it wasnt set (since .profile hasn't been run yet). Neither of these things has worked.
The wierd thing is that I can start this program from the command line (using the boot script) and it works fine. This is why its so strange that it wont start on boot.

Any insight you could give would be fantastic.
Thanks,
Marshall

[John Poff]

Hi Marshall,

Does your program rely on any other piece of software that may not have been started at that point in the boot sequence?

Have you tried putting the start command script in a cron job and kicking it off to see if it starts successfully that way? You probably have the same limited environment in cron that you have at boot time, so it might be a good way to test and debug the problem.

Can you post your start script, or at least the line in it that you are using to start your program?

My guess is that there is something missing in the environment [PATH, etc.] that is causing your program to stop.

JP

[Michael Tully]

Depending on the script you may need a file under /etc/rc.config.d that determines as to whether your script start or not by using a 1 (one) or 0 (zero). There are a number of scripts/files that can be used as a reference. If your not sure, post your start/stop script.

[Oktay Tasdemir]

Hi,

Waiting for another subsystem to start might be a problem, depending what your script does I usually put in sleeps in between pre-req programs to rectify this kind of issues. Posting your script would be helpful.

[John Payne_2]

What about what the program does? Are you using nohup to start the program, and if not should you? If you start the program manually and then exit your shell, does your program exit?

BTW, welcome to the HPUX forums! The 'search' button on the pages are great to search old posts, and there are a LOT of old posts.

It migh help to see what the program is doing. I do not think the issue would be a file in /etc/rc.config.d/ because it starts from the command line...

Hope it helps

John

[Marshall_5]

Hello everyone, I sure appreciate all thesee responses.
Here is the script:

#!/bin/sh

DIR=/opt/temp/
LAUNCHER="$DIR/myProgram"
ARGS="-lf $DIR/myProg.log"
ERRLOG="$DIR/error.log"
PIXFILE="/var/run/temp/myProgram.pid"

USER="root"

PATH=/opt/java1.3/bin:/usr/sbin:$PATH:/sbin:/usr/local/bin:/home/root

case "$1" in
'start_msg')
echo "Starting program"
;;
'start')
echo "starting your program now"
cd $DIR
nohup $LAUNCHER $ARGS > $ERRLOG 2>&1 & PID=${1}
echo "prog started, pid is ${PID} ...";
;;
'stop')
echo "Stopping your program..."
fuser -k $LAUNCHER
;;
'restart')
/sbin/init.d/thisScript stop
/sbin/init.d/thisScript start
;;
*)
echo "usage....."
exit 1
;;

esac

exit 0


And here is what is resulted in the rc.log....

And here is what is resulted in the rc.log....
Starting program
Output from "/sbin/rc3.d/S901StartUp start":
----------------------------
Starting yourprogram now
prog started....


To answer a few of your questions. The program relies on the network being up because it has to communicate with a server. I haven't tried the cron job idea, but I'm definatly going to. I'm pretty new to Unix so that hadn't even occured to me. As far as needing a file in /etc/rc.config.d.... I dont think I do since my program doesn't depend on any outside variables, but I may not be understanding this files purpose. Oktay mentions using sleep to wait for other subsystems. I think the only subusystem my program uses is networking, which should be up by the time rc3.d runs, right? This is a Java program, do you guys think that has anything to do with it?
John, The program gathers information about the system and constantly reports it to a server. I haven't tried to start the program and then exit the shell. I'm not sure how to exit the shell (rookie :) ).

Anyway, thanks again for all your help guys!
-Marshall

[Gary Yu]

Hi,

If your program is not a "daemon", it tend to exit after it started at boot time, try to wrap it in a script, and using "at" to start it 10 mins later in your /sbin/init.d/script

thanks,
Gary

[Marshall_5]

I know realize that it does infact continue to run after the shell is exited. If I shell in and run the program on the command line, then logout it keeps working. I dont know if this helps but I thought I'd mention it.

[Marshall_5]

Gary,
I just tried your suggestion. It didn't work either! I created a script and put it in /sbin/init.d
I called this script delayScript, and all that was in it was the following:

#!/bin/sh
echo "/sbin/init.d/myScript start" | /bin/at now + 4 minutes

I tested this script from the command line and it worked perfectly, but when I set it up to execute at boot, it didn't work. But the wierd thing is that once again /etc/rc.local said that it worked. This was in rc.local

Output from "/sbin/rc3.d/S902startDelayScript":
----------------------------
warning: commands will be exectued using /usr/bin/sh
job 1051130613.a at Wed Apr 23 13:43:33 2003

So this makes it seem like the at command did run correctly (thats the exact same output that I got when I ran it from the command line) however, 13:43:33 came and went and my program was not started, unlike when I did it on the command line and when the time elapsed, it started the program.

What do you think?

Thanks,
-Marshall

[John Poff]

Marshall,

Do you get anything in your error.log file when the script is called at boot time?

Also, I noticed that you have this:

DIR=/opt/temp/

but you probably don't need the '/' on the end, as you prepend the '/' when you use it to set the next variable:

LAUNCHER="$DIR/myProgram"

This probably results in

LAUNCHER=/opt/temp//myProgram

I don't think that would be an issue, but you never know. It might be worth taking the trailing '/' off of the DIR assignment and trying it again.

JP

[Frank Slootweg]

I think that your program *does* start, but then *dies* due to some condition.

You may want to check for this, i.e. start the program, wait (sleep(1)) a few seconds and then check the status with ps(1). Log all output to a logfile.

Do I understand you correctly that
echo "/sbin/init.d/myScript start" | /bin/at now + 4 minutes
works from the command line, but not in the rc-invoked script?
If so, that could be explained by at(1) inheriting your current environment, which is (very) different for an interactive shell and a rc-invoked script.

By the way, cron(1M) logs the stop/start of jobs in /var/adm/cron/log which might give a indication, for example a non-normal return code ("rc=...").

Is you program really a program, i.e. an executable a.out-format file, or is it a script?
If the latter, then put "set -x" (show each statement as it is executed) at the beginning and log all output, both standard out and standard error, to a file.

[Brian Crabtree]

Are you sure that you want to use nohup with the program? If you run it outside of nohup, it should still run with a uid of 1, and should work normally.

Brian

[Carlos Fernandez Riera]

In facts Myprogram acts as a daemon, as you want it continue working when the rc3.d/s.. has finished.

If Myprogram is a sh you can include

set -x

to see a trace of teh execution.

The problem with these daemons is that init process send a HUP signal when the execution is finished, so you can use the trap instruction inside de rc script.

start)
trap '' 1


HTH

[Darren Prior]

Hi,

It's just a minor point, but I'd suggest changing your initial shell identifier from:
#!/bin/sh

to

#!/sbin/sh

regards,

Darren.

[David_246]

Hi Marshall,

The "set -x" is a very good option.
The following might be of any use as well :

nohup $LAUNCHER $ARGS > $ERRLOG 2>&1 Sometimes a script wants to bound itself to a tty type, which you don't have using at or at boot. /dev/null redirects this (under Solaris). PLease try this.

Also :

nohup /usr/local/bin/tusc $LAUNCHER $ARGS > $ERRLOG 2>&1 & PID=${1}

Will tell you exactly what syscalls are done and where it fails. Be aware that $ERRLOG will grow very fast.


Best Regs David

P.S. : I know you're quiet new, but please don't forget to reward you previous answers.

[Marshall_5]

Hey everyone, Thanks for all the help.
I got this figured out late last night. The short version is that it was a problem with the differences in environments between the command prompt and the startup.

Here's the long version:
It turns out that the binary that I was trying to start up was not a binary at all. The installer product we use creates a big shell script rather than a binary when it packages our product for installation on Unix. And since I'd been working almost exclusivly on Windows I was not aware of this fact. Anyway, what was happening was that in this script were several commands that weren't being executed because the path wasn't set correctly or something. I changed the PATH= line in the script and added "export PATH". This fixed the problem, the script started at boot for the first time in a week!!

Thanks again everyone for you help!
-Marshall

[Marshall_5]

Hey everyone, Thanks for all the help.
I got this figured out late last night. The short version is that it was a problem with the differences in environments between the command prompt and the startup.

Here's the long version:
It turns out that the binary that I was trying to start up was not a binary at all. The installer product we use creates a big shell script rather than a binary when it packages our product for installation on Unix. And since I'd been working almost exclusivly on Windows I was not aware of this fact. Anyway, what was happening was that in this script were several commands that weren't being executed because the path wasn't set correctly or something. I changed the PATH= line in the script and added "export PATH". This fixed the problem, the script started at boot for the first time in a week!!

Thanks again everyone for your help!
-Marshall