Let's explicitly deactivate all home dirs on shutdown, in order to
properly synchronizing unmounting and avoiding blocking devices.
Previously, we'd rely on automatic deactivation when home directories
become unused. However, that scheme is asynchronous, and ongoing
deactviations might conflicts with attempts to unmount /home. Let's fix
that by providing an explicit service systemd-homed-activate.service
whose only job is to have a ExecStop= line that explicitly deactivates
all home directories on shutdown. This service can the be ordered after
home.mount and similar, ensuring that we'll first deactivate all homes
before deactivating /home itself during shutdown.
This is kept separate from systemd-homed.service so that it is possible
to restart systemd-homed.service without deactivating all home
directories.
Fixes: #16842
RC_LOCAL_SCRIPT_PATH_START and RC_LOCAL_SCRIPT_PATH_STOP were was originally
added in the conversion to meson based on the autotools name. In
4450894653 RC_LOCAL_SCRIPT_PATH_STOP was dropped.
We don't need to use such a long name.
Add After=systemd-networkd.socket to avoid a race condition and networkd
falling back to the non-socket activation code.
Also add Wants=systemd-networkd.socket, so the socket is started when
networkd is started via `systemctl start systemd-networkd.service`.
A Requires is not strictly necessary, as networkd still ships the
non-socket activation code. Should this code be removed one day, the
Wants should be bumped to Requires accordingly.
See also 5544ee8516.
Fixes: #16809
This should make /home as automount work reasonably well.
If /home is an automount this has little effect at boot, because if the
automount is not triggered it doesn't matter how the associated mount is
ordered.
It does matter at shutdown however, where home.mount is likely active
now. There the ordering means we'll end sessions first, and only then
deactivate home.mount.
Fixes: #16291
Combining Requires= with Before= doesn't really make sense, since this
means we are requiring something that runs after us, which logically
cannot be fulfilled.
Let's hence downgrade Requires= to Wants= so that the ordering is kept
but no failure propagation implied.
This should be enough to fix https://bugzilla.redhat.com/show_bug.cgi?id=1856514.
But the limit should be significantly higher than 10% anyway. By setting a
limit on /tmp at 10% we'll break many reasonable use cases, even though the
machine would deal fine with a much larger fraction devoted to /tmp.
(In the first version of this patch I made it 25% with the comment that
"Even 25% might be too low.". The kernel default is 50%, and we have been using
that seemingly without trouble since https://fedoraproject.org/wiki/Features/tmp-on-tmpfs.
So let's just make it 50% again.)
See 7d85383edb.
(Another consideration is that we learned from from the whole initiative with
zram in Fedora that a reasonable size for zram is 0.5-1.5 of RAM, and that pretty
much all systems benefit from having zram or zswap enabled. Thus it is reasonable
to assume that it'll become widely used. Taking the usual compression effectiveness
of 0.2 into account, machines have effective memory available of between
1.0 - 0.2*0.5 + 0.5 = 1.4 (for zram sized to 0.5 of RAM) and
1.0 - 0.2*1.5 + 1.5 = 2.2 (for zram 1.5 sized to 1.5 of RAM) times RAM size.
This means that the 10% was really like 7-4% of effective memory.)
A comment is added to mount-util.h to clarify that tmp.mount is separate.
This reverts commit c7220ca802.
The removal was done as a reaction to the messages from systemd:
initrd-root-fs.target: Requested dependency OnFailure=emergency.target ignored (target units cannot fail).
initrd.target: Requested dependency OnFailure=emergency.target ignored (target units cannot fail).
initrd-root-device.target: Requested dependency OnFailure=emergency.target ignored (target units cannot fail).
initrd-fs.target: Requested dependency OnFailure=emergency.target ignored (target units cannot fail).
local-fs.target: Requested dependency OnFailure=emergency.target ignored (target units cannot fail).
...
But it seems that the messages themselves are wrong, and the units were OK.
Strictly speaking you can run homed without userdb. But it doesn't
really make much sense: they go hand in hand and implement the same
concepts, just for different sets of users. Let's hence disable both
automatically by default if homed is requested.
(We don't do the reverse: opting into userdbd shouldn't mean that you
are OK with homed.)
And of course, users can always deviate from our defaults easily, and
turn off userbd again right-away if they don't like it, and things will
generally work.
This generator can be used by desktop environments to launch autostart
applications and services. The feature is an opt-in, triggered by
xdg-desktop-autostart.target being activated.
Also included is the new binary xdg-autostart-condition. This binary is
used as an ExecCondition to test the OnlyShowIn and NotShowIn XDG
desktop file keys. These need to be evaluated against the
XDG_CURRENT_DESKTOP environment variable which may not be known at
generation time.
Co-authored-by: Henri Chain <henri.chain@enioka.com>
In our regular gettys the actual shell commands live the the session
scope anyway (as long as logind is used). Hence, let's avoid
KillMode=process, it serves no purpose and is simply unsafe since it
disables systemd's own process lifecycle management.
We want to watch USB sticks being plugged in, and that requires
AF_NETLINK to work correctly and get the host's events. But if we live
in a network namespace AF_NETLINK is disconnected too and we'll not get
the host udev events.
Fixes: #15287
Limit size of various tmpfs mounts to 10% of RAM, except volatile root and /var
to 25%. Another exception is made for /dev (also /devs for PrivateDevices) and
/sys/fs/cgroup since no (or very few) regular files are expected to be used.
In addition, since directories, symbolic links, device specials and xattrs are
not counted towards the size= limit, number of inodes is also limited
correspondingly: 4MB size translates to 1k of inodes (assuming 4k each), 10% of
RAM (using 16GB of RAM as baseline) translates to 400k and 25% to 1M inodes.
Because nr_inodes option can't use ratios like size option, there's an
unfortunate side effect that with small memory systems the limit may be on the
too large side. Also, on an extremely small device with only 256MB of RAM, 10%
of RAM for /run may not be enough for re-exec of PID1 because 16MB of free
space is required.
"Login Service" doesn''t explain much, esp. considering that logind is actually is
for logins. I think "User Login Management" is better, but not that great either.
Suggestions welcome.
We unregister binfmt_misc twice during shutdown with this change:
1. A previous commit added support for doing that in the final shutdown
phase, i.e. when we do the aggressive umount loop. This is the robust
thing to do, in case the earlier ("clean") shutdown phase didn't work
for some reason.
2. This commit adds support for doing that when systemd-binfmt.service
is stopped. This is a good idea so that people can order mounts
before the service if they want to register binaries from such
mounts, as in that case we'll undo the registration on shutdown
again, before unmounting those mounts.
And all that, just because of that weird "F" flag the kernel introduced
that can pin files...
Fixes: #14981
This doesn't really matter, since in non-/usr-merged systems plymouth
needs to be in /bin and on merged ones it doesn't matter, but it is
still prettier to insert the right path, and avoid /bin on merged
systems, since it's just a compat symlink.
Replaces: #15351
This dependency is now generated automatically given we use
StateDirectory=. Moreover the combination of Wants= and After= was too
strong anway, as whether remount-fs is pulled in or not should not be up
to systemd-pstore.service, and in fact is part of the initial
transaction anyway.
sysinit.target is the target our early boot services are generally
pulled in from, make systemd-pstore.service not an exception of that.
Effectively this doesn't mean much, either way our unit is part of the
initial transaction.
Add `ProtectClock=yes` to systemd units. Since it implies certain
`DeviceAllow=` rules, make sure that the units have `DeviceAllow=` rules so
they are still able to access other devices. Exclude timesyncd and timedated.
This reverts commit 7e1ed1f3b2.
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.
/home is posibly a remote file system. it makes sense to order homed
after it, so that we can properly enumerate users in it, but we probably
shouldn't pull it in ourselves, and leave that to users to configure
otherwise.
Fixes: #15102
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.
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.
Lennart Poettering