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):
[Unit]
Description=TeamCity server
After=network.target
[Service]
EnvironmentFile=/etc/conf.d/teamcity
ExecStart=/opt/teamcity/bin/teamcity-server.sh start
ExecStop=/opt/teamcity/bin/teamcity-server.sh stop
Type=forking
PIDFile=/opt/teamcity/logs/teamcity.pid
Restart=no
TimeoutSec=30
RemainAfterExit=yes
User=teamcity
[Install]
WantedBy=multi-user.target
teamcity-server.sh (this is no real script, just showing how the chained script is executed):
#!/bin/sh
sh "script2.sh" "run" "$@" &
wait $!
EXIT_CODE=$?
exit $EXIT_CODE
script2.sh (this isn't a real script either, just showing how we launch the java daemon here):
#!/bin/sh
PIDFILE = "/opt/teamcity/logs/teamcity.pid"
java -jar somejavadaemon.jar
tc_pid=$?
echo $tc_pid > $PIDFILE
