restarting init.d script without rebooting

[Allan Pincus]

Is there anyway to simulate a reboot and have scripts called again in rc3.d without actually having to reboot?

I know I can do this, but I can't seem to locate the reference.

[Pete Randall]

Allan,

Sure, just do "/sbin/init.d/SCRIPTNAME start"

Pete

[Allan Pincus]

Yes, I've done that, but I found that it does not emulate a reboot. Seems that my script will launch that way, but not at reboot. I'm having an odd problem.

Thanks for this input!

[Jeff Schussele]

Hi Allan,

What errors, if any, are you getting in the /etc/rc.log file when these scripts don't start?

Rgds,
Jeff

[Allan Pincus]

None!!!!!

I see the script start, with no errors. I've had the script spit out everything to /etc/rc.log, with no problems.

Now I'm trying to start my script with nohup, just to see if it works.

When I run the Start script (S101) from rc3.d it works fine. At reboot, I get the start up message, but the process isn't there.

Weird.

[Ollie R]

Hi Allan,

You can try bringing the server down to the run level below the one you want to run the scripts for - i.e. 2 in this case - but it can be just as catastrophic for the applications as a reboot and may not clean up properly:
init 2
init 3

Don't know if that's of any use???

Ollie.

[Jeff Schussele]

Do you have a config file for this process in /etc/rc.config.d ?

Jeff

[Jim Butler]

make sure your shell is
#!/sbin/sh

or whatever you have from

