Auto-Start on server reboot
If this option is enabled the service will be started on server reboot.
Clean work directory on service start
If this option is enabled the default start script will remove default/work/*
Remove old logs on service start
If this option is enabled the default start script will remove default/logs/*
Service actions
Start
The START action attempts to start the service.
SystemD waits for a READY notification in order to consider the service started.
The default WatchDog configuration sends the READY signal when the landing pages of all the configured domains start to return non-error HTTP status codes.
See the rest of this documentation for ways to override the WatchDog behavior.
The START action executes my_appserv/bin/start . It can be changed to fit your service needs. Search for "bin/start" in this doc for more info.
See Limits for Start/Stop timeouts.
Stop
The STOP action attempts to stop the service gracefully. It waits for the main process of the service to exit.
In case that the stop command timeouts SystemD sends TERM & CONT signals to all the processes in the service group.
If there are remaining processes after the TERM signal the processes are killed with KILL & CONT signals . The KILL signal is non maskable and the Linux Kernel terminates processes which receive it. There are some very specific cases in which blocked processes can not be killed even with a KILL signal.
The STOP action executes my_appserv/bin/stop . It can be changed to fit your service needs. Search for "bin/stop" in this doc for more info.
See Limits for Start/Stop timeouts.
Restart
RESTART does a STOP followed by a START, so the descriptions of those two apply.
Reload
RELOAD usually does a configuration reload without restarting the whole daemon process.
This action is not implemented in the default scripts since Tomcat does not support a reload operation. So it is normal to fail if you execute it.
If your custom application server supports the reload operation you can create a bin/reload script which will be executed when this action is triggered. It is up-to you to decide what to do with this action.
Send SIGTERM / SIGKILL
Those allow to send the signals to all the processes in the service group. Those signals usually TERMinate or KILL the service.
Normally, those two actions should not be used.
Note that SystemD will restart the service if you kill it with one of those signals while it was in active state.
Service initialization
This action creates the my_appserv directory structure when it is missing. The directory structure will be initialized with the chosen Application server and JVM versions .
My App Server domains
A domain/subdomains can have My App Server support activated/deactivated if it:
- has its web hosting enabled
- is active, e.g. it is not suspended or disabled
This active/disabled state is used in the default configuration:
- by the
bin/startscript to generate the needed configuration files - by the WatchDog to monitor the landing pages of the active domains
If you run a customized version of an application server or have modified the default start/stop/watchdog scripts you are free to ignore the activation status. E.g. you can have a default catchall VHost configured on the backend.