Debian 12 LXC Template SystemD Failures

[WvdW]

Hi,

PVE: 8.2.4

I noticed log in delays with a new Deb12 container I was testing. When trying to reboot or shutdown it would also just hang for about 30 seconds and then display 'Failed to set wall message, ignoring: Connection timed out', after which it would eventually complete the requested action.

I had a look at systemd's login service 'systemctl status systemd-logind' which showed a start failure. After looking at the journal messages 'journalctl -xeu systemd-logind.service' it was evident it was trying to start but kept failing. Two of the errors had to do with permissions:
'systemd-logind.service: Failed at step NAMESPACE spawning /lib/systemd/systemd-logind: Permission denied'
'systemd-logind.service: Failed to set up mount namespacing: /run/systemd/unit-root/proc: Permission denied'

I then tried the Ubuntu 24.4 LXC template, configured it exactly as the Deb12 one was and it worked 100%. No delays, no error messages and the systemd service starting up successfully. So clearly this is an issue with the Deb12 template (btw I tried the Deb11 one as well and it was doing the exact same).

Has something been stripped out of the Deb12 template that should have remained? Is there a way to correct it? I would prefer using the Debian template rather than the Ubuntu one but am now concerned that all is not well with it
BTW: This template was downloaded from the Proxmox repository. Is there any other trusted Debian direct repository where LXC templates can also be downloaded from instead of manually having to build my own one?

Thanks

Werner

 

[fschauer]

As a hardening measure, systemd tries to setup namespaces. In the instance of the Debian LXC template, it seems that setting ProtectControlGroups= to no in /lib/systemd/system/systemd-logind.service lets the systemd-logind.service start successfully.
Another way to work around this is to enable the nesting feature in the container options.

 

[makuser]

As a hardening measure, systemd tries to setup namespaces. In the instance of the Debian LXC template, it seems that setting ProtectControlGroups= to no in /lib/systemd/system/systemd-logind.service lets the systemd-logind.service start successfully.
Another way to work around this is to enable the nesting feature in the container options.

What about privileged containers though?

 

[fschauer]

Privileged containers also require the nesting feature.
Note that using a privileged container poses a security risk.

 

[makuser]

Privileged containers also require the nesting feature.
Note that using a privileged container poses a security risk.

Thought so too.

But then I do not understand why nesting is greyed-out if you unselect "unprivileged container" while creating a ct. That must be a bug then?


I now know nesting can be enabled after the setup, that's not what I'm asking. I'm just wondering why it would even be greyed-out in the first place, if it was clearly a function that also works on privileged cts.

 

[fschauer]

But then I do not understand why nesting is greyed-out if you unselect "unprivileged container" while creating a ct. That must be a bug then?

This is not a bug. This is to discourage users from using privileged containers with nesting. It is possible to do this, but it is not secure, as it basically gives the container full access to the host.

 

[makuser]

This is not a bug. This is to discourage users from using privileged containers with nesting. It is possible to do this, but it is not secure, as it basically gives the container full access to the host.

I see. IMHO that's still a bad design choice. An exclamation mark would fit more.

Unfortunately unprivileged containers seem to be the only way, currently at least, to run samba 4.

 

[WvdW]

As a hardening measure, systemd tries to setup namespaces. In the instance of the Debian LXC template, it seems that setting ProtectControlGroups= to no in /lib/systemd/system/systemd-logind.service lets the systemd-logind.service start successfully.
Another way to work around this is to enable the nesting feature in the container options.

Thanks for the pointer Filip. I had a look and made the change as recommended. It definitely solved the problem although I am still not convinced that it is 100% the correct solution. I am basing my statement on a comparison of the systemd-logind.service files between Deb12 and Ubuntu 24.4.
In both ProtectControlGroup=yes is set by default - one distribution is working and the other not. So both are applying the hardening with different results.

The test containers are both running as unprivileged, unnested for isolation.

 

[fschauer]

The reason why this problem does not occur in the Ubuntu container, is this systemd ubuntu patch: https://git.launchpad.net/~ubuntu-c...e-more-careful-when-handling-namespacin.patch

This causes systemd to ignore the errors when trying to create a namespace.

 

[versionDefect]

Hi all, I'm experiencing this same issue. (still new at Hypervisors so sorry if I misspeak)
Running on an unprivileged container, tried with both nesting on and off, opening the console is blank until you wait like a few minutes, then the login message comes up and works perfectly fine.

As a hardening measure, systemd tries to setup namespaces. In the instance of the Debian LXC template, it seems that setting ProtectControlGroups= to no in /lib/systemd/system/systemd-logind.service lets the systemd-logind.service start successfully.
Another way to work around this is to enable the nesting feature in the container options.

I've even tried to do this even though I already had nesting enabled but still no dice, login page takes minutes to load for some reason. Am I doing something wrong here?

 

[fiona]

Hi,

Hi all, I'm experiencing this same issue. (still new at Hypervisors so sorry if I misspeak)
Running on an unprivileged container, tried with both nesting on and off, opening the console is blank until you wait like a few minutes, then the login message comes up and works perfectly fine.


I've even tried to do this even though I already had nesting enabled but still no dice, login page takes minutes to load for some reason. Am I doing something wrong here?

please check the system journal inside the container. I remember other users with such delays where the culprit was configuring DHCP for IPv6 without having a DHCPv6 server, so startup waited until that timed out. If it's not that, please share the container configuration pct config <ID> and the output of pveversion -v

 

[versionDefect]

Hi,

please check the system journal inside the container. I remember other users with such delays where the culprit was configuring DHCP for IPv6 without having a DHCPv6 server, so startup waited until that timed out. If it's not that, please share the container configuration pct config <ID> and the output of pveversion -v

Of course, I spend an hour trying to figure out wtf is going on with this thing, after I make a post asking for help, I found out it was an IPV6 issue for some reason.

Also thanks for the fast response. After setting ipv6 on the VM to be on SLACC everything is working great now.

Thanks!