13

Debian packages usually start services right after installing them. This is a well-known phenomenon, given tens of webpages explaining how to disable this behavior. As far as I remember, this has been in place before systemd has been adopted.

My question is, is it an official policy? Has this rule been written down anywhere? I've tried looking for it in the Debian Policy, but couldn't find relevant notes.

liori
  • 630

1 Answers1

18

This is addressed in the “Managing the links” section of Policy, which described how links to services should be handled:

The default behaviour is to enable autostarting your package’s daemon.

Here I’m reading “autostarting” in a wide sense; technically since this section of Policy only deals with “links”, i.e., configuring services to start at boot, it could be read as only requiring this, but that would lead to inconsistent system states (i.e. a service installed but not started until the next boot). The recommendations in this section and the next one:

It is easiest for packages not to call update-rc.d directly, but instead use debhelper programs that add the required update-rc.d calls automatically. See dh_installinit, dh_installsystemd, etc.

It is easiest for packages not to call invoke-rc.d directly, but instead use debhelper programs that add the required invoke-rc.d calls automatically. See dh_installinit, dh_installsystemd, etc.

result in services which, by default, are enabled and started immediately.

Other sections of Policy assume this, or at least result from a requirement to support this; thus in the section on configuration files:

The scripts are not required to configure every possible option for the package, but only those necessary to get the package running on a given system. Ideally the sysadmin should not have to do any configuration other than that done (semi-)automatically by the postinst script.

If necessary though, Policy allows the opposite behaviour:

If, however, the daemon should not be autostarted unless the local administrator has explicitly requested this, instead add to your postinst script:

update-rc.d package defaults-disabled

The defaults can also be configured locally; for example debootstrap-style chroots are often set up to skip running services.

This section of Policy needs to be updated for systemd, but the general principle still applies.

Stephen Kitt
  • 434,908
  • Thank you! I was looking for it in the sections about services. Somehow missed that init systems is exactly what I should be checking… – liori Oct 13 '20 at 14:59
  • 3
    One day I would love to find out exactly why this policy came about. It seems quite dangerous to me. – Michael Hampton Oct 14 '20 at 02:10
  • @MichaelHampton Service will attempt o start on start on system reset. If it was not started before, this will lead to an unattended system state change, which is by far more dangerous than an interactive one. – Basilevs Oct 14 '20 at 04:39
  • 1
    @Basilevs not necessarily: if a service is installed but not enabled, it won’t try to start at boot. – Stephen Kitt Oct 14 '20 at 04:41
  • @StephenKitt we are talking about default configuration – Basilevs Oct 14 '20 at 05:49
  • 1
    @Basilevs right, and the default is “service starts immediately and when the system boots”. The opposite of that isn’t “service doesn’t start immediately but starts when the system boots”, it’s “service never starts automatically”. But your comment is a good argument in favour of starting the service immediately if it is enabled (so in systemd terms, always using enable --now). – Stephen Kitt Oct 14 '20 at 06:06
  • 4
    @MichaelHampton, back when that policy was written, people would only install the services they needed. That desktop environments pull in everything in case the user might want it is a more recent development. – Simon Richter Oct 14 '20 at 08:17
  • @SimonRichter And suppose I want to configure a service before starting it? This not only happens today, it was also a thing back in the prehistoric times. Today I'll have a firewall going, but for much of the 90s there was no such thing. – Michael Hampton Oct 14 '20 at 15:56
  • @MichaelHampton, we had firewalls in the 90ies, and if you had a public IP you generally also configured it properly. Also, we shipped rather conservative default configurations (e.g. ISC DHCPd runs, but doesn't answer any requests), and larger deployments usually shipped their configuration files as in-house packages, which were unpacked together with the service. – Simon Richter Oct 14 '20 at 19:13
  • @SimonRichter I was referring specifically to Linux, which didn't have any sort of firewall until kernel 1.1. – Michael Hampton Oct 14 '20 at 19:58
  • @MichaelHampton, Debian never had a kernel older than 2.0. – Simon Richter Oct 14 '20 at 20:10
  • @SimonRichter And AFAIK never shipped with the firewall actually blocking anything at first boot, not even today. – Michael Hampton Oct 14 '20 at 20:16