echo $SHELL (when you are successful

[Steve Labar]

Have you stopped the service before starting it again? I would run /sbin/init.d/SCRIPTNAME stop
then
/sbin/init.d/SCRIPTNAME start

Good Luck.

Steve

[James R. Ferguson]

Hi Allan:

If you script works when you manually launch it but not during bootup, I'd look to differences in the environment. Make sure that you have a PATH declaration in your script along with any other variables that you would "normally" have if your $HOME/.profile had been sourced.

Regards!

...JRF...

[Gary Yu · Accepted solution]

Hi Allan,

I had the same problems before, and I got some hint from this forum. It seemed that if the App/process you are trying to bring up from /sbin/init.d at boot time is not a Daemon, it won't last. That's why even though you saw everything is fine from /etc/rc.log, still it's not up, because it exit after 1 or 2 seconds.

To solve this problem, there're 2 ways:

1. write your wrapper scripts, put what ever in the /sbin/init.d/your-script start part in this wrapper, and make it a daemon, then call this wrapper from /sbin/init.d/your-script

2. write a script, put all the start-up part from your origenal script into this script, and put it somewhere else, say "/", then in the /sbin/init.d/your-script start part, instead of calling this new script directly, using "at" command to schedule it start after 5 or 10 mins ( depend on how long the whole system will start up normally), then it will start with normal way -- like you did to call this script from command line.

the 2nd solution is simple, the key is to make the proper time for "at" command, so that it will start soon after the system is booted. But if there's other Apps you put at /sbin/init.d which have dependency on this App , you can only use solution 1.

hope it helps,
Gary

[Martin Johnson]

Verify all your PATH and environment variables aer set correctly in your startup scripts.

HTH
Marty

[Kelli Ward]

Hi,

If I understand your question correctly:

You can start up a script manually by /sbin/init.d/<scriptname> start/stop

However, some scripts depend on others to be started in a particular order in order to run properly. Also, some scripts don't like to be "start"ed without being "stop"ped first.

For example, /sbin/init.d/net will be annoyed if /sbin/init.d/hostname wasn't run first.

The best way to figure the safest way to start a daemon process is to figure what it depends on (if applicable) and in what order and follow it.

Open question - I just now thought about this. Linux has a restart option in many of it's /etc/init.d scripts. Does HP-UX? I've never thought to try it.

HTH,
Kel

[Jeff Schussele]

Hi Kelli,

Appears only the sshd daemon has an explicit restart sequence out of the box. Although others like swagentd can be restarted with parms on the command line. (swagentd -r).
But it would be fairly straightforward to set up a restart case value in any - as long as they can be stopped/started normally.
See /sbin/init.d/sshd2 for an example.

BTW - New hat looks good!!

Rgds,
Jeff

[Kelli Ward]

Hi Allan,
I'm sorry, I wasn't giving your question my full attention. I read the rc3.d comment and then ignored it in my note.

The easiest way might possible be to write a script that starts all the scripts linked in rc3.d and test it on a non production unit first to help ensure as little risk of problems as possible.

I know of no builtin way accomplish this.

Also - I received a usage statement when I attempted "restart" on a process for grins.

Good luck,

Kel
N/A for this one please.

[Kelli Ward]

Jeff - Thanks for the info and compliment.
This hat's pretty comfortatble. I like it.
I'm looking forward to trying on the pointy one.
Kel

[Thomas Schler_1]

Allan,

your original question is, how to "simulate" a reboot without actually reboot the system. This can be done by changing to the single user mode and than going back to the run-level you like. The system actually does no reboot:
# shutdown 0 # change to single user mode
# init 3 # change to run level 3 (rc3.d)

All the init.d scripts have been stopped and started again without reboot.

When you are writing the startup script by your own, you have to be very careful. Not just start any program and expecting it is there. Do also check if the desired programs are there where they are expected, check if they can be executed, check if all necessary configurations are done (best to do inside /etc/rc.config.d), check what the exit values of the started programs are. You have to program your startup message by your own, in your startup script you have to decide when your startup message has been appended with an "OK", "FAIL", or "N/A". Check if your desired process is really running after executing the main part of your startup script, if not your startup script has to exit with returning 1.

[Frank Slootweg]

It seems to me that your script probably *does* start "the process", but then the process dies, but you don't know it/why.

If that is the (suspected) scenario, then - assuming that you normally start "the process" as "/path/to/the_process &" -, start "the process" as follows:

[stuff in your script]
nohup /path/to/the_process &1 >>/the_process.log &
sleep 10
ps -ef | grep the_process >>/the_process.log

The nohup(1) is a safeguard in case the_process is not a real daemon, i.e. it will die when the (shell executing the) script terminates.

The redirection is to catch all messages.

The sleep(1) is to allow nohup(1) time to do its work, i.e. a "nohup .... &" at the end of the script is likely to fail because the script will terminate before nohup(1) has been able to do its work (ignoring SIGHUP and SIGQUIT).

The ps(1) is to make sure that the_process has really started.

If you need more help, then please post your script and the logs.

[Frank Slootweg]

About testing without a reboot, do:

# echo "your_manual_command" | batch

Where "your_manual_command" is the full path/command which you successfully execute from an interactive shell.

Other test:
# your_manual_command
[check if it ran OK and the daemon is running]
# exit
login: ...
...
[check if the daemon is *still* running]

If the daemon *was* running, but no longer *is* running, then it is not a real daemon, i.e. it can not handle that (the shell that executes) the calling script terminates, i.e. you *must* use nohup(1) (see my previous response).

[Mark Landin]

I also ran into this, and as a previous poster indicated, adding a "sleep 10" statement to the startup commands was effective. Some things need more time to 'simmer' before they are done. :)

[Sean OB_1]

This is from another thread, but things to check out:

Typically most machines default to run level three.

So make sure to put a link in /sbin/rc3.d as S999xvfb pointing to /sbin/init.d/xvfb.

cd /sbin/rc3.d
ln -s /sbin/init.d/xvfb S999xvfb
chmod 755 S999xvfb

Check /etc/inittab to see what the default run level it.

Check /etc/rc.log to see what if any error messages happen when the system boots.

Finally I would make sure that /sbin/init.d/xvfb sets any environment variables that you need. There may be vars set when you log in that aren't set at boot time so they aren't available when the command is executed.


Not the last part especially.