Re: [PATCH container/manager 0/2] fix #8093: console: bind console sessions to container lifetime via systemd scopes

[Filip Schauer <f.schauer@proxmox.com>]

On 07/10/2026 10:37, Elias Huhsovitz wrote:
> The current Problem
> -------------------
> Console session processes can outlive their container when it stops or
> is destroyed. The cleanup currently runs in pvestatd every 10 seconds.
> It calls vmstatus() and kills stale processes by PID.
> 
> The killing of the process can result in a race condition:
> If the console gets closed by something else, just before the kill
> command is executed, a different process can reuse the PID and we kill
> a completely unrelated process.
> 
> Also checking this every 10s is too much unnecessary overhead IMO.
> 
> My understanding of a "better" architecture
> -------------------------------------------
> IMO console deletion should be tied to the state of the underlying
> container. Also I was unable to find a "convenient" time/event for a
> cleanup job to run.
> 
> Proposed implementation
> -----------------------
> Wrap console commands in transient systemd scopes and bind them to the
> container service via the PartOf= property. When the container stops,
> systemd stops the scope, terminating the console session and the dtach
> session. This allows removing the pvestatd periodic cleanup entirely.

Getting away from the polling in pvestatd would be nice.
However, I don't think `PartOf=` can be relied on here.

As a test I created a scope running `sleep 1000` with
`PartOf=pve-container@103.service`. Stopping the container left the
scope and its process running. It seems like `lxc-stop` ends the service
without a systemd stop job, and `PartOf=` only propagates explicit stop
jobs. The same goes for a `poweroff` inside the container. As far as I
can tell, the scope would only be stopped by `systemctl stop` or
`systemctl restart`. So most stop paths are not covered.

But do we even need to kill the lxc-console process in the first place?
lxc-console already exits automatically when the container stops. Or am
I missing something? Is there any case where the process lingers?