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

Description=Starts the DCCA index software


ExecStart=/opt/insiteone/bin/indexControl start
ExecStop=/opt/insiteone/bin/indexControl stop

# Execute pre and post scripts as root

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


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.

  • Thanks, that works great. So if i understood correctly since the shell script "forks" starts other daemon, so you recommended type=forking. I have a question, if u can please help: Once i do service index start it shows loaded active, after that if i manually invoke the script to stop the services, instead of systemd, it shows inactive dead, but is there a way for systemd to show status loaded active if manually started as well using the script? I understand, the reason could be systemd does not know, if the script is accessed, so could be the reason. But any way out? – RajSanpui Jan 6 '16 at 8:41
  • 1
    No, there isn't. If you want systemd to monitor your services, start them via systemd. – user1686 Jan 6 '16 at 8:50

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

Description=Setup foo



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.

  • 1
    Correct answer! – JohnnyFromBF Jan 5 '18 at 11:42
  • 1
    was stuck with same issue, it got resolved because of your feedback, thanks – usetej2 Sep 26 '19 at 4:18

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

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

ExecStart=/etc/init.d/apache2 start
ExecStop=/etc/init.d/apache2 stop


  • Can you please include a source or explain what's in there? – CaldeiraG May 20 '19 at 9:51

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.