x11vnc hangs while moving/sizing windows on IceWM

[elluisian]

Describe the bug
If I decide to stop the x11vnc server while I'm dragging/resizing a window through keyboard shortcuts, I'm not able to restart said server.
When I try to restart it, it just hangs at:

18/11/2024 22:47:49 passing arg to libvncserver: -listen
18/11/2024 22:47:49 passing arg to libvncserver: localhost
18/11/2024 22:47:49 -usepw: found *OMITTED*
18/11/2024 22:47:49 x11vnc version: 0.9.16 lastmod: 2019-01-05  pid: 289967

I'm using IceWM 3.6.0 (the actual version doesn't matter) on Debian Trixie (testing), its shortcut to move/resize windows are ALT+F7 and ALT+F8.
Please note that I'm not sure this is related to x11vnc itself, as I was able to reproduce this issue with other programs as well (xdotool, icesh).
Unfortunately I'm not familiar with X11's architecture, so I'm not able to say what's causing it.

While when being phisically in the vicinity of the server, it is simply a matter of "canceling the move/resizing" by pressing ESC/Enter, this becomes extremely problematic when connecting from the outside, since there's no way to "cancel" (even xdotool hangs).

To Reproduce
As far as I noted, there's an easy way to test this on the server itself, there's no need for an external connection:

1. Login with IceWM as Desktop Environment/Window Manager;
2. Switch to a TTY, perform the login;
3. Start x11vnc from the TTY (foreground mode);
4. Go back to the desktop, open a window and focus on it;
5. Press Alt+F7/Alt+F8 to start moving / sizing it;
6. Go back to the TTY and stop x11vnc with CTRL-C;
7. Re-run it again and observe it hanging;

Expected Behavior
When I decide to re-run x11vnc, it should not hang, it should run as normal and I should be able to go back to the VNC session, in order to cancel the window moving/sizing.

Screenshots
N/A

Desktop

• OS and version: GNU/Linux Debian Trixie (testing)
• Xorg version used: 21.1.14
• Wayland version used: N/A

Additional context
As already said, I'm not totally sure this is a bug with x11vnc, unfortunately, since other tools seem to hang to the same situation.
I'd like some help in order to correctly diagnose the problem and solve it, since it is very annoying.

[elluisian]

As another try, I tried to use "strace", here's where it hangs:

...omitted...
newfstatat(AT_FDCWD, "/etc/localtime", {st_mode=S_IFREG|0644, st_size=2641, ...}, 0) = 0
write(2, "19/11/2024 12:32:35 ", 2019/11/2024 12:32:35 )    = 20
write(2, "x11vnc version: 0.9.16 lastmod: "..., 56x11vnc version: 0.9.16 lastmod: 2019-01-05  pid: 268032
) = 56
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) = 3
connect(3, {sa_family=AF_UNIX, sun_path=@"/tmp/.X11-unix/X0"}, 20) = 0
getpeername(3, {sa_family=AF_UNIX, sun_path=@"/tmp/.X11-unix/X0"}, [124 => 20]) = 0
uname({sysname="Linux", nodename="omitted", ...}) = 0
access("/var/run/lightdm/root/:0", R_OK) = -1 EACCES (Access denied)
fcntl(3, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{iov_base="l\0\v\0\0\0\0\0\0\0\0\0", iov_len=12}, {iov_base="", iov_len=0}], 2) = 12
recvfrom(3, 0x556cd5195ec0, 8, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}], 1, -1)

The same happens with tools such as "xdotool".
I guess somehow, the Alt-F7/F8 blocks something? What's that?

[elluisian]

The only workaround I found, for now, is to use the 'forever' option and keep the program in background, so that it doesn't stop accidentally.

To start the server (other parameters may be used):

sudo x11vnc -forever &

To stop it:

sudo x11vnc -R stop

If it doesn't work, just kill it:

sudo killall x11vnc # 'sudo killall -9 x11vnc' if the previous is not working

Of course, before stopping the server, BE SURE To stop moving/sizing windows.

Still, I'd be glad for some contribution in finding out what the problem might be and how to solve it properly.

[elluisian]

Better yet, to start the server, a combination of nohup and disown may be used, so that if ssh accidentally goes down, everything is fine:

sudo nohup x11vnc -forever & disown

[elluisian]

Unfortunately even with this setup, the bug might happen while grabbing/sizing windows by using a pointer device... so, even WITHOUT using ALT-F7/F8...
What's worse, I'm not able to replicate it reliably, sometimes it happens, but sometimes not.

