systemd call bash script to create a symlink before daemon process

Question

Before a daemon process is to be executed by systemd, I need to create or change the destination of a symlink. The daemon process redirects its standard output to this symlink and therewith into a special file for each started daemon process. That is the idea. I set up the service unit file named "test_start.service":

[Unit]
Description=Test Server
After=network-online.target test_start.socket
Requires=network-online.target test_start.socket

[Service]
User=test1
Group=test1
Type=simple
ExecStartPre=/bin/bash /etc/testServer/Debug/makeOutfile.sh
ExecStart=/etc/testServer/Debug/testServer
StandardInput=socket
StandardOutput=file:/etc/testServer/Debug/test_outLink
Restart=on-failure
RestartSec=3

[Install] 
WantedBy=multi-user.target

The bash script "/etc/testServer/Debug/makeOutfile.sh" looks like this:

#!/usr/bin/env bash
timeStamp=$(date +%y-%m-%d_%Hh%Mm%Ss)
myfolder="/etc/testServer/Debug"
# create new logfile
touch $myfolder/started_$timeStamp
# remove old symlink if exists (owned by test1)
if [ -h $myfolder/test_outLink ]; then
    rm $myfolder/test_outLink
fi
# create new symlink
ln -s $myfolder/started_$timeStamp $myfolder/test_outLink

It works under certain circumstances. If a symlink exists and if the file it points to also exists, everything is just fine. The bash script "makeOutfile.sh" works via terminal for testing purposes and via a systemd service start.

But:

If the file pointed to (name: "started_atSomeDate") does not exist (because it got removed by someone meanwhile), a terminal call of the script works as expected, but starting the systemd service will add an additional file owned by root with group root with the original old file name: "started_atSomeDate".

Where does that come from?

If the old symlink "test_outLink" does not exist (because it got removed by someone meanwhile), a terminal call of the script works as expected, but starting the systemd service will add the newly created "test_outLink" as a regular file owned by root with group root and the service does not start.

Something goes terribly wrong here and although the systemd service unit User and Group is test1, root gets mixed in here. Can anybody explain? What am I doing wrong?

Answer 1

My suggestion is that you should use a shell script that will both set up the log file and execute the test server with an appropriate redirection, therefore bypassing the systemd StandardOutput= setup that doesn't work for your case.

Create a bash script /etc/testServer/Debug/runTestServer.sh like this:

#!/usr/bin/env bash
timeStamp=$(date +%y-%m-%d_%Hh%Mm%Ss)
myfolder="/etc/testServer/Debug"
# create new logfile
touch $myfolder/started_$timeStamp
# remove old symlink if exists (owned by test1)
if [ -h $myfolder/test_outLink ]; then
    rm $myfolder/test_outLink
fi
# create new symlink
ln -s $myfolder/started_$timeStamp $myfolder/test_outLink
# run the actual testServer
exec /etc/testServer/Debug/testServer >/etc/testServer/Debug/test_outLink

The only difference from your original makeOutfile.sh script is that this script executes the testServer with an appropriate redirection to send its stdout to the log file you just set up.

It also uses exec to ensure the shell script is not kept around and replaced by the testServer (so systemd will know what is the main process of the service.)

In your unit file, remove the ExecStartPre= and the StandardOutput= and replace the ExecStart= with:

ExecStart=/etc/testServer/Debug/runTestServer.sh

(Or calling the script with /bin/bash is also possible, although not necessary as long as the script has the executable bit set.)

By setting up your server through a script like this, you can even bypass the symlink altogether and do the redirection directly to the final started_$timeStamp log file.

I haven't looked at the systemd code directly and the documentation isn't clear on the interactions between StandardOutput= and ExecStartPre= in specific... But there's definitely an issue with the order in which the steps are executed by systemd (and which process executes them, which results in different permissions/ownership), so I'm not too surprised with the results you reported. I guess, regardless, my recommendation would be to simplify it with the single wrapper executor script, so hopefully that solves your problem.