Why is systemd stopping service immediately after it is started?

Question

I created a systemd service which should invoke a shell script, when started or on reboot.

[Unit]
Description=Starts the DCCA index software

[Install]
WantedBy=multi-user.target

[Service]
ExecStart=/opt/insiteone/bin/indexControl start
ExecStop=/opt/insiteone/bin/indexControl stop

# Execute pre and post scripts as root
#PermissionsStartOnly=true
Restart=on-abort
TimeoutSec=600

Initially it kept on restarting in infinite loop as soon as it is started, but when I added the TimeoutSec option, it called the ExecStop as soon as the service was started for the first time (started, and then stopped again immediately).

Any clue, where I am going wrong?

P.S.: indexControl is a shell script, which starts other processes

Answer 1

You didn't tell systemd what kind of daemon this is and what to expect from it (most importantly, it needs to how to know when the daemon has finally started).

The default is Type=simple, which means the first process is considered the main service process. The moment it starts, the entire service is considered "active (started)"; the moment it exits, the entire service gets stopped.

The other common mode is Type=forking, where the initial process is expected to fork at least once and exit, leaving a child running "in background" or "daemonized" as some call it.

But if you're going through a "whateverctl" tool, you're always going to see the behavior that needs Type=forking, since the tool itself will try to start the daemon "in background" and exit itself.

Answer 2

None of the above and similar SO answers worked for me. But this post eventually did.

[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

What did the trick was the RemainAfterExit=true directive. That's because my script didn't leave any trace of itself for systemd to look at, so next systemd step was always to call ExecStop to stop "this strange script that doesn't leave a daemon behind". Moot but true.

UPDATE 20180316: Ok, I totally forgot everything about systemd services in these few months, so I was re-doing all the work from scratch. Fortunately I vaguely remembered about this answer, passed half an hour looking for it and now I'm here again.

I'll try to add just a couple of things I've re-learned this time: systemd scripts must not be placed in /etc/init, they stay in the more hideous /etc/systemd/system directory, and they're called .service, not .conf!

After the script is in the correct directory, a sudo systemctl daemon-reload is desirable, but won't make the script name appear in sudo service [TAB] autocomplete list. Nevertheless, the new service can be launched with:

sudo service myservice start

And that's it, now the service is doing what has been written for. For sure the called script won't, but this is another problem.

Answer 3

Keep Type=forking and give a pid file location if your start service/app is maintaining any pid.

[Unit]
Description="Run app on boot"
After=network.target syslog.target auditd.service

[Service]
Type=forking
PIDFile=/var/run/apache2/apache2.pid
ExecStart=/etc/init.d/apache2 start
ExecStop=/etc/init.d/apache2 stop
StandardOutput=syslog
StandardError=syslog
Restart=on-failure
SyslogIdentifier=webappslog

[Install]
WantedBy=multi-user.target
Alias=webapps