Forum / NoMachine for Linux / Losing host session when client disconnects with screen blanking enabled
- This topic has 5 replies, 2 voices, and was last updated 4 months ago by Britgirl.
-
AuthorPosts
-
October 24, 2023 at 09:18 #45773florianParticipant
Hi all,
my situation/issue is the following, while “blank screen” and “lock screen on disconnect” on Linux host is enabled:
If I connect to the host, I see the Debian login screen. If I log in there, I unlock the previously locked session on the host (if one exists, what is the case in 99% of the cases in my situation).
When I disconnect from the host, regardless if I lock the host sessions first or just close/disconnect the client player, the host machine not only locks the host session and un-blanks the screen, it looks like it does a logout from the host session, meaning that all windows and applications are killed on the host.
Is there a way to configure the disconnect to do a lock only?
Basically, I would like to have the host session running all the time, supporting unlocking/locking on host or from remote in the same session all the time.
Btw.: If I disable the “blank screen” setting, it actually does what I want, but I would prefer to have “blank screen” setting enabled.
Thanks!
Florian
October 26, 2023 at 17:38 #45810BritgirlKeymasterIs there a way to configure the disconnect to do a lock only?
Not sure what you mean here. Lock the physical screen is a separate setting from blank the screen.
It sounds like Xorg could be crashing. We investigated a similar issue to what you’ve described and the results of the investigation were that this behaviour is not triggered by the NoMachine software, but affects all the situations in which the X server “goes offscreen” (not just with NoMachine). What does the stacktrace of Xorg print? Is there a line like this [ 94029.825] (II) AIGLX: Suspending AIGLX clients for VT switch? Cases were reported on Debian/Mint and in one case one of the users reported that switching from XFCE desktop to KDE stopped the crash.
It was also reported in the forums, the users there made some Xorg updates.
"Lock the physical screen when somebody connects" session disappears
If it’s not that, it could be related to this known TR https://kb.nomachine.com/TR08U10994. We reproduced it on Cinnamon desktop. You can follow the workaround described in that link and tell us if it the problem stops.
October 31, 2023 at 13:40 #45870florianParticipantUPDATE: It’s even more easy to reproduce:
On nomachine remote connection:
* Click “Lock Screen”
* Keep NoMachine client connected and wait for login screen
* Login again
* X-Session is already deadThis means, that the actual disconnect of NoMachine session is not the problem, but pressing “Lock Screen” in combination with “blank out screens” is an issue.
Disabling popup did not fix the issue: https://kb.nomachine.com/TR08U10994.
October 31, 2023 at 18:38 #45869florianParticipantIs there a way to configure the disconnect to do a lock only?
Not sure what you mean here. Lock the physical screen is a separate setting from blank the screen.
I just wasn’t sure if the behavior I saw is a bug or a feature 😉
My problem is actually exactly the same as described here, but I’m using XFCE:
“Lock the physical screen when somebody connects” session disappears (https://forum.nomachine.com/topic/lock-the-physical-screen-when-somebody-connects-session-disappears)
Sadly, the recommended steps did not work for me as I have a newer Xorg.Xorg backtrace:
[1140316.034] (EE) Backtrace: [1140316.035] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x135) [0x55a0cd97e915] [1140316.036] (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x50) [0x7f111433b140] [1140316.036] (EE) 2: /usr/lib/xorg/Xorg (InitCallbackManager+0x2170) [0x55a0cd821b10] [1140316.036] (EE) 3: /usr/lib/xorg/Xorg (DeliverEvents+0x10ee) [0x55a0cd82b7ce] [1140316.037] (EE) 4: /usr/lib/xorg/Xorg (AssignTypeAndName+0x6ceb) [0x55a0cd90eb0b] [1140316.037] (EE) 5: /usr/lib/xorg/Xorg (SendErrorToClient+0x354) [0x55a0cd81a594] [1140316.037] (EE) 6: /usr/lib/xorg/Xorg (InitFonts+0x3b4) [0x55a0cd81e594] [1140316.038] (EE) 7: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xea) [0x7f1114175d0a] [1140316.039] (EE) 8: /usr/lib/xorg/Xorg (_start+0x2a) [0x55a0cd807d2a] [1140316.039] (EE) [1140316.039] (EE) Segmentation fault at address 0x28 [1140316.039] (EE) Fatal server error: [1140316.039] (EE) Caught signal 11 (Segmentation fault). Server aborting [1140316.039] (EE) [1140316.039] (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. [1140316.039] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. [1140316.039] (EE) [1140316.040] (EE) Server terminated with error (1). Closing log file.
xsession-errors:
cat .xsession-errors | grep -i error ** (xfce4-power-manager:2333947): WARNING **: 12:52:04.051: Failed to get name owner: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Cou ld not get owner of name 'org.xfce.PowerManager': no such name ** (xfce4-power-manager:2333947): WARNING **: 12:52:04.053: Failed to get name owner: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Cou ld not get owner of name 'org.freedesktop.PowerManagement': no such name ** (xiccd:2334129): CRITICAL **: 12:52:04.793: failed to create colord device: could not check org.freedesktop.color-manager.create-device for a uth: GDBus.Error:org.freedesktop.PolicyKit1.Error.NotAuthorized: Only trusted callers (e.g. uid 0 or an action owner) can use CheckAuthorization () for subjects belonging to other identities ** (xiccd:2334129): CRITICAL **: 12:52:04.793: failed to create colord device: could not check org.freedesktop.color-manager.create-device for a uth: GDBus.Error:org.freedesktop.PolicyKit1.Error.NotAuthorized: Only trusted callers (e.g. uid 0 or an action owner) can use CheckAuthorization () for subjects belonging to other identities (xfce4-power-manager:2333947): xfce4-power-manager-WARNING **: 12:52:04.995: Failed to get keyboard max brightness level : GDBus.Error:org.freed esktop.DBus.Error.UnknownMethod: No such interface “org.freedesktop.UPower.KbdBacklight” on object at path /org/freedesktop/UPower/KbdBacklight cat .xsession-errors | grep -i critical ** (xiccd:2334129): CRITICAL **: 12:52:04.793: failed to create colord device: could not check org.freedesktop.color-manager.create-device for a uth: GDBus.Error:org.freedesktop.PolicyKit1.Error.NotAuthorized: Only trusted callers (e.g. uid 0 or an action owner) can use CheckAuthorization () for subjects belonging to other identities ** (xiccd:2334129): CRITICAL **: 12:52:04.793: failed to create colord device: could not check org.freedesktop.color-manager.create-device for a uth: GDBus.Error:org.freedesktop.PolicyKit1.Error.NotAuthorized: Only trusted callers (e.g. uid 0 or an action owner) can use CheckAuthorization () for subjects belonging to other identities
Interestingly, the error happens each time, if I lock the remote screen manually before disconnecting the nomachine session. If I do not lock the screen and let the “lock screen on last user disconnect” do the locking job, the error happens less frequent or never.
Thanks,
Florian
December 11, 2023 at 10:05 #46277BritgirlKeymasterHi, the logs you pasted indeed show the same errors of the problem we investigated. The bug occurs in all situations in which the X server “goes offscreen”. We are, in any case, we are looking at ways we can work around this X.org bug by delaying the lock the screen after making sure the screen blanking is deactivated. So watch out for this in upcoming software updates.
July 16, 2024 at 15:55 #48808BritgirlKeymasterPlease try the latest 8.12 and tell us if you see some improvements.
The related Trouble Report which gives details about the issue is available here: https://kb.nomachine.com/TR02T10468
-
AuthorPosts
This topic was marked as solved, you can't post.