On Mo, 01.10.18 09:14, Justin Forbes (jmforbes(a)linuxtx.org) wrote:
> Lennart made a really interesting observation here, systemd
> is just proxying if "cat /sys/power/disk" indicates that
> hibernate is supported.
No, that is not what systemd is doing. The kernel provides a
mechanism, it does absolutely nothing with that mechanism unless told
to do so. What systemd is actually doing is creating a policy around
Well, we do provide a way to disallow hibernation in systemd, that's
not the point.
The thing though is: the hibernation subsystem in the Fedora kernel is
in a relatively unique situation: it's enabled and installed on all
installations by default, and adds a substantial, relatively invasive,
non-trivial subsystem to the kernel — all while (as I understand) the
Fedora kernel maintainers are not really willing to maintain it with
the greatest love, and show no interest in turning this into a
universally supported mechanism. Is there any other subsystem that is
equally invasive which is enabled on all systems but where the
maintainers are equally conservative in their will to support/fix it?
I don't think so...
To compare this with other cases: usually code that the package
maintainers don't want to maintain with the highest priority and
greatest love is split into separate RPMs, and not installed by
default. But in this case that's not really possible...
Also, while of course I personally think that people should use
systemd's APIs to hibernate the system this is not really how the
world works. There are plenty of howtos on the internet that suggest
people to use the /sys interface directly to hibrenate the system from
their scripts. And hence that's how people often do it. Turning off
hibrenation in levels high up in the stack hence kinda is less than
ideal, as all those scripts don't care a tiny bit about that if they
use the API advertised by the kernel itself...
While this change would "solve" the problem, I do not
believe it is
the correct place to do so. As mentioned above, the mechanism is not
flawed. Some hardware does not support the mechanism, and has no way
of reporting as such, which is why policy has always been leave it off
unless the user knowingly triggers it. Now we have changed the
policy, in a way that seems pretty much universally undesirable, the
solution is the revert the policy, not cripple the mechanism.
I think it would be wise to generally only enable and advertise
features in the Fedora kernel that the kernel maintainers are actually
willing to support. To me it appears this is generally followed in all
cases, but in this case the kernel advertises that hibernation is
available, even though it is known to be broken in plenty cases with
noone actually caring about it.
Also: I am sure there's a lot of disagreement of what the
responsibility of systemd is and what not, but I personally don't
think it's our job to decide whether a specific kernel subsystem is
high quality enough to override the kernel's own advertisement of it,
or even to judge whether the Fedora kernel team's willingness to
maintain said subsystem is big enough or not. I'd much rather if the
kernel team would decide on their own, and advertise on their own what
they think is good enough and supportable enough to be used by
Or to say this differently: own the thing or turn it off.
Lennart Poettering, Red Hat