Losing host session when client disconnects with screen blanking enabled

Forum / NoMachine for Linux / Losing host session when client disconnects with screen blanking enabled

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #45773
    florian
    Participant

    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

    #45810
    Britgirl
    Keymaster

    Is 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.

    #45870
    florian
    Participant

    UPDATE: 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 dead

    This 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.

    #45869
    florian
    Participant

    Is 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

    #46277
    Britgirl
    Keymaster

    Hi, 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.

Viewing 5 posts - 1 through 5 (of 5 total)

This topic was marked as solved, you can't post.