The first step in setting up the application so that it will shutdown cleanly when the system shuts down 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 symbolic 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 a "root" user. 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 user as this will be the case when the application is started on system startup. It is fairly common for there 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.

You will want your 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 executing the update-rc.d command as a root user:

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, when you try to reboot in order 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.

Problems?

If you encounter any problems, then please check the log file, which 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 environment variables.

Controlling the Order:

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 of your application by using the startup order of 21 and the 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