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

["Elias Huhsovitz" <e.huhsovitz@proxmox.com>]

On Wed Oct 7, 2026 at 3:38 PM CEST, Filip Schauer wrote:
> 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.

Thats interesting. I was not able to re-produce this behaviour when
calling poweroff from inside the container

Did you create the console using `pct`, or via the API 
(e.g. `/nodes/{node}/lxc/{vmid}/vncproxy)`.

But nevertheless, you are correct. My assumptions about the `PartOf=`
were wrong.

>
> 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?

There are a few scenarios where lxc-console remains:

1. rm-rf <id>.conf 

while the process is running. Killing the container via lxc-stop <id>
leaves the console running.

2. pid=$(pgrep -f "lxc-console.*<id>")
kill -STOP $pid
lxc-stop <id>

also results in a remaining console.

In my testing yesterday, calling 

pct detory <id> --force
while the container is still running, resulted in an orphaned console,
which prompted me to create this patch in the first place

But I am unable to re-produce this currently. So probably the issue was
something else...

Bottom Line
-----------
The scenarios that leave an orphaned are not standard lifecycle events.

What about:

Moving the `remove_stale_lxc_consoles` logic (with some
improvements) to pve-container.

Introduce a new pct command `pct console cleanup` (name TBD), so that
administrators can cleanup the orphaned consoles in the edge cases
where an lxc-console might get left behind.

I would love to hear your thoughts on this matter!