0

https://unix.stackexchange.com/a/197682/674 says

All services are "disabled" by default; "enablement" is opt-in.

Is it correct?

After I run

sudo apt install openssh-server

why is sshd automatically run?

If a service is automatically started by systemd, how can I change the default to not start it?

Now I have installed samba server and NFS server, do I need to ask systemd to disable them by default (so that them won't automatically start every time when I boot into Lubuntu)? If yes, how?

Thanks.

  • Because the package enables it. – Stephen Harris Feb 24 at 23:09
  • It depends on your package manager and how is the software packaged, although in reality, sshd run in such case. Is starting on boot a default behavior? Still dependent on those. Although in reality it is the default. How to enable/disable service starting on boot? Read systemd tutorial. – 炸鱼薯条德里克 Feb 25 at 0:55
  • By default, I mean the status provided by a newly installed package without any further configuration. – 炸鱼薯条德里克 Feb 25 at 0:56
  • Even if a service is enabled by default, it will often not be running at startup, instead being started on-demand due to systemd's socket activation. – novice Feb 25 at 2:06
  • @炸 Is there a command that can list the on/off status of all the services managed by systemd? – Tim Feb 25 at 2:57
4

All services are "disabled" by default; "enablement" is opt-in.

Is it correct?

Yes, in that if you create a unit file on disk, you still need to run some commands for systemd to learn about the new unit (systemctl daemon-reload), to start it right away (systemctl start ...), to request that it's started on boot (systemctl enable ...) or to enable and start it at the same time with a shortcut (systemctl enable --now ....)

But when you install a package that includes systemd units, the package will typically run most of these commands for you as part of their post-install scripts.

After I run

sudo apt install openssh-server

why is sshd automatically run?

So the package's post-install script is enabling it and running the package after it's installed.

You mentioned you're on Lubuntu. Debian-based distros (those typically using apt-get or apt) such as Debian itself, Ubuntu, Lubuntu and its other variants have traditionally started and enabled packages right after installing them. Their philosophy is to ship sane and "safe" defaults that allow starting a service and making it useful out of the box. (By "safe" sometimes that means not accepting connections except from localhost, or sometimes restricting authentication to strong forms of authentication only, like key-based authentication.)

Red Hat-based systems (RHEL, CentOS, Fedora, I think SuSE too) typically do the opposite and require the administrator to explicitly enable and start a daemon after installing the software packages for it, so they'll have a chance to review its configuration before it's brought up for the first time.

systemd created a mechanism to wrap around enablement and initialization, and it's one that takes into account the distribution-specific policies in this regard, which is called Presets.

That mechanism allow packagers to simply call systemctl preset ... from their post-install scripts, so they don't need to worry about the specific policies of the distro.

Debian-based distributions will push a *.preset file that has the line enable *, which will implement their policy of enabling everything by default, while Red Hat-based distributions ship a *.preset file with disable * to implement their preference.

Beyond making the mechanism behind this distro-specific setting uniform across distros, systemd Presets also offer an easy and uniform way for administrators to customize those settings, selecting different presets for specific packages or wholly overriding the distribution's original choice.

In practice, Debian-based distributions end up not using systemctl preset directly, instead they ship a small wrapper around it, which is what they use in their packages' post-install scripts. The reason for the wrapper is to record the enablement mode of a package when it's uninstalled, in order to preserve it in case the package is installed again in the future on that same host. The systemd preset configs still work as usual on these hosts, so this small detail can for the most part be ignored.

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.