20

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

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

I understand that /etc/init.d/mongod is called at boot, or in other particular system states, as long as it is registered via update-rc.d. This is perfectly fine for me. The script initializes and 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>.

/lib/systemd/system/mongod.service seems to do the same thing (i.e. run mongo), but with less configuration - just one line in the ExecStart parameter:

[Unit]
Description=MongoDB (High-performance, schema-free document-oriented database)
After=time-sync.target network.target
[Service]
Type=forking
User=mongod
Group=mongod
PermissionsStartOnly=true
EnvironmentFile=/etc/default/mongod
ExecStart=/usr/bin/env bash -c "/usr/bin/mongod $OPTIONS > ${STDOUT} 2> ${STDERR}"
PIDFile=/var/run/mongod.pid
[Install]
WantedBy=multi-user.target

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

  • I don’t understand if 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?

Improve this question

1 Answer 1

Reset to default
14

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.

Improve this answer
4
  • 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
    Commented Sep 3, 2016 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
    Commented Sep 3, 2016 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
    Commented Sep 3, 2016 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
    Commented Sep 3, 2016 at 11:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .