From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id 3BB2F1FF09B for ; Mon, 28 Sep 2026 13:02:44 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id ED3EB216DC; Mon, 28 Sep 2026 13:02:38 +0200 (CEST) Message-ID: <7788afcb-4ca0-4189-9fb9-001a6c9dad78@proxmox.com> Date: Mon, 28 Sep 2026 13:02:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [pve-devel] [PATCH container] add container console scrollback buffer To: Thomas Ellmenreich , Proxmox VE development discussion References: <20260121112335.84473-1-f.schauer@proxmox.com> Content-Language: en-US From: Filip Schauer In-Reply-To: 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: 1790593352101 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.602 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 URI_HEX 0.1 URI hostname has long hexadecimal sequence Message-ID-Hash: DNUKDQFHSQZ276YRU5GQAWSPKO4U327F X-Message-ID-Hash: DNUKDQFHSQZ276YRU5GQAWSPKO4U327F 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 CC: pve-devel 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 25/09/2026 13:00, Thomas Ellmenreich wrote: > Thanks for this patch! In my opinion, this would be a great addition. > > I installed the patch on one of my test nodes and it worked wonderfully. > > However, looking at the approach, I'm not convinced that having a separate > process for each container just for the scrollback buffer is ideal, so I would > definitely make it optional. This is especially the case since the new process > is added regardless of whether the terminal is ever used. That said, I'm not > quite sure how to improve it. > > I assume that applying the patch [0] to dtach itself would not solve the > problem of the extra process, as dtach would just become that extra process. > > Overall, I think the approach is reasonable. I considered having one 'master > master' process (xD) for all containers instead of a new process for each > container. However, that would introduce a lot of programming complexity. > > When I first started using it, I thought the buffer was a bit small. > Implementing it as you have would allow us to easily make the buffer > configurable. I can see larger buffer sizes being useful in some cases. > > As an aside: I found it especially nice that some context is now retained > when refreshing the page. > > Tested-by: Thomas Ellmenreich > > [0]https://367015.bugs.gentoo.org/attachment.cgi?id=272965 Thanks for the feedback and testing! Even without this patch, a dtach master process already runs for each container once its console has been opened at least once in the web UI. (You can verify this with `ps aux | grep dtach`) The dtach patch alone would therefore grant us the scrollback as soon as the console has been opened for the first time. To retain early boot diagnostics as well, the dtach master needs to be started when the container starts, rather than when the console is first opened in the web UI. This is why my patch starts a master process in src/PVE/LXC.pm:vm_start. The drawback is that containers whose consoles are never opened will now also retain a dtach master process. I measured the memory overhead of different approaches: * Native C dtach: ~1.2 MB RSS * Perl dtach-scrollback-master: ~7 MB RSS While 7 MB is lean for Perl, it adds up with each running container. Regarding patching dtach directly: very recently a new pull request was created on GitHub that implements a configurable scrollback buffer along with some special handling for terminal escape sequences: https://github.com/crigler/dtach/pull/32 The problem is that we don't know when or if the PR will be merged upstream, and waiting for it to reach Debian could take a long time. So I see a few options going forward: * Vendor dtach with PR #32 applied ourselves * Use the dtach-scrollback-master Perl implementation and accept the memory overhead * Write our own lightweight dtach master in Rust to avoid having to vendor dtach while keeping the memory footprint low