Ubuntu – Automatically enable systemd services installed using deb

debservicessystemdUbuntu

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?

Best Answer

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.

Related Solutions

Linux – systemd: How to unmask a service whose unit file is empty

A service unit that is empty (0 bytes) will be parsed by systemd as masked. While systemctl mask <unit> works by symlinking the service to /dev/null, systemd appears to just check if a file is 0 bytes when read to determine if a unit is masked. This results in the misleading message about a masked service.
You need to figure out why the service unit is empty.

As to how to unmask a service whose unit file is empty... You "unmask" the service by making the unit non-empty, which is going to be dependent on why the unit is empty.

Init service failing to enable once a systemd service file is generated

I've now found that the issue was that the service file automatically generated by systemd-sysv-generator lacks an install section with a WantedBy option. I added the following to my generated file at /etc/systemd/system/programexample.service which allowed me to properly enable the service:

[Install]
WantedBy = multi-user.target

After that I ran

systemctl daemon-reload

to ensure my service file was read by systemd.

Now I received a proper notification that my service was actually symlinked somewhere to be "enabled":

[root@centos7-box ~]# systemctl enable programexample.service
Created symlink from /etc/systemd/system/multi-user.target.wants/programexample.service to /etc/systemd/system/programexample.service.

This link helped me better understand the service file.

I am not a fan of the way that systemd-sysv-generator does not include an install section with a WantedBy option by default. If systemd can dynamically read the LSB headers and properly start services at boot, why doesn't it generate the service file accordingly? I suppose some systemd growing pains are to be expected.

Update July 7 2020:

Working with Debian Buster and trying to enable a SysVInit legacy service, I was presented with this wonderful message, which I believe would have saved me some time when I dealt with this issue in 2017:

Synchronizing state of programexample.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable programexample
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template units). This means they are not meant to be enabled using systemctl. 
Possible reasons for having this kind of units are:

• A unit may be statically enabled by being symlinked from another unit's
  .wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
  a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
  D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
  instance name specified.

Best Answer

Related Solutions

Linux – systemd: How to unmask a service whose unit file is empty

Init service failing to enable once a systemd service file is generated

Related Question