Troubles with EnableLockScreen

[ednaiul]

Hi everyone,

We have some problems trying to configure the “EnableLockScreen” feature.

We have installed the NoMachine Enterprise Desktop (v6.8.1) into our SLES 12 SP3 VM. The service is working fine, as we are able to access the physical desktop from a NoMachine client.

The problem is that, after the disconnection of the NoMachine client, instead of locking the physical desktop with the native lock screen, sometimes it shows a screen saver instead, which reports “User: nx@<hostname>” and asks for a password.

The problem is that the password requested seems to be for the “nx” user, which is the user assigned to the service and not the user used to access with the NoMachine client. This provokes that the physical desktop gets locked unless a reboot is made.

Our expected behaviour is that each time all NoMachine connections are closed, the screen is always locked with the user logged and using the GDM lock screen.

What are we doing wrong?

Best regards and thanks in advance,

Ednaiul

[kroy]

We couldn’t reproduce this problem. Which Desktop Environment do you use and which screensaver? If you try to lock screen manually inside the session are you reproducing this behaviour?

[ednaiul]

Thanks for your quick reply Kroy

We’re using GNOME Version 3.20.2, and the only screensaver package installed is xscreensaver 5.22. However, if I execute the following command on a console:
$ screeensaver-command -version

The answer is the following:
xscreensaver-command: No screensaver is running on display :0

So it seems that gnome is not using a screensaver, which makes sense as searching the graphic options this feature doesn’t appear (is not included).

When we lock the user session using the gnome option in the user menu (where “Log out” and “switch user” are located), the usual GDM login screen appears requesting the password for the correct user (as well as the option to Log in as another user).

Maybe NX is calling to a different desktop environment or xscreensaver?

[Gega]

Hello ednaiul,

Logs might help to identify your issue, so please enable debug, than reproduce your problem, collect and send logs to us. This article shows how to collect logs: https://www.nomachine.com/DT10O00163

Please submit them to forum[at]nomachine[dot]com putting the title of your topic as the subject.

[ednaiul]

Hi Gega,

Today we’ve repeated our scenario to generate the requested logs (which have been already sent to the e-mail address provided).We have checked the nxserver.log and the nxerror.log and we have determined that the issue is around the datetime 2020-02-10 10:06:25.

A few messages that could lead to the solution could be:
2020-02-10 10:06:25 453.810  3326 NXNODE   Cannot lock screen using dbus message. Trying to use screen lock application.
2020-02-10 10:06:56 705.600  3326 NXNODE   WARNING! Lock screen command finished with error ‘xscreensaver-command: no screensaver is running on display :0\n’.
2020-02-10 10:08:29 041.891  3326 NXNODE   WARNING! Process ‘/usr/bin/xdg-screensaver lock’ with pid ‘4349/4349’ finished with exit code 4 after 0,078 seconds.
2020-02-10 10:08:29 042.608  3326 NXNODE   nxProcessCreate: ‘/usr/bin/xlock’ ‘/usr/bin/xlock /usr/bin/xlock’ ‘DISPLAY=:0 HOME=/var/NX/nx XAUTHORITY=/usr/NX/var/log/node/C-ttcf-sv-mcu-1001-76769C47615E9631BAA73D1386A97DC5/authority XDG_SESSION_ID= XDG_SESSION_PATH=’ ’18’ ’24’ ’24’ ‘101’

[Gega]

It’s not clear why we aren’t able to lock with dbus, but problem here is this part: HOME=/var/NX/nx, nxnode is run as desktop owner so home directory should be desktop owner’s home directory, so HOME shouldn’t point to /var/NX/nx, Are you maybe using UserNXDirectoryPath? It could be related to problem described in this TR: https://www.nomachine.com/TR09Q09406

If that’s the case, then updating could help.

[ednaiul]

Hi Gega,

We are not using Virtual Desktops, and the value of the UserNXDirectoryPath is set to the default value (“”). It seems like, after the disconnection of the last user, something “forgets” the logged user and falls back to the information of the nxserver service user (“nx”).

In the other hand, when the “default” locking mechanism fails (xdg-screensaver lock), it seems to try with a different one (xlock).

I’m a bit confused about this, because we have still not been able to define the exact steps to reproduce the problem. Also, in some cases, the xlock screensaver is shown and in others not.

 

[Gega]

Full logs could shed some light on what’s going on, so please send logs to forum[at]nomachine[dot]com set specify troubles-with-enablelockscreen as Subject.
It’ll be good to know what are steps to reproduce this issue and how often that happens. I’d like to see also effective user of all nodes, and might be better to see all processes related to NX, so please send output of:
ps -ef | grep nx
along with logs.

[ednaiul]

Full logs have been sent again to the provided e-mail.

Regarding the command, here you have the output:

nx        4978     1  0 09:41 ?        00:00:00 /usr/lib/systemd/systemd –user
nx        4981  4978  0 09:41 ?        00:00:00 (sd-pam)
nx        5096     1  0 09:41 ?        00:00:00 /bin/dbus-launch –autolaunch 38a12291fe576b5d1961376a5c129794 –binary-syntax –close-stderr
nx        5097     1  0 09:41 ?        00:00:00 /bin/dbus-daemon –fork –print-pid 5 –print-address 7 –session
nx        6171     1  0 09:44 ?        00:00:00 /usr/bin/pulseaudio –start –log-target=syslog
nx        8835     1  0 10:04 ?        00:00:08 /usr/NX/bin/nxserver.bin –daemon
root      8972  8835  0 10:04 ?        00:00:00 /usr/NX/bin/nxexec –node –user nx –priority realtime –mode 0 –pid 11
nx        8976  8835  0 10:04 ?        00:00:00 /usr/NX/bin/nxd
nx        8984  8972  0 10:04 ?        00:00:00 /usr/NX/bin/nxnode.bin
nx        9026  8984  0 10:04 ?        00:00:00 /usr/NX/bin/nxclient.bin –monitor –pid 4820

[Gega]

Are you logged into system as user ‘root’? Seems like we do have problem in that case, but it’ll need investigation to find if/how that could be fixed.

[ednaiul]

Yes, probably the trigger condition is to leave the physical screen with the “root” account logged. I cannot confirm, but in our tests the problem seems to appear only in that scenario.

[Gega]

Hello ednaiul

We’ve created TR for your case: https://www.nomachine.com/TR02R09553. Use the notify me utility to receive a notification when a fix has been released.

[ednaiul]

Thanks Gega, I’ll track the updates on that TR.

 

[Author]

Posts