The first step in setting up the application so that it will shutdown cleanly when the system shutsdown and then starts up in the correct order when the system boots is to create a symbolic link to the applications script within the /etc/init.d directory. Many applications simply copy their daemon script to this directory but the Wrapper's scripts require that a symolic link is used so that the location of the rest of the application's files can be located without modification to the script.

To create a symbol link in the /etc/init.d, you must be root. Simply enter the following sequence of commands:

ln -s /usr/lib/myapp/bin/myapp /etc/init.d/myapp

Now verify that the symbolic link is working correctly by changing the current directory to /etc/init.d and executing the following command.

./myapp console

Make sure to run as root as this will be the case when the application is started on system startup. It is fairly common for their to be differences in the environment between the root user and the user you are normally logged in as. These differences can cause problems like not being able to locate the JVM for example.

The application should start normally. Press CTRL-C to stop the application.

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:

shutdown -r now

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 .

To unregister the run levels registered in the previous section, execute the following command.

update-rc.d -f myapp remove