No keyboard input accepted after logging in

[MrBombastic]

Hi

I use NoMachine infrequently, but when I do it has worked fine.

However, today when I tried to reconnect to a NX session that I left running from my (Suse Leap 42.2) PC overnight, the keyboard did not work.  The mouse worked perfectly as normal.  I’ve spent over 2.5 hrs trying to work it out, doing the basics like stopping the NX server and restarting it.  I even just upgraded both the server and client to the latest version to no avail.  I’ve googled extensively but many threads are never revisited by the opener.

I installed and tested from both the IOS and Windows versions and the keyboard still did no work.  Given that the problem exists from 3 different clients running different operating systems, the issue must be server side.

Server is  SUSE Linux Enterprise Server 11 (x86_64) SP3 running Gnome 2.28.2 and NoMachine 6.0.78_1_x86_64.rpm (free version).  I believe I am using a physical display, but now can I be sure?  Whenever I connect it says “Cannot detect any display running?  Do you want NoMachine to create a new display and proceed to connect to the desktop?”

Can anyone offer any ideas on what to try next to get the keyboard working again?

MrB

[graywolf]

To check if a physical display is available, you can search for running “X” process:
ps -ef | grep X
Search for “X” or “Xorg” among results.

Virtual sessions use nxnode.bin as display server, search for them using nxserver –list and ps:
/usr/NX/bin/nxserver --list
ps -ef | grep nxnode

If session is still running and you’d like to try to recover, killing all the running grabs could be useful.
Access the remote host using the same account owning the graphical session.
Using the proper display number (it should be :0, but check the Xorg command line with ps) setup the xkb map:
DISPLAY=:0 setxkbmap -option "grab:debug" -option "grab:break_actions"
Check the result:
DISPLAY=:0 xprop -root | grep XKB
Now you can list the grabs sending keystrokes through xdootol:
DISPLAY=:0 xdotool key XF86LogGrabInfo
Output will go into file /var/log/Xorg.0.log
To cancel the grabs or kill the grabbing programs:
DISPLAY=:0 xdotool key XF86Ungrab
DISPLAY=:0 xdotool key XF86ClearGrab
See the results:
tail /var/log/Xorg.0.log
[ 1951.330] Ungrabbing all devices and killing their owners; grabs listed below:
[ 1951.330] End list of ungrabbed devices

If you tried anything without success, you could restart the display manager or reboot the server machine, but that would kill any job you were running in the graphical session. If you decide for that way, switching to runlevel 3 would kill display manager, runlevel 5 will bring it up:
init 3
init 5

[MrBombastic]

I checked the processes with no NoMachine session running and it shows this:

`fs1:/var/log # ps -ef | grep X
nx        4361     1  0 Feb20 ?        00:00:01 /usr/NX/bin/nxserver.bin root 1 –daemon
nx        4689  4361  0 Feb20 ?        00:00:00 /usr/NX/bin/nxd
root     14717 61184  0 00:12 pts/1    00:00:00 grep X
root     42442 42438  0 Feb20 tty7     00:00:13 /usr/bin/X :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-jWX4wY/database -nolisten tcp vt7`

The for comparison I started another NoMachine session and checked again…

fs1:/var/log # ps -ef | grep X
nx        4361     1  0 Feb20 ?        00:00:01 /usr/NX/bin/nxserver.bin root 1 –daemon
nx        4689  4361  0 Feb20 ?        00:00:00 /usr/NX/bin/nxd
nx       14006  4689  0 00:10 ?        00:00:00 /usr/NX/bin/nxserver.bin -c /etc/NX/nxserver –login -H 4
nx       14028  4361  0 00:10 ?        00:00:00 /usr/NX/bin/nxserver.bin –virtualsession –sessionid 6BEDD558F1C8BC5E5E54CEF499E45FD2
root     14043  4361  0 00:10 ?        00:00:00 /usr/NX/bin/nxexec –node –user root –priority realtime –mode 0 –pid 15
root     14048 14043  2 00:10 ?        00:00:02 /usr/NX/bin/nxnode.bin
root     14150 14048  0 00:10 ?        00:00:00 /usr/NX/bin/nxclient.bin –monitor –pid 14097
root     14251 14097  0 00:10 ?        00:00:00 /usr/bin/gpg-agent –sh –daemon –write-env-file /root/.gnupg/agent.info /usr/bin/ssh-agent /bin/bash /etc/X11/xinit/xinitrc
root     14254 14097  0 00:10 ?        00:00:00 /usr/bin/ssh-agent /bin/bash /etc/X11/xinit/xinitrc
root     14372 14006  0 00:10 ?        00:00:00 /usr/NX/bin/nxexec –node –user root –priority realtime –mode 0 –pid 14 -H 4
root     14379 14372  0 00:10 ?        00:00:00 /usr/NX/bin/nxnode.bin -H 4
root     14659 61184  0 00:12 pts/1    00:00:00 grep X
root     42442 42438  0 Feb20 tty7     00:00:13 /usr/bin/X :0 -br -verbose -auth /var/run/gdm/auth-for-gdm-jWX4wY/database -nolisten tcp vt7

Out of frustration I ended up rebooting the server and still there was no ability to use the keyboard, just the mouse.

Here is where it is even stranger, in a test NoMachine connection, as usual the mouse works perfectly, so I clicked to open Gedit (Gnome text editor) and was randomly pressing some keys in the vicinity of a,s,d,f, then suddenly I noticed a single ‘d’ in the Gedit document!?  Wow! but how?

VNC TESTING:

Interestingly connecting with VNC to displays :1 and :2 work fine.  VNC is started with xinetd on this server.

I thought I was on a sure thing by rebooting the server, but alas no.  Is it worth me attaching a NXserver config file?

 

[MrBombastic]

Luckily I had a backup (from August 2017) of the NoMachine config file fs1:/usr/NX/etc/server.cfg, so I restored it and restarted /etc/init.d/nxserver and now the keyboard entry from the NoMachine session works again!!

I guess I could have just removed NoMachine from the server and reinstalled it too, but this server.cfg file was much quicker to restore.

In switching to an older version of NoMachine server.cfg I ran a diff and there are quite a few differences between them.  Would it be detrimental to leave the old server.cfg file with a newer version of NoMachine?

[graywolf]

If it works for you, it is OK. Would you like to show me the diff, just to be sure?

[Author]

Posts