From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id C748A1FF0AB for ; Wed, 07 Oct 2026 15:38:20 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 92610213B4; Wed, 07 Oct 2026 15:38:17 +0200 (CEST) Message-ID: Date: Wed, 7 Oct 2026 15:38:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH container/manager 0/2] fix #8093: console: bind console sessions to container lifetime via systemd scopes To: Elias Huhsovitz , pve-devel@lists.proxmox.com References: <20261007083726.26067-1-e.huhsovitz@proxmox.com> Content-Language: en-US From: Filip Schauer In-Reply-To: <20261007083726.26067-1-e.huhsovitz@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1791380292134 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.562 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: Y64HILTR7HQ2CZEPHNOEBU5HGL4EM24D X-Message-ID-Hash: Y64HILTR7HQ2CZEPHNOEBU5HGL4EM24D X-MailFrom: f.schauer@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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?