I've created a deb package which installs a service.

On our embedded devices, I want this package to automatically enable the service. On our developer workstations, I want the developers to systemctl start foo manually (it's a heavy service, and so it just consumes resources if run all of the time on a desktop environment).

How can I go about prompting the user for their decision during the apt-get step? Is that the best solution?

Note, I've created the package using dh_make and debhelper and enabled it with:

    dh $@ --with=systemd

    dh_systemd_enable --name=foo foo.service

You can use systemd presets to affect whether a systemd service will default to being enabled or disabled at installation time.

The Debian presets default to enabling all services as they're installed, so you only need to ship a preset to the development workstations (the default behavior matches what you want to happen in production), by shipping a file such as /etc/systemd/system-preset/80-foo.preset containing a line that says

disable foo.service

If you manage your developer workstations using a system such as Puppet, Chef, Ansible, etc., you can use them to ship such a systemd preset configuration, that should make it easy for you to apply the policy to developer workstations only and not production machines.

Your .deb package should use the systemctl preset command to enable the service, since that command will respect the preset configuration.

As @JdeBP and @sourcejedi point out, the Debian macros in deb-helpers (such as dh_systemd_enable) do that already, they invoke deb-systemd-helper which will use systemctl preset by default (with a small caveat that if you remove (but do not purge) the package, and later re-install it, it will then not enable the service, even if you remove the preset file.) See this comment in deb-systemd-helper's enable operation:

    # We use 'systemctl preset' on the initial installation only.
    # On upgrade, we manually add the missing symlinks only if the
    # service already has some links installed. Using 'systemctl
    # preset' allows administrators and downstreams to alter the
    # enable policy using systemd-native tools.

For more information on the systemd feature of presets, see the man page of systemd presets and of the command systemctl preset which implements it.

  • 1
    This is exactly what I needed. I deploy the dev environment through a meta-package and so I can install these *.preset files as part of that package. – Stewart Nov 12 '18 at 11:52
  • 4
    An important quirk to know is that presets are only consulted by deb-systemd-helper the first time that a package is installed. After that, the parallel database maintained by the Debian tools is consulted instead, until the package is purged. news.ycombinator.com/item?id=18320131 – JdeBP Nov 12 '18 at 11:53
  • 1
    So deb-systemd-helper appears to use presets. And this should work without needing a manual systemctl preset command inside the .deb package. The Debian-specific quirk is what happens if you remove (but do not purge) the package. If you later re-install the package, it will then not enable the service, even if you remove the preset file. salsa.debian.org/debian/init-system-helpers/blob/debian/1.56/… – sourcejedi Nov 26 '18 at 11:21
  • @sourcejedi Incorporated your comments and link to deb-systemd-helper comment into the answer. Thanks! – filbranden Nov 27 '18 at 3:13

If you want to prompt the user during installation, you should use debconf. This has a number of advantages, even if you’re not in a context where Debian Policy is relevant: it provides a consistent end-user experience, with support for a variety of frontends; it supports different “levels”; it supports pre-seeding. Pre-seeding means that the package can be pre-configured, in which case it won’t prompt at all. The different levels mean that a prompt can be set up to only show in certain circumstances; you could then have the package install without prompting by default (for your embedded targets), and instruct your developers to set up their frontend appropriately when installing the package so that they see the prompt.

However, I think it’s better to avoid prompting altogether when possible. This is especially true for services which have other ways of dealing with end-user preferences, and where dealing with user preferences complicates the maintainer scripts (see the generated scripts in your package, they already deal with a number of subtle issues, using deb-systemd-helper — you’d have to replicate all that, with your preference handling on top).

If your developers never need to run the service, they can mask it before installing the package, and the service will never be enabled:

sudo systemctl mask foo

If your developers sometimes need to run the service, using the systemd unit, they can disable it after installing the package for the first time, and subsequent installs will remember this:

sudo apt install foo
sudo systemctl disable --now foo

The default would then be to enable the service.

  • Good answer. debconf looks like what I had in mind, but I agree that it's best to avoid prompting when possible. I knew about the systemctl disable, but I was trying to help the user to avoid "skipping a step" during installation. The *.presets solution suggested by Filippe solves this. – Stewart Nov 12 '18 at 11:56
  • Indeed, presets fit the bill perfectly! – Stephen Kitt Nov 12 '18 at 12:01

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.