I am completely new to the linux world, so sorry for anything wrong I might say.

I am trying to run a Mongo DB on a Debian 8.5 machine. When I installed the package (pre built from percona.com), I have noticed the following files:

/etc/init.d/mongod (1)
/lib/systemd/system/mongod.service (2)

About /etc/init.d/mongod

I understand that this is called (as long as it is registered via update-rc.d) at boot / in other particular system states (don’t want to get technical on this, I’m absorbing lots of informations and this seems less important).

This is perfectly fine for me. The script does lots of initialization and finally launches the mongo daemon. It seems to have “triggers” for start, stop, restart, etc and as far as I understand I can trigger those with sudo service mongod <action>.

About /lib/systemd/system/mongod.service

This file seems to do the same thing (i.e. run mongo), but with less configuration, just one line in the ExecStart parameter:

Description=MongoDB (High-performance, schema-free document-oriented database)
After=time-sync.target network.target
ExecStart=/usr/bin/env bash -c "/usr/bin/mongod $OPTIONS > ${STDOUT} 2> ${STDERR}"

As far as I understand this can be triggered with sudo systemctl start mongod.

  • I don’t understand if this is called at boot or not.

  • I don’t understand why the need for two of these ‘service’ files, and how can I get rid of one (possibly the one in /lib/systemd, since it is much simpler).

  • I don’t understand if there’s any relation between the two.

  • I have read that systemctl works on init.d scripts too, and in this case I don’t understand which of the two files will be triggered by systemctl mongod start.

I think there’s some redundancy and I should choose just one of the two ways. And I want to be sure that it is

  • called at boot
  • callable by command (like service or systemctl).

Could you help me clear my mind? With the help of some comments I can probably focus and narrow down the question.


When you have both an init.d script, and a systemd .service file with the same name, systemd will use the service file for all operations. I believe the service command will just redirect to systemd. The init.d script will be ignored.

Use systemd. It's new in Debian 8, but it's the default. Systemd service files are supposed to look simpler than init.d scripts. You didn't mention any specific feature you need that's not supported by the systemd service.

If the service file was not included, systemd would happily use the init.d script. So the mongod package developer is telling you they think this systemd definition is better :).

Look at the output of systemctl status mongod. If the service is enabled to be started at boot time, the Loaded: line will show "enabled". Otherwise you can use systemctl enable mongod. You can also include the option --now, and it will start mongod at the same time.

  • Thank you! I am going to study systemd and eventually use it. For now I wanted to disable that and finally run the init.d script I’ve been working on. I went: systemctl disable mongod; then renamed mongod.service to mongod-backup.service; then systemctl daemon-reload. Do you think this was correct? I have read you should not modify files in /lib/systemd/system/, but without renaming, systemctl kept ignoring the init.d script. – natario Sep 3 '16 at 9:32
  • The files in /lib/systemd are not conffiles. I really can't recommend installing a debian package and modifying its files (and later updating the package). Instead, you should rename the init.d script you've been "working" on (presumably modifying?). init.d scripts tend to be conffiles. If an update changes a conffile (which there shouldn't be any reason for), it will warn you first. In this case I would expect it to notify you if an updated version of the original, (effectively) deleted init.d script ever became available. – sourcejedi Sep 3 '16 at 10:53
  • It's possible you would need to add ordering dependencies on your new service, to the services which depended on mongod. There's also a chance you will have to remove some strict dependencies, but I wouldn't have thought so. A safe way to modify the affected services is to copy them to /etc/systemd/system/ and modify the copy. – sourcejedi Sep 3 '16 at 10:55
  • In general, I think sticking with systemd is simpler. You're now studying bash, init-functions, and systemd's back-compat features. Since you're not learning a pure SysV init system, if you ever do use such a system, there's a risk you'll expect features that actually come from systemd. – sourcejedi Sep 3 '16 at 11:11

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.