summaryrefslogtreecommitdiffstats
path: root/src/shared/mount-setup.c
diff options
context:
space:
mode:
authorZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>2024-11-02 17:07:22 +0100
committerLuca Boccassi <luca.boccassi@gmail.com>2024-11-06 14:43:25 +0100
commitd0ab0e5fa5434cac67e51dbeb1d873c6ac6f20cd (patch)
treec4bc2483849be43ecfdf67946e63f69935e08cbd /src/shared/mount-setup.c
parentman/varlink: fix typo (diff)
downloadsystemd-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 '')
-rw-r--r--src/shared/mount-setup.c22
1 files changed, 19 insertions, 3 deletions
diff --git a/src/shared/mount-setup.c b/src/shared/mount-setup.c
index ba291bd76f..d5009fb59e 100644
--- a/src/shared/mount-setup.c
+++ b/src/shared/mount-setup.c
@@ -512,12 +512,28 @@ int mount_cgroup_legacy_controllers(bool loaded_policy) {
_cleanup_set_free_ Set *controllers = NULL;
int r;
+ /* Before we actually start deleting cgroup v1 code, make it harder to boot in cgroupv1 mode first.
+ * See also #30852. */
+
+ if (detect_container() <= 0) { /* If in container, we have to follow host's cgroup hierarchy. Only
+ * do the deprecation checks below if we're not in a container. */
+ if (cg_is_legacy_force_enabled())
+ log_warning("Legacy support for cgroup v1 enabled via SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1.");
+ else if (cg_is_legacy_enabled()) {
+ log_full(LOG_CRIT,
+ "Legacy cgroup v1 configured. This will stop being supported soon.\n"
+ "Will proceed with cgroup v2 after 30 s.\n"
+ "Set systemd.unified_cgroup_hierarchy=1 to switch to cgroup v2 "
+ "or set SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1 to reenable v1 temporarily.");
+ (void) usleep_safe(30 * USEC_PER_SEC);
+
+ return 0;
+ }
+ }
+
if (!cg_is_legacy_wanted())
return 0;
- if (!cg_is_legacy_force_enabled())
- return -ERFKILL;
-
FOREACH_ELEMENT(mp, cgroupv1_mount_table) {
r = mount_one(mp, loaded_policy);
if (r < 0)