Automatically enable systemd services installed using deb?

Question

I'm building a bunch of services to install on my own (automatically created) servers. I'm migrating from upstart on Ubuntu 14.04, where services are enabled by default (we have to do extra work if we don't want then to start when installed), to Ubuntu 16.04 where we want to use systemd as the new native service framework.

The services are installed using deb packages that I'm creating myself. I've upgraded the deb creation by adding --with systemd to rules and adding a package-name.service with a systemd unit specification.

The problem I found is that even if I add an [Install] section with WantedBy=multi-user.target, the service will not be started on the system.

Instead, the service gets installed and then systemctl status package-name shows:

● package-name.service - My Service
   Loaded: loaded (/lib/systemd/system/package-name.service; disabled; vendor preset: enabled)
   Active: inactive (dead)

I don't have any systemd overrides in my rules, which as I've understood from the Debian packaging with systemd page as well as the dh_systemd_enable man page I can use to not enable services if I choose not to.

Also from the looks of the status display it appears that dh-systemd did enable the services (the vendor preset bit), but that was not enough. What am I missing?

Answer 1

Actually, you don't need to add anything in override_dh_auto_install.

You need --with systemd (without the dash between with and systemd) in the rules and the package dh-systemd installed.

Answer 2

I've worked around the problem by calling dh_systemd_enable (to make the service run by default) and dh_systemd_start (to actually start it after installation) manually from the override_dh_auto_install target in rules, so it looks like this:

%:
    dh $@ --with-systemd

override_dh_auto_install:
    dh_auto_install
    dh_systemd_enable || true
    dh_systemd_start || true

Answer 3

I ran into this issue as well. It turns out that dh_systemd_enable has certain expectations about the content of a foo.service file.

You can see this in lines 187-215 of deb-systemd-helper.

In particular, ensuring that the foo.service file has an [Install] section and has at least an Alias field where the alias does NOT equal foo.service will cause the call to deb-systemd-helper enable to detect the needed service. If you want the service to be automatically started adding WantedBy=multi-user.target is also needed.

Below is a lightly modified version of my foo.service file:

[Unit]
Description=foo service, foos
After=bar.service
Requires=bar.service

[Service]
ExecStart=/path/to/my/script/foo
Restart=always
RestartSec=5

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

I was able to determine this by enabling a couple debug flags and adding debug statements in the deb-systemd-helper perl script. On an Ubuntu 16.04 system I found it here: /usr/bin/deb-systemd-helper.

So repeatedly running the following and adding debug statements got me to the bottom of the problem.

$ sudo DPKG_MAINTSCRIPT_PACKAGE=1 _DEB_SYSTEMD_HELPER_DEBUG=1 deb-systemd-helper enable foo.service

Answer 4

I just hit this issue, even though I had the required [Install] section, it still wouldn't enable the unit by default.

The solution was to convert the Windows endlines of the .service file to UNIX ones:

dos2unix my.service