[SOLVED] Komisches verhalten LXC nach Upgrade auf PVE 7

[Skye]

Hallo zusammen,

Seit dem Upgrade auf Proxmox 7 und dem Upgrade der Debian Container auf Bullseye habe ich folgende Probleme:

Die SSH Verbindung dauert ca. 10 Sekunden und allgemein ist die ganze SSH Verbindung manchmal sehr träge.
Nach ewigem googlen habe ich rausgefunden das es nicht an der Config der SSH liegt sondern wohl an Proxmox oder der Bullseye Version der Container.

Schuld an dem ganzen scheint wohl der Dienst "systemd-logind" zu sein.

Gebe ich in der Shell (auf dem jeweiligen Linux Container) folgendes ein: systemctl status systemd-logind.service erhalte ich folgende Fehlermeldung:

systemd-logind.service - User Login Management
     Loaded: loaded (/lib/systemd/system/systemd-logind.service; static)
     Active: failed (Result: exit-code) since Thu 2021-08-05 09:26:54 UTC; 27s ago
       Docs: man:sd-login(3)
             man:systemd-logind.service(8)
             man:logind.conf(5)
             manrg.freedesktop.login1(5)
    Process: 6140 ExecStart=/lib/systemd/systemd-logind (code=exited, status=226/NAMESPACE)
   Main PID: 6140 (code=exited, status=226/NAMESPACE)
        CPU: 9ms

Aug 05 09:26:54 Deb-Matrix systemd[1]: systemd-logind.service: Main process exited, code=exited, status=226/NAMESPACE
Aug 05 09:26:54 Deb-Matrix systemd[1]: systemd-logind.service: Failed with result 'exit-code'.
Aug 05 09:26:54 Deb-Matrix systemd[1]: Failed to start User Login Management.
Aug 05 09:26:54 Deb-Matrix systemd[1]: systemd-logind.service: Scheduled restart job, restart counter is at 5.
Aug 05 09:26:54 Deb-Matrix systemd[1]: Stopped User Login Management.
Aug 05 09:26:54 Deb-Matrix systemd[1]: systemd-logind.service: Start request repeated too quickly.
Aug 05 09:26:54 Deb-Matrix systemd[1]: systemd-logind.service: Failed with result 'exit-code'.
Aug 05 09:26:54 Deb-Matrix systemd[1]: Failed to start User Login Management.

Dieser Fehler tritt ausnahmslos auf allen Containern auf bei denen keyctl und nesting NICHT aktiv sind.
Ist hingegen keyctl und nesting aktiv läuft alles ohne Probleme.

Hat jemand einen rat woran das liegen könnte?

 

[oguz]

hi,

nesting aktivieren ist die richtige loesung, das wird auch bald das default beim (unpriviligierten) container anlegen werden

 

[Skye]

Super, vielen dank, dann werde ich das mal überall aktivieren

 

[geppi]

In einem Thread im Englischen Forum schrieb Thomas Lamprecht bezüglich der systemd Versionen neuer als 247:

It tries to create more namespaces for it's various operations, like running the systemd-networkd with version 247.

As it runs in a container, which is also using namespaces to isolate it from the host, it must be allowed to setup nested namespaces.

Normally this can be avoided by pre-creating the relevant ones, it seems this version added new ones, which are not (yet?) specified in their container runtime interface requirements.

Wird das Setzen von nesting=1 denn für die Zukunft Vorraussetzung bleiben um die neueren systemd Versionen in einem unpriviligierten Container laufen zu lassen oder besteht die Möglichkeit, dass die "container runtime interface requirements" von systemd irgendwann wieder die notwendigen namespaces spezifizieren und man damit wieder auf das Nesting verzichten kann ?

 

[geppi]

In besagtem Thread im Englischen Forum hat Thomas Lamprecht meine oben gestellte Frage inzwischen beantwortet:

The container runtime interface requirements are not likely to change, and the required namespaces are dynamic in nature, so I'd really not expect nesting to go away anytime soon.
But, as it has no impact for unprivileged Containers and PVE 7.0 defaults to enable nesting anyway it should not be a real issue.

Demnach ist nicht zu erwarten, dass sich in absehbarer Zeit etwas an der Notwendigkeit ändern wird, das Nesting zu aktivieren.
Für unprivilegierte Container sollte dies jedoch keine negativen Auswirkungen haben und PVE 7.0 aktiviert das Nesting standardmäßig.