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

When you run as root, you are running under the full root environment, which in your case, includes the JAVA_HOME environment variable. The problem is that at the point that the init scripts are run, that environment is not yet set up. This is not really a problem with the Wrapper script, but rather an artifact of the way the system is set up.

To make this work reliably, you need to make sure the JAVA_HOME environment variable is always defined. One way of doing this is to put the variables in the script as you mentioned.

The way I would suggest is to define it in the wrapper.conf file as follows:
set.JAVA_HOME=/usr/share/java

Then rather than using the PATH to locate java, set it absolutely as follows:
wrapper.java.command=%JAVA_HOME%/bin/java

As an option, if you want to use the system JAVA_HOME value, but simply define a default value in case it is not set, you can do so as follows:
set.default.JAVA_HOME=/usr/share/java

This will only set the JAVA_HOME variable if it is not already set.

I'm not sure what I did wrong, but when I rebooted, the wrapper could not locate java at boot time. Instead of making a symlink in /etc/init.d to my start script, I have to make a script like this (replace the paths as appropriate for your environment):

#! /bin/sh

export JAVA_HOME=/usr/share/java
export PATH=$PATH:$JAVA_HOME/bin
/usr/share/myapp/bin/myapp $1

To set the app to run on reboot, you can simply do this:

update-rc.d myapp defaults

I don't believe you have to do this:

update-rc.d myapp start 20 2 3 4 5 . stop 20 0 1 6 .