Services declared as oneshot
are expected to take some action and exit immediatelly (thus, they are not really services,
no running processes remain). A common pattern for these type of service is to be defined by a setup and a teardown action.
Let's create a example foo
service that when started creates a file, and when stopped it deletes it.
Create executable file /opt/foo/setup-foo.sh
:
#!/bin/bash
echo "Setting up foo ..."
touch /tmp/foo-activated
Create executable file /opt/foo/teardown-foo.sh
:
#!/bin/bash
echo "Tearing down foo ..."
if [ -f /tmp/foo-activated ]; then
rm /tmp/foo-activated
else
echo "Doesnt seem to be up: Skipping ..."
fi
Now, we define the systemd unit file as /etc/systemd/system/foo.service
. Note that we must specify RemainAfterExit=true
so that systemd considers the service as active after the setup action is successfully finished.
[Unit]
Description=Setup foo
#After=network.target
[Service]
Type=oneshot
ExecStart=/opt/foo/setup-foo.sh
RemainAfterExit=true
ExecStop=/opt/foo/teardown-foo.sh
StandardOutput=journal
[Install]
WantedBy=multi-user.target
Reload the systemd daemon and start the service as normally (systemctl start foo.service
). Check the status to verify that the correct actions are taking place.
Du you have an idea for processes like rsync in a script?
I have a backup-script, where several rsync-processes are startet to sync different home-directories, /opt, /usr/local...
When script starts the first rsync-process, it will fork an systemd stops the whole unit. My backup does not get finished.
Only RemailAfterExit=true can solve the problem in combination with Type=oneshot.
But in combinstion with systemd-timer, which starts the backup-serviice every day, it will not start backup.service on the next day, because the service is active in case of RemainAfterExit=true...
systemd.timer manpage say:
"Note that in case the unit to activate is already active at the time the timer elapses it is not restarted, but simply left running. There is no concept of spawning new service instances in this case. Due to this, services with RemainAfterExit= set (which stay around continuously even after the service's main process exited) are usually not suitable for activation via repetitive timers, as they will only be activated once, and then stay around forever."