[BUG] Wayland reconnect detaches GUI terminal TTY after websocket/client communication error, while the shell process keeps running

[snakedreamy]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

When running ghcr.io/linuxserver/webtop:ubuntu-kde with PIXELFLUX_WAYLAND=true, reconnecting to the same running session can cause the GUI terminal to appear lost or reset.

This happens both when reconnecting from a different machine and when reconnecting from the same machine/page.

Based on the attached probe log, the shell process is not terminated. The shell PID stays the same before and after the event, but it loses its controlling TTY. At the failure point, the probe records TRAP EXIT rc=129, and immediately after that the same shell process continues running with tty=not a tty instead of /dev/pts/1.

So the visible effect is that the terminal session looks reset, but the underlying shell process is actually still alive and detached from its original GUI terminal/TTY.

Expected Behavior

Reconnecting to the same persistent webtop session should preserve the GUI terminal attachment, or at minimum should not detach a running shell from its controlling TTY.

The shell process should either remain attached to the same GUI terminal session, or the reconnect logic should reattach the session cleanly without leaving the shell alive but without a TTY.

Steps To Reproduce

1. Start the container with PIXELFLUX_WAYLAND=true.

2. Open webtop from one machine.

3. In a GUI terminal inside webtop, run a probe script that prints PID and current TTY every second.

4. Leave it running for a long period of time.

5. Reconnect to the same running webtop session from another machine.

6. The same behavior can also occur when reconnecting from the same machine/page.

7. Around the reconnect time, the GUI terminal appears lost/reset.

8. Check the probe log:

   • before the event, the shell has a normal TTY such as /dev/pts/1
   • at the event, the probe records TRAP EXIT rc=129
   • after the event, the same shell PID continues running but tty=not a tty

gui-probe.log

container.log

gui-probe.sh

Environment

- OS:armbian 26.2.1
- How docker service was installed:podman

CPU architecture

arm64

Docker creation

mkdir -p $PWD/webtop-repro

podman run -d \
  --name webtop-test \
  --security-opt seccomp=unconfined \
  --shm-size=4g \
  -p 3001:3001 \
  -e TZ=Asia/Shanghai \
  -e LC_ALL=zh_CN.UTF-8 \
  -e PIXELFLUX_WAYLAND=true \
  -v $PWD/webtop-repro:/repro \
  ghcr.io/linuxserver/webtop:ubuntu-kde

Container logs

I am attaching the full `container.log` and `gui-probe.log`.

Relevant observations from the attached logs:

* The container does not appear to fully restart.
* Around the failure point, the container log shows:

  * `Stats sender: WS connection closed`
  * `Received STOP_VIDEO`
  * `Received START_VIDEO`
  * `Data too big for buffer (4092 + 12 > 4096)`
  * `error in client communication (pid 1582)`
  * cleanup and display/audio reconfiguration
* The probe log shows:

  * same shell PID throughout (`3177`)
  * normal TTY before failure (`/dev/pts/1`)
  * `TRAP EXIT rc=129` at the failure point
  * same shell PID continues afterwards with `tty=not a tty`

This suggests the reconnect path is detaching the GUI terminal/TTY rather than terminating the shell process.

[github-actions]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[snakedreamy]

Additionally, this issue still exists in the latest version, ghcr.io/linuxserver/webtop:ubuntu-kde-version-377f0526.

[corvidica]

I was able to reproduce this behavior with the error Data too big for buffer (4092 + 12 > 4096) in the logs as of yesterday, but unable to after rebuilding with the latest (linuxserver/webtop:ubuntu-kde-version-377f0526) today.

[snakedreamy]

I was able to reproduce this behavior with the error in the logs as of yesterday, but unable to after rebuilding with the latest (linuxserver/webtop:ubuntu-kde-version-377f0526) today.Data too big for buffer (4092 + 12 > 4096)

I did notice that the latest version has improved. The most obvious change is that the black screen interval during reconnection after each page refresh has become much shorter.
However, even with the latest version, I still encountered the issue where the graphical terminal appears to be lost or reset.

This time, the issue occurred in the following scenario: I first opened the Webtop webpage on one of my Windows computers and used it there. Then the Windows computer went to sleep. A few hours later, I tried to open the Webtop connection page on my MacBook to continue working, and that was when the GUI terminal session on the page was lost.

[corvidica]

Very similar use case to me but can confirm this morning it has stopped as of yesterday on the latest build. All active windows sessions survived reconnecting on different machines after all were inactive overnight. Do your logs still show the 'Data too big for buffer' error?

[snakedreamy]

Very similar use case to me but can confirm this morning it has stopped as of yesterday on the latest build. All active windows sessions survived reconnecting on different machines after all were inactive overnight. Do your logs still show the 'Data too big for buffer' error?

I didn’t check the logs earlier. I’m going to test it again and see what error shows up in his container logs.

[corvidica]

Well - a full 24 hours without this issue, but it has come back. Now i'm getting the fresh sessions with the Data too big for buffer (4092 + 12 > 4096). errors in the logs again.