Forum Replies Created
-
AuthorPosts
-
graywolfParticipant
Please collect server logs for the troublesome case: https://www.nomachine.com/DT10O00163#1.1
March 4, 2020 at 17:47 in reply to: Configure an headless server with Nvidia GPU with option to plug in monitor #25869graywolfParticipantHello. I think rebooting is not necessary. In order to make changes effective, restarting the display manager is enough:
systemctl restart display-manager
.graywolfParticipantServer’s keyboard defaults to US.
You would setup DE keyboard in the server’s display:
setxkbmap -layout de
. Otherwise change it by the keyboard configuration preferences of the graphical environment on the server.February 12, 2020 at 10:08 in reply to: Cannot see desktop after updating Debian to Testing version #25613graywolfParticipantHello, please gather server side logs with command
/etc/NX/nxserver --debug --collect
. If you prefer, you can send the zip archive by email: forum at nomachine dot com.Please, also take the journal since the last boot:
journalctl -b -0 > journal.txt
.graywolfParticipantSo you have one virtual NoMachine display. You can check input with xev:
- Connect by NoMachine to the troublesome session.
- Connect by ssh to the NoMachine server and run this command to find the display number of the session and exporting to terminal:
export $(cat /proc/$(pgrep nxclient.bin)/environ | grep -z DISPLAY)
(there is only one session, so only one nxclient.bin) - Run the xev command in the ssh terminal. The xev white window will show up in the NoMachine session. Try to hover, click, type in the window. Check the results in the ssh terminal.
Then, you can list the apps grabbing the mouse/keyboard:
- Run the command
xdotool key XF86LogGrabInfo
in the ssh terminal. - Check the result in session log file. Find it with command
/usr/NX/var/log/node/C-*$(cat /proc/$(pgrep nxclient.bin)/environ | grep -z NX_SESSIONID | cut -f2 -d= )/session
- You can terminate the grabs with command:
xdotool key XF86ClearGrab
or kill the grabbing app.
graywolfParticipantIs it your server user session on Wayland or Xorg?
If it is Xorg, you could check if any mouse/keyboard grab is active when such loss of keyboard/mouse occurs.
graywolfParticipantI don’t know. It is possible perhaps configuring Xorg server to run over headless AMD card. If nothing else helps, using a fake display dongle cheating the video card would do the trick.
graywolfParticipantHello, it looks like your system goes into sleep or suspend state. There are multiple ways such feature is handled: it looks you could act on
- systemd targets
- kernel parameters
- Gnome shell settings
This topic looks a small collection of things you could try: How do I disable my system from going to sleep?
I would try with systemd target as first thing:
sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target
graywolfParticipantHello, likely a modifier got stuck in “key down” state. Should such issue occur again, press/release all Alt/Shift/Ctrl keys and let us know.
graywolfParticipantJimH24:
When I go to connect with NoMachine, today I need to choose amongst the following “Physical displays” on “Ubuntu X server”: 0, 10, 12-17.
Did you ever try display :0 ? Others look like X11-forwarded displays, not physical ones.
January 30, 2020 at 13:04 in reply to: Centos 7 – Menus and options on the GUI dont react to remote mouse inputs #25441graywolfParticipantHello,
Are the affected sessions run in NoMachine virtual displays? I guess they are as no physical screen is attached to the server.
Would you look at CPU and memory usage while the problem is occurring?
Would you send server logs?
Would you get the output of command “glxinfo” in the remote session?- This reply was modified 4 years, 11 months ago by graywolf.
graywolfParticipantXKEYBOARD extension is required to create a proper keymap. Display :11 is unusual, did you do any custom setup of X server?
graywolfParticipantopen a terminal and execute this command
Please, would you run also these, both in remote session as well as on client host:
xkbcomp -xkb $DISPLAY - > xkbcomp.out 2> xkbcomp.err
xprop -root | grep XKB > xprop.out 2> xprop.err
setxkbmap -print > setxkbmap.out 2> setxkbmap.err
and let me look at err, out files?
graywolfParticipantPhysical is OK: AgentX11VectorGraphics 0 is implicit in that case. Switching to “virtual” would not provide any leverage. If you want to try it anyway, just turn off Gdm display manager (systemctl stop display-manager): on the next try NoMachine will ask you if you want to create a virtual display server.
In my opinion, VM has not support for video acceleration (OpenGL renderer is llvmpipe, that is CPU renderer) so you get poor gnome performance. Would you consider a more lightweight desktop like Xfce? Otherwise you could try providing more CPU power to the VM in order to get a faster rendering by llvmpipe.
graywolfParticipantIt is good. What about “renderer” in the output from glxinfo (
glxinfo | grep -i renderer
)? Please be sure you issue the command remotely through NoMachine.How are DISPLAY vars set? Please run
env | grep DISP
Would you verify the kind of NoMachine session? With NoMachine connected to the remote host, press combo Ctrl+Alt+0 and chose Connection information; look at “session type”.
If the type is “virtual desktop” you can try to turn off X11VectorGraphics; in node.cfg, place:
AgentX11VectorGraphics 0
. See also this (applies only to virtual desktop session type): https://www.nomachine.com/AR02L00779 -
AuthorPosts