graywolf

[graywolf]

Hello, would you send a screenshot showing the elements that does not respond to clicks?

Would you try to change NoMachine options in file /Applications/NoMachine.app/Contents/Frameworks/etc/node.cfg:

DisplayServerExtraOptions "-oldeventapi 1"

Restart NoMachine server after the change. Does it change the behavior?

[graywolf]

Is (user1) liam’s desktop running with DISPLAY :0, actually?

Have you tried to logout/login user1 (liam)?

If that does not help, try to run xhost +local: in the liam’s desktop. Now user2 is authorized to use DISPLAY :0 and things
should work. To make that authorization for granted on any login, place xhost +local: in SDDM user session launcher /usr/share/sddm/scripts/Xsession: I’d do it just BEFORE line

exec $@

[graywolf]

Should be possible for user2 to spawn their own virtual desktops. Even when DISPLAY:0 belongs to user1?

Yes, it is possible although not recommended:
Why VirtualGL requires access to the display :0

I still cannot open a virtual desktop with user2. I received the error “the connection with the server was shutdown”

Would you check the output of startkde in this case too? Do these messages

Invalid MIT-MAGIC-COOKIE-1 keyNo protocol specified
[VGL] ERROR: Could not open display :0.

keep showing up?

[graywolf]

Virtual desktops are not available in the free edition of NoMachine. You need a product among the NoMachine Terminal Server family (NoMachine Workstation, for example).

[graywolf]

Search the system log for any error issued by Gnome: journalctl -b -0 | grep -i gnome.

[graywolf]

This is weird behaviour and we are investigating further. Are you using GDM as the display manager?

openSUSE comes with SDDM, so I guess it is the display manager in use in this case.

I found an openSUSE system with a similar issue: it looks a race condition prevents SDDM scripts to enable local access to
the X server. So let me provide the following tips:

1. Check the script /etc/X11/xdm/Xsetup
If VirtualGL setup changed it correctly, the command:
xhost +LOCAL:
is placed at the beginning of the script.

2. In that case, change the Xsetup script to add 5 seconds delay to the
xhost command (waiting in background):

( sleep 5; xhost +LOCAL:) &

3. Repeat steps 1 and 2 for script /usr/share/sddm/scripts/Xsetup

4. Restart sddm:
systemctl restart sddm

5. Try again to get a virtual desktop

6. Retry DISPLAY=:0 xhost, in the remote session. Output should be:

access control enabled, only authorized clients can connect
LOCAL:

[graywolf]

You have more choices:

1. Configure the X server of the remote computer in order to run without any monitor attached (headless)
Or
2. Use a dummy display dongle to simulate the precence of a monitor connected to the remote computer
Or
3. Turn display manager off in the remote computer (sudo systemctl stop display-manager): that would let NoMachine launch its own virtual display on demand.

[graywolf]

It is possible the issue you reported is related to the way macOS handles “Spaces” and “Screens”: in order to get an app window spanning multiple displays, deselect the option ‘Displays have separate Spaces’ in the Mission Control pane of System Preferences.

[graywolf]

Do you mean that switch “Full screen on all screens” does not work as expected or the switch is completely missing?
Would you tell me which version of NoMachine client and server are you using?

[graywolf]

Hello. Likely this could help you: Fullscreen On All Screens

[graywolf]

Would you remove symlink /usr/NX/lib/libstdc++.so.6, restart the server and see if something changed?

Would you provide the output of commands

sudo dpkg -l libstdc++\*
sudo dpkg -L libstdc++6

and the file /usr/NX/var/log/nxinstall.log ?

Thank you.

[graywolf]

Yes, sharing multiple Wayland screen is not supported, but it will be soon. See : Sharing of multiple monitors is not supported with Wayland desktops

Check “Notify me” to get a notification when the fix is released.

[graywolf]

Thanks, that is very useful.

Would you send the log file at /usr/NX/var/log/node/C-challenger.aps.anl.gov-1001-53D4418C3D3EDA98900CF407B5AD065D/session ?

Do you mind retrying with a debug library in order to gather more information? In that case, please write to forum (at) nomachine (dot) com to receive instructions.

[graywolf]

As we know the memory chunk size, you could try to catch the allocation, using gdb:

1. Restart NoMachine to have a fresh nxnode.bin process
2. Attach to nxnode.bin (replace NNNN with process ID):
# gdb -p NNNN
3. In gdb, Insert breakpoint:
(gdb) b mmap64 if $rsi=47244640256
4. Let process run:
(gdb) c
5. Connect to server using NoMachine client. gdb will hit the breakpoint and start waiting for commands: ask for backtrace:
(gdb) bt
6. Print the id of file descriptor that is going to be mapped. At this point it should be in register R8:
(gdb) p $r8
7. Keep process suspended. Without closing gdb (use a different terminal) query file descriptors with lsof and inspect results searching for the one found in $r8 with gdb:
# lsof -p NNNN
8. After you gathered info, you can quit gdb:
(gdb) q

[graywolf]

Hello. What about screen size? Are you able to change that through the NoMachine client interface?

Do the affected desktop run over Wayland? (A quick way to check: search for processes with “wayland” in the name: ps -ef | grep -i wayland).

[Author]

Posts