We will want our application to be started for all multi-user
run levels and stopped for the halt, single-user and reboot
runlevels. This can be accomplished by changing the current
directory to /etc/init.d
and then, as root, using the update-rc.d
command:
update-rc.d myapp start 20 2 3 4 5 . stop 20 0 1 6 .
|
You should see the following output:
Adding system startup for /etc/init.d/myapp ...
/etc/rc0.d/K20myapp -> ../init.d/myapp
/etc/rc1.d/K20myapp -> ../init.d/myapp
/etc/rc6.d/K20myapp -> ../init.d/myapp
/etc/rc2.d/S20myapp -> ../init.d/myapp
/etc/rc3.d/S20myapp -> ../init.d/myapp
/etc/rc4.d/S20myapp -> ../init.d/myapp
/etc/rc5.d/S20myapp -> ../init.d/myapp
|
The environment while booting is pretty sparse, so any references
which make use of the path or environment variables may fail. To
save yourself some extra reboots to test your install, I would
suggest setting the
wrapper.logfile.loglevel
property to DEBUG now.
You can now reboot your system to test the installation:
When the system comes back up it will hopefully be running. If
there were any problems, then the log file should contain some
clues as to the problem. If the test in the previous section
worked but this failed, then the problem is most likely a
problem with missing enviroment variables.
If your application makes use of other services, MySQL for example,
then you will need to make sure that your application is started
after MySQL, and then shutdown before MySQL. This is done by
controlling the startup/shutdown order. By default, MySQL starts
and stops with an order of 20, so we can get the desired behavior by
using a startup order of 21 and a shutdown order of 19.
update-rc.d myapp start 21 2 3 4 5 . stop 19 0 1 6 .
|
|