12

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?

Improve this question
4
  • 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, but I still don't understand why it doesn't get called automatically - as promised in its documentation.
    – Guss
    Commented Apr 6, 2016 at 11:51
  • I haven't worked with .deb packages, but I have worked with custom .rpm packages that I wanted to enable a service for. With rpms there's a post section, which will just run the commands in it after install is finished. That's where I threw in a systemctl enable. I assume .deb has something similar.
    – Centimane
    Commented Jul 5, 2017 at 12:58
  • dpkg has a somewhat more sophisticated (complicated, some may say) way to handle such actions - though you can always just right a trigger script in like in RPM. My comment above was about using this setup - the dh_auto_install step gets translated by dpkg-build into a trigger script. My question is more about how to setup SystemD so it enables and starts "vendor enabled" services automatically. For now I'll just post that comment as an answer and approve that :-)
    – Guss
    Commented Jul 5, 2017 at 14:05
  • 2
    You need 3 things: rules to contain dh $@ --with systemd, control to contain Build-Depends: dh-systemd, postinst to contain #DEBHELPER# and a reasonable current build system
    – Tino
    Commented Oct 1, 2018 at 13:40

4 Answers 4

Reset to default
8

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.

Improve this answer
4
  • This is the correct answer.
    – Tino
    Commented Oct 1, 2018 at 13:35
  • 2
    Unfortunately, this isn't an answer to my issue - I've done that but the result is that the service is in installed but not enabled and not running. Overriding dh_auto_install to call dh_sysyemd_enable and dh_systemd_start is the best way I could find except writing a postinst script manually.
    – Guss
    Commented Oct 1, 2018 at 15:02
  • 1
    --with systemd is enabled by default in compat modes 10+ manpages.debian.org/testing/debhelper/debhelper.7.en.html
    – Greg B
    Commented Mar 4, 2021 at 18:11
  • 1
    It just doesn't work in version 12 (status shows Active: inactive (dead) after installation)
    – Mariusz Jaskółka
    Commented Mar 28, 2022 at 10:48
5

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
Improve this answer
2
4

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

Improve this answer
3
  • 1
    It looks like the Alias line causes deb-systemd-helper to create a link to /etc/systemd/system - which is not necessarily what I want. Can you show what you have in rules other than %: dh $@ --with-systemd to get your service auto-enabled and started?
    – Guss
    Commented Nov 5, 2018 at 17:30
  • Why don't you want a link in /etc/systemd/system? I believe this is core to the mechanism of enabling a systemd unit. e.g. $ sudo systemctl disable <redacted> Removed symlink /etc/systemd/system/multi-user.target.wants/<redacted>. $ sudo systemctl enable <redacted> Created symlink from /etc/systemd/system/multi- user.target.wants/<redacted> to /lib/systemd/system/<redacted>.
    – Gabriel
    Commented Nov 6, 2018 at 20:16
  • 1
    I definitely want a link to /etc/systemd/system/multi-user.target.wants, but I definitely do not want a link in /etc/systemd/system - that directory is saved for user managed scripts - for example I have an apache2 service running on my machine by default, it does not have a link in /etc/systemd/system. Setting Alias=foo.service will cause deb-systemd-helper to create an alias to my service by adding a link from /etc/systemd/system to the real service file - like the ssh.service on my Ubuntu box has an alias sshd.service so I can use both names. This shouldn't be a requirement.
    – Guss
    Commented Nov 8, 2018 at 8:32
1

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

Improve this answer
2
  • Never use "windows new lines" in Linux system files - it breaks almost everything.
    – Guss
    Commented Apr 3 at 11:14
  • Of course. Still, this is something to lookout for that you can easily forget to doublecheck, and this in particular causes the .service file not to get enabled automatically.
    – Giedrius
    Commented Apr 3 at 13:24

You must log in to answer this question.

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