October 21, 2022 at 16:19 #40868
after upgrading from SuSE Linux Enterprise Desktop SP3 to SP4 we realized that NoMachine would not always lock the screen when nxplayer disconnects. We always connect to the physical screen.
1) When it first happened with ctwm and with xfce we restarted nxserver (without restarting the desktop session) after which locking an disconnection worked again. A while later I managed to collect a log where disconnecting from xfce didn’t lock the screen (with xlock), but the subsequent disconnects did, although we did not restart neither nxserver nor the desktop session.
2) We use kdm or sddm as login manager as gdm has some problems. With 15 SP3 nxserver would lock the screen also when using gnome as desktop (from kdm/ssdm). As the gdm screenlocked isn’t available with kdm/sddm, nxserver used xscreensaver if the user had started it or xlock otherwise. With 15 SP4, gnome desktops are never locked by nxserver when started from kdm or sddm.
This might be because the dbus name for the locking message has changed. With dbus-monitor I can see that the signals for locking the screen are still sent by nxserver, but while on SP3 (gnome-session-3.34) the message looks like
mc 1666360979.211103 2 :1.135 org.freedesktop.ScreenSaver /ScreenSaver org.freedesktop.ScreenSaver Lock
there are 3 messages in SP4:
mc 1666361095.639973 37 :1.63 org.gnome.Shell.ScreenShield /org/gnome/ScreenSaver org.gnome.ScreenSaver Lock
mc 1666361095.690794 2 :1.103 org.freedesktop.ScreenSaver /ScreenSaver org.freedesktop.ScreenSaver Lock
mc 1666361095.944046 42 :1.63 org.gnome.Shell.ScreenShield /org/gnome/ScreenSaver org.gnome.ScreenSaver Lock
I write a little python proxy and saw that only this variant would work:
session_bus = dbus.SessionBus()
os.system( "/usr/bin/touch /tmp/t3" )
I.e. using org.gnome.Shell.ScreenShield as service.BusName but /org/gnome/ScreenSaver for the Object and method. The ScreenShield name is new in Gnome 41.
So maybe NoMachine 8 is doing sth. wrong with sending the correct bus message? But it seems it doesn’t realize it because I cannot see any message (as has been in other issues with screen locking) that dbus failed and therefore a fallback to xlock would be used. NoMachine seems to thins that dbus locking went fine although it has no effect.
I send the logs for both cases if you want.
FrankOctober 24, 2022 at 18:12 #40915
Hi, thanks for the information, we are investigating and will come back to you.October 25, 2022 at 09:40 #40931og00rContributor
A while later I managed to collect a log where disconnecting from xfce didn’t lock the screen (with xlock),
Any chance for those collected logs? If possible I prefer logs from /home//.nx/
where is physical desktop owner when problem happen.October 25, 2022 at 10:50 #40934
Not sure if the debugging was set accordingly for the logs in user home, but I can send them together with the global nxserver.log so that you can filter the matching logs from the users home. Where do I send them?October 25, 2022 at 10:59 #40940
Please send to forum[at]nomachine[dot]com making sure to use the topic’s title as the subject of your email. Thanks!October 25, 2022 at 11:33 #40942
I will send them. In the meantime I detected another bug with SLE 15 SP4 that I can reliably reproduce: when using gnome as desktop (we don’t used gdm but kdm or sddm for login, I’m not sure if it’s related to that or not) it will start in a somewhat strange mode. It shows the “Activities” button and a search field and some icons at the bottom. But the background image is smaller and only when you click on it, it will maximize and show the usual desktop icons. I thinks that the workspace you must activate by this first click in gnome-session-41.3.
Anyway, in this initial state where the desktop is not yet clicked, NX will not even try to lock the screen when disconnecting. I tailed ~/.nx/nxserver.log and there appears no line at all when disconnecting, no matter how often I re- and disconnect. But as soon as I clock the background image and desktop appears and I disconnect, I will see messages about org.gnome.ScreenSaver and also my test script I quoted above will receive a signal again.
Do you want logs for that problem, too?January 2, 2023 at 10:21 #42259
You must be logged in to reply to this topic.