Debian 12 LXC Template SystemD Failures

W

WvdW

Renowned Member
Apr 18, 2013
26
1
68
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
 
Last edited:
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.
 
Last edited:
  • Like
Reactions: misku
fschauer said:
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.
Click to expand...
What about privileged containers though?
 
Privileged containers also require the nesting feature.
Note that using a privileged container poses a security risk.
 
fschauer said:
Privileged containers also require the nesting feature.
Note that using a privileged container poses a security risk.
Click to expand...
Thought so too.
Bildschirmfoto vom 2024-07-23 16-38-39.pngBildschirmfoto vom 2024-07-23 16-38-51.png
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.
 
Last edited:
makuser said:
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?
Click to expand...
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.
 
fschauer said:
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.
Click to expand...
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.
 
fschauer said:
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.
Click to expand...
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.
 
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.

fschauer said:
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.
Click to expand...
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?
 
Hi,
versionDefect said:
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?
Click to expand...
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
 
fiona said:
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
Click to expand...
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!
 
You must log in or register to reply here.
Top Bottom