[pkg-lxc-devel] Bug#1030389: Bug#1030389: lxc: Conflict with new systemd cgroup unified hierarchy

Pierre-Elliott Bécue peb at debian.org
Mon Feb 6 22:03:30 GMT 2023


Linas Vepstas <linasvepstas at gmail.com> wrote on 06/02/2023 at 22:59:05+0100:

> On Mon, Feb 6, 2023 at 8:29 AM Pierre-Elliott Bécue <peb at debian.org> wrote:
>
>  No, but it sounds plausible that either you don't have apt-listchanges
>
> I do have apt-listchanges, but Debian auto-updates itself nightly, and
> does not inform me of what changes it makes.  I don't know how to
> disable the auto-update feature.

If you have unattended-upgrades installed, Debian indeed self-updates on
a daily basis. That being said, it does not change the distro version.

The systemd update that made unified cgroups hierarchy the default has
been between buster's release and bullseye's release. Hence, the systemd
version of buster does *not* break unprivileged containers.

As you're on bullseye, it means that you did, at some point, a stable
upgrade. And if you were still able to run your unprivileged containers,
then either you did reboot when you did your stable upgrade and found
out about lxc-unpriv-start, or you did *not* reboot after your stable
upgrade.

>  and therefore didn't read the news entry telling how to make
>  unprivileged containers work with cgroupsv2, 
>
> My unpriviledged contains have worked *just fine* for a decade! And
> then they broke a few days ago. Creating a breaking change that is
> silent and incompatible is not acceptable. This took me two days to
> debug, and it took down a running server, https://gnucash.org for that
> time interval.

The breaking change is not silent. It is advertised in the news file of
systemd the way *ALL* breaking changes have always been. As Debian does
not accept breaking changes on stable versions, they all come with a
stable upgrade (when the codename and the major version changes).

As these upgrade are supposed to be done by hand, and with
apt-listchanges installed (it's installed by default, only people doing
specific stuff don't have it, and it's generally not a good idea), you
should have be presented the breaking changes on all your packages. As I
don't know what your admin practices are, and how you did your buster ->
bullseye upgrade, I can't know where it went wrong, but I'm sorry to
state that it's not on systemd's side and *certainly not* on LXC's side,
as the change made in LXC was only to make it able to work again with
unified cgroup hierarchy, which was enabled by systemd v247.2-2.

This change has more than 2 years, now.

>  or you installed directly
>  LXC on bullseye and didn't read the readme present in
>  /usr/share/doc/lxc (file: README.Debian.gz).
>
> It is fundamentally wrong to expect users to be rocket surgeons. Being
> unable to boot your system after a power outage is bad. Taking three
> days to figure out why your server, that thousands of people depend
> on, failed to boot, is a horror. Requiring a PhD in operating system
> theory and days plundering the bowels of how this obscure and arcane
> subsystem works is not acceptable.

What is fundamentally wrong is being aggressive. No one here is your
punching ball, and you are not entitled to anything more than the system
you get. You are not a customer, and I am not a client support
host. Debian, as any Free Operating System requires one to read its
documentation, and the changelogs between the releases. In particular,
stable upgrades should be done manually, and the documentation we
provide allows one to avoid a lot of caveats. It seems clear to me that
whatever you did, you did not follow our guidelines.

The file I referred to is supposed to be shown by apt-listchanges. Yet,
even without that, reading the content of /usr/share/doc is not
something obscure or an arcane move, it's what any person should do by
default, or at least when they meet a problem.

> When you lose electrical power, and get it back again, the system
> should be able to boot and run. Blaming me for not reading some
> obscure and unknown README file after making a BREAKING CHANGE is
> criminal.
>
> This is representative of the stupid thought that the systemd folks
> engage in regularly. I'm tired of spending days trying to repair
> systems that worked just fine the day before. Changes to apt packages
> should not render a system unbootable.  And breaking stuff, ... on
> purpose ...  just to break it ... that's criminal.

You should really get some fresh air before throwing a tantrum in a bug
system and present youself quite badly.

> I'd punch all of you in the nose if I could. This is just gross
> negligence and incompetence. You people need to grow up and stop
> acting like Peter Pan. It's' time to behave like responsible, grown
> adults. Take some pride in doing good work, instead of crapping on
> your users!

I'm sorry, but your behaviour is not acceptable.

You've clearly not followed the proper guidelines to upgrade your system
By doing so, you dug a hole, which you fell in later. And now, you're
being aggressive, behaving in a quite immature way, and trying to make
it LXC maintainers' fault (or maybe, systemd maintainers' assuming that
you realized that the breaking change lies within systemd) instead of
trying to take a step back and understanding what actually failed in
your way of doing stuff.

Instead of trying to lecture others on how they should work or behave
when they clearly did their work properly, maybe you should indeed
follow your own remark and start behaving like a responsible and grown
adult.

-- 
PEB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 853 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-lxc-devel/attachments/20230206/524f45e5/attachment-0001.sig>


More information about the Pkg-lxc-devel mailing list