Re: [pve-devel] [PATCH container] add container console scrollback buffer

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

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<t.ellmenreich@proxmox.com>
> 
> [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