| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
| |
The proc-sys-fs-binfmt_misc.mount unit should not be enabled by
preset-all because it should only be used as fallback in case
proc-sys-fs-binfmt_misc.automount cannot be used on a system. In these
cases it should be enabled manually by an administrator.
|
| |
|
|
|
|
|
|
|
| |
This reverts commit 61c3e2c8bfc28cea5b52d8643fac3d85f4c571d2.
The original commit doesn't make sense to me, none of the listed units
have an [Install] section, they hence are not subject to enable/disable
and hence not preset either. This commit hence has no effect whatsoever,
let's undo it to avoid further confusion.
|
| |
|
|
|
|
|
|
|
| |
let's make sure we list all singleton units we define in the preset
list, either as disable or as enable. Only four were missing, let's add
them in.
Also, let's group the pstore one with the other ones that are enabled,
right at the top.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 7e1ed1f3b29162df25064b33dc55ac8cf432bb0b.
systemd-repart is not a user service that should be something people
enable/disable, instead it should just work if there's configuration for
it. It's like systemd-tmpfiles, systemd-sysusers, systemd-load-modules,
systemd-binfmt, systemd-systemd-sysctl which are NOPs if they have no
configuration, and thus don't hurt, but cannot be disabled since they
are too deep part of the OS.
This doesn't mean people couldn't disable the service if they really
want to, there's after all "systemctl mask" and build-time disabling,
but those are OS developer facing instead of admin facing, that's how it
should be.
Note that systemd-repart is in particular an initrd service, and so far
enable/disable state of those is not managed anyway via "systemctl
enable/disable" but more what dracut decides to package up and what not.
|
| |
|
|
|
|
|
|
| |
It's lightweight and generally useful, so it should be enabled by default. But
users might want to disable it for whatever reason, and things should be fine
without it, so let's make it installable so it can be disabled if wanted.
Fixes #15175.
|
| |
|
|
| |
Fixes #15083. Users might want to disable homed if not used to save resources.
|
| |
|
|
|
|
| |
This essentially adds another layer of configurability:
build disable, this, presence of configuration. The default is
set to enabled, because the service does nothing w/o config.
|
| |
|
|
|
|
|
| |
It has no effect is the pstore is not used, and prevents the non-volatile
storage from filling up if is used by the kernel.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952767
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Officially we default to a "enable *", even though pretty much everybody
overrides this with "disable *". We have a bunch of targets and services which
should not be enabled by default. In case the default policy is not overriden,
our passive units would be enabled by presets, which is generally not useful at
all. So let's explicitly mark them as disabled.
Note that this effectively changes very little. E.g. on Fedora, all the units
listed in this patch were "disabled" already.
Fixes #14648.
|
|
|
I want to add presets/user/ later. This mirrors the layout for units:
we have units/ and units/user. The advantage is that we avoid having yet
another directory at the top level.
|
