I have an application that should be started during boot and terminated gracefully during shutdown. The problem is that I cannot ensure that the application is started/stopped using systemd, it's quite a complex app that might sometimes need to be started "partially" using manual commands so there is therefore no real good way for systemd to keep track of the actual state of the application.

So, I've arrived at the conclusion that I need a "stupid" systemd unit that will simply always run a certain script at startup and another one at shutdown, no matter the state of the service. And this is what I'm having difficulties to accomplish. Here's what I use for testing:

[Unit] Description=My Test application Wants=network-online.target After=network-online.target [Service] Type=oneshot ExecStart=/home/user/tmp/systemd-test/script.sh start ExecStop=/home/user/tmp/systemd-test/script.sh stop RemainAfterExit=true [Install] WantedBy=multi-user.target 

The problem with above is that I cannot make it run "stop" if start hasn't been previously run and the other way around:

$ systemctl start test # Start script is run $ systemctl start test # Nothing happens $ systemctl stop test # Stop script is run $ systemctl stop test # Nothing happens $ systemctl stop test # Nothing happens 

So imagine the start script failing for whatever reason during boot, the app admin going in and starting things manually. Then the stop script will not be run during shutdown because it was never started properly as far as systemd is concerned.

My question is therefore, is there a way to make a "stupid" systemd service that doesn't care about state, or will I have to separate it into two different units?

I have an application that should be started during boot and terminated gracefully during shutdown. The problem is that I cannot ensure that the application is started/stopped using systemd, it's quite a complex app that might sometimes need to be started "partially" using manual commands so there is therefore no real good way for systemd to keep track of the actual state of the application.

So, I've arrived at the conclusion that I need a "stupid" systemd unit that will simply always run a certain script at startup and another one at shutdown, no matter the state of the service. And this is what I'm having difficulties to accomplish. Here's what I use for testing:

[Unit] Description=My Test application Wants=network-online.target After=network-online.target [Service] Type=oneshot ExecStart=/home/user/tmp/systemd-test/script.sh start ExecStop=/home/user/tmp/systemd-test/script.sh stop RemainAfterExit=true [Install] WantedBy=multi-user.target 

The problem with above is that I cannot make it run "stop" if start hasn't been previously run and the other way around:

$ systemctl start test # Start script is run $ systemctl start test # Nothing happens $ systemctl stop test # Stop script is run $ systemctl stop test # Nothing happens $ systemctl stop test # Nothing happens 

So imagine the start script failing for whatever reason during boot, the app admin going in and starting things manually. Then the stop script will not be run during shutdown because it was never started properly as far as systemd is concerned.

My question is therefore, is there a way to make a "stupid" systemd service that doesn't care about state, or will I have to separate it into two different units?

Edit: To explain a bit more why I cannot really use systemd state as intended: Starting the application first involves starting a "server" process, and once that is up and running to start a "launcher" process that in turn spins up ~20 different processes for different types of processing. And everything is started asynchronously (i.e. non-blocking) with no way to know when things are actually up except for grepping the logs or invoking a custom binary for listing processes. So there is really no way for systemd to find out if one of these 20 processess failed to start.