While this is another bad news, I've finally figured out a way to actually "unlock" this situation while being on a remote computer, WITH NO ACCESS to the physical one.

What you need is 'ydotool' (you read correctly 'ydotool', not 'xdotool').
As I've said in the previous comments to this issue, xdotool hangs, since it tries to talk to X11, but fails for some reason, but not 'ydotool', since this works by using the uinput Linux kernel module to interact (so, X11 is bypassed).
This means that it works whatever the environment is, be it X11, Wayland or the TTY.

There's a github repository for ydotool (https://github.com/ReimuNotMoe/ydotool), so yeah, you can use that to inject an ESC o ENTER key, this way, the window movement gets stopped.

Still, it would be nice if the bug were to be solved without the need to use this kind of workaround, since this can get very annoying.
I've not tried to determine if the problem can be avoided if using the keyboard only (this might be possible with the use of keynav, found at https://github.com/jordansissel/keynav).

[Signy13]

I have been struggling with this bug for many years on Xubuntu (even with XFCE 4.18, the current version for Xubuntu 24.04).
In my case VNC viewer hangs while moving or resizing a window. If I can click on the machine with its physical mouse (or press ESC key on its keyboard), VNC starts working again (and it stars moving with mouse - probably movement in its buffer while is frozen).

I tested the approach with ydotool (installed as a system service) but without success.
With working VNC, when I am have another SSH connection to the machine, I can simulate ESC keypress (ydotool key 1:1 1:0) or type text (ydotool type "Some text") and I can see results through connected VNC client.
Once it freezes (because of moving or resizing a window), I can use ydotool key 1:1 1:0 or ydotool type "Some text" (in the SSH again) and I do not see any difference - it is still frozen as if nothing happened (and the typed text does not appear anywhere).
I can not figure out how come ydotool worked for you and not for me.

I found similar problem here https://gitlab.freedesktop.org/xorg/xserver/-/issues/862
where there is a problem with XGrabServer(display). It seems that while the VNC client freezes, XGrabServer(display) (called by window manager so moving/resizing the window would not be iterrupted) blocks all attempts to open new display XOpenDisplay(displayName).
That is probably the reason why xdotool etc. do not work - because the frozen X display it is blocked by X server so nothing can interfere. That is also the reason why X11vnc is not able to connect to the session again - opening the display XOpenDisplay(displayName) is blocked by XGrabServer(display), until its not cancelled by XUngrabServer(display).
I have not found any way how to call the XUngrabServer(display) outside: I wrote a simple program, which should call XUngrabServer(display), but it freezes when it tries to XOpenDisplay(displayName) and waits.

[elluisian]

@Signy13 Hi, thank you for the response and wow, that would explain a lot of things, honestly, I tried looking at Xorg, but I gave up pretty soon, since I had zero knowledge on it.
Nice to know though what the problem might be, but at this point, a question arises... is it a Xorg problem or a x11vnc one?
Weirdely enough, this problem never happened to me with TigerVNC server, but it does happen if I use X0tigervnc (TigerVNC's counterpart to x11vnc).

As for ydotool, I can confirm it works well for me as I use it very often (though, not as often as the standard TigerVNC server).
Please consider that I'm using IceWM as desktop environment, I used to use XFCE4 in the past and I'm pretty sure the former is very barebones in comparison, so I wouldn't be surprised by XFCE4 causing troubles.

If I remember correctly I had problems with it too, but I'm not sure.
Oh yeah, now I remember, you said you installed it as a system service, well, that did not work for me also.
What worked was installing it in /usr/local with GNU stow (this tool is not mandatory), then, I edited /etc/rc.local and added the line:

/usr/local/stow/ydotool/bin/ydotoold --socket-path=/tmp/.ydotoold_socket >/dev/null 2>/dev/null 

Finally, I set the aliases in .bashrc or similar:

alias ydotool='sudo YDOTOOL_SOCKET=/tmp/.ydotoold_socket ydotool'
alias x11vnc-unlock='ydotool key 1:1 1:0'

I configured sudoers so that I don't need to use a password for that ydotool command.
Whenever I need to "unlock" x11vnc, I simply type x11vnc-unlock.
This works on Debian Trixie (testing).

I know rc.local is not recommended nowadays, but I still have problems dealing with systemd services.
Actually, if anyone can improve this solution of mine, well, that's a good thing.