5

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?

  • 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 Apr 6 '16 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 Jul 5 '17 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 Jul 5 '17 at 14:05
  • 1
    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 Oct 1 '18 at 13:40
6

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.

  • This is the correct answer. – Tino Oct 1 '18 at 13:35
  • 1
    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 Oct 1 '18 at 15:02
3

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
  • 2
    For me, with the --with-systemd the default has always been to enable + start anyway, so you should not have to do it manually. sduthil answer's makes more sense. However, your postinst script may be missing the #DEBHELPER# (See unix.stackexchange.com/questions/423069/…) – Alexis Wilke Aug 14 '18 at 4:11
0

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

  • 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 Nov 5 '18 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 Nov 6 '18 at 20:16
  • 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 Nov 8 '18 at 8:32

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.