diff options
author | Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> | 2024-11-02 17:07:22 +0100 |
---|---|---|
committer | Luca Boccassi <luca.boccassi@gmail.com> | 2024-11-06 14:43:25 +0100 |
commit | d0ab0e5fa5434cac67e51dbeb1d873c6ac6f20cd (patch) | |
tree | c4bc2483849be43ecfdf67946e63f69935e08cbd /NEWS | |
parent | man/varlink: fix typo (diff) | |
download | systemd-d0ab0e5fa5434cac67e51dbeb1d873c6ac6f20cd.tar.xz systemd-d0ab0e5fa5434cac67e51dbeb1d873c6ac6f20cd.zip |
pid1: stop refusing to boot with cgroup v1
Since v256 we completely fail to boot if v1 is configured. Fedora 41 was just
released with v256.7 and this is probably the first major exposure of users to
this code. It turns out not work very well. Fedora switched to v2 as default in
F31 (2019) and at that time some people added configuration to use v1 either
because of Docker or for other reasons. But it's been long enough ago that
people don't remember this and are now very unhappy when the system refuses to
boot after an upgrade.
Refusing to boot is also unnecessarilly punishing to users. For machines that
are used remotely, this could mean somebody needs to physically access the
machine. For other users, the machine might be the only way to access the net
and help, and people might not know how to set kernel parameters without some
docs. And because this is in systemd, after an upgrade all boot choices are
affected, and it's not possible to e.g. select an older kernel for boot. And
crashing the machine doesn't really serve our goal either: we were giving a
hint how to continue using v1 and nothing else.
If the new override is configured, warn and immediately boot to v1.
If v1 is configured w/o the override, warn and wait 30 s and boot to v2.
Also give a hint how to switch to v2.
https://bugzilla.redhat.com/show_bug.cgi?id=2323323
https://bugzilla.redhat.com/show_bug.cgi?id=2323345
https://bugzilla.redhat.com/show_bug.cgi?id=2322467
https://www.reddit.com/r/Fedora/comments/1gfcyw9/refusing_to_run_under_cgroup_01_sy_specified_on/
The advice is to set systemd.unified_cgroup_hierarchy=1 (instead of removing
systemd.unified_cgroup_hierarchy=0). I think this is easier to convey. Users
who are understand what is going on can just remove the option instead.
The caching is dropped in cg_is_legacy_wanted(). It turns out that the
order in which those functions are called during early setup is very fragile.
If cg_is_legacy_wanted() is called before we have set up the v2 hierarchy,
we incorrectly cache a true answer. The function is called just a handful
of times at most, so we don't really need to cache the response.
Diffstat (limited to 'NEWS')
-rw-r--r-- | NEWS | 13 |
1 files changed, 8 insertions, 5 deletions
@@ -51,6 +51,12 @@ CHANGES WITH 257 in spe: too many systems, because most NVMe devices only know a namespace 1 by default. + * Support for cgroup v1 ('legacy' and 'hybrid' hierarchies) is now + considered obsolete and systemd by default will ignore configuration + that enables them. To forcibly reenable cgroup v1 support, + SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1 must additionally be set on the + kernel command line. + Announcements of Future Feature Removals: * The D-Bus method org.freedesktop.systemd1.StartAuxiliaryScope() is @@ -64,11 +70,8 @@ CHANGES WITH 257 in spe: will be phased out in a future release in 2025, i.e. we expect to bump the minimum baseline to v5.4 then too. - * Support for cgroup v1 ('legacy' and 'hybrid' hierarchies) is now - considered obsolete and systemd by default will refuse to boot under - it. To forcibly reenable cgroup v1 support, - SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1 must be set on kernel command - line. The complete removal of cgroup v1 is scheduled for v258. + * The complete removal of support for cgroup v1 ('legacy' and 'hybrid' + hierarchies) is scheduled for v258. * Support for System V service scripts is deprecated and will be removed in v258. Please make sure to update your software |