Consider this scenario: Systemd Type=forking service starts one shell script, which in turn starts another script and exits, which will then start the actual service/daemon process.

Now systemd will consider the service started as soon as the first shell script exits and either consider the second shell script to be the service or look for the PID file if that was mentioned in the service file. My dilemma is that the first script exits before the PID file was created by the second script and the second script exits about half a minute later when the actual service process is finally started.

While I could merge those chained startup scripts in theory, these are shipping with the service I'm creating the systemd service file for and I would rather not mingle with that in order to keep it easily updateable.

So basically the question is: How do I handle chained forking processes in a systemd service so that only the last fork in the chain is considered/monitored by systemd?

For reference: The software causing this problem is the newest version of TeamCity, the CI server by JetBrains.

As I know StackExchange people like code samples here we go with a simplified nonsense version: teamcity-server.service (Systemd Service file):

Description=TeamCity server

ExecStart=/opt/teamcity/bin/teamcity-server.sh start
ExecStop=/opt/teamcity/bin/teamcity-server.sh stop


teamcity-server.sh (this is no real script, just showing how the chained script is executed):

sh "script2.sh" "run" "$@" &
wait $!

script2.sh (this isn't a real script either, just showing how we launch the java daemon here):

PIDFILE = "/opt/teamcity/logs/teamcity.pid"
java -jar somejavadaemon.jar
echo $tc_pid > $PIDFILE


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.