light-locker breaks x11vnc as service

Bug #1287171 reported by koegs
170
This bug affects 34 people
Affects Status Importance Assigned to Milestone
light-locker (Ubuntu)
Opinion
High
Unassigned

Bug Description

1. Using x11vnc as service to have it running on the login screen via /etc/init/x11vnc.conf:

start on login-session-start
script
/usr/bin/x11vnc -xkb -auth /var/run/lightdm/root/:0 -noxrecord -noxfixes -noxdamage -rfbauth /etc/x11vnc.pass -forever -bg -rfbport 5900 -o /var/log/x11vnc.log
end script

2. Use light-locker instead of xscreensaver to lock the screen
3. Not able to use vncviewer to see the lock-screen

4. If PC is unlocked locally, x11vnc is able to display the screen again

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: light-locker 1.2.0-0ubuntu1
ProcVersionSignature: Ubuntu 3.13.0-14.34-generic 3.13.5
Uname: Linux 3.13.0-14-generic x86_64
ApportVersion: 2.13.2-0ubuntu5
Architecture: amd64
CurrentDesktop: XFCE
Date: Mon Mar 3 14:22:04 2014
EcryptfsInUse: Yes
InstallationDate: Installed on 2014-02-27 (3 days ago)
InstallationMedia: Xubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140225)
SourcePackage: light-locker
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
koegs (koegs) wrote :
Revision history for this message
koegs (koegs) wrote :

x11vnc log attached

Revision history for this message
Sean Davis (bluesabre) wrote :

I've subscribed the core developers to this bug.

Revision history for this message
diabloneo (diabloneo) wrote :

I confirm this bug

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in light-locker (Ubuntu):
status: New → Confirmed
Revision history for this message
Pavel Podkorytov (tierpod) wrote :

Light-locker + vino-server = same problem. I have only black screen with mouse point on the lock screen via vnc-client.

Revision history for this message
Fabio Rossi (rossi-f) wrote :

same problem here using xubuntu 14.04 and x11vnc.

The x11vnc service is started with lightdm using the greeter-setup-script configuration directive:

[SeatDefaults]
greeter-setup-script=/usr/bin/x11vnc -shared -display :0 -auth /var/run/lightdm/root/:0 -rfbauth /etc/x11vnc.passwd -forever -bg -rfbport 5900 -o /var/log/x11vnc.log

Revision history for this message
Simon Steinbeiß (ochosi) wrote :

Frankly I'm not sure light-locker *can* even work with a service such as VNC, as it switches to a new VT / X11 session when locking the screen (with lightdm).

Revision history for this message
Jens Berke (jensberke) wrote :

I use ssvnc as a client and am able to connect to a password protected x11vnc service. ssvnc offers me a black screen to enter the x11vnc login credentials, it accepts these credentials but then *bypasses* (!) the lock screen of the remote desktop and immediately shows me the remote desktop! However, I'm not able to use the remote desktop with mouse or keyboard in any way (ssvnc is definitely not configured to connect read-only).

The same setup using x11vnc and ssvnc had worked before with Ubuntu 13.10.

Revision history for this message
Jens Berke (jensberke) wrote :

Possibly duplicated by bug #1309418?

Revision history for this message
Chris Fester (camaronut) wrote :

Is there a workaround for this? I tried ssh-ing into the machine and killing the X server process on vt8, but it just re-spawned.

Revision history for this message
Simon Steinbeiß (ochosi) wrote :

The workaround is to not use light-locker for screenlocking, as it does VT switches.
Killing the other xserver process obviously won't help, because that's where the (lightdm-)greeter sits that is expecting authentification.

Revision history for this message
Benjamin J Norton (leomcsnarf) wrote :

Not sure if this was exactly my problem but I always try to see if someone already opened a bug.....
I was using light locker and when I closed my laptop and opened it again... I would log back in, the login screen went off but it didn't come back on. I am guessing that it did log me back in but the screen stayed off.

For me it fixed it to install intel graphics driver via: https://01.org/linuxgraphics/downloads/2014/intelr-graphics-installer-1.0.5-linux after installing their driver, light locker works fine.

Revision history for this message
dbp (dbpalan) wrote :

This bug is confirmed due to switching VT to provide the locking features. Below is a temporary solution by running a script to detect the active VT and restart VNC server to attach to the active VT periodically.

    #!/bin/bash
    #
    # This script will (re)attach VNC to the active VT of running X11 session locked with light-locker
    #
    # Author: dbpalan (A)(T) hotmail (D)(O)(T)(C)(O)(M)
    #
    # Licence: GNU GPL 2.0
    #
    # Problem: light-locker switch VT to perform the lock screen features, this inhabit x11vnc to attach to active VT
                            Reference: https://bugs.launchpad.net/ubuntu/+source/light-locker/+bug/1287171
    # Solution: Run a background script to detect active VT and force x11vnc to (re)attach to the active VT, this requires relogin to VNC, but still do the work
    # Usage:
    # 1. Setup VNC password by "vncpasswd /etc/vncpasswdfile"
    # 2. Run this script by "xxx.sh"
    # 3. Connect via any VNC client (screen either lock or unlock is ok)

    vncpasswdfile=/etc/vncpasswdfile
    vtpath=/var/run/lightdm/root
    vtuser=:0
    vtlock=:1

    vtlast=$vtlock
    switch=true
    while (true); do {
            if [ "$vtlast" == "$vtuser" ]; then {
                    if [ -e "$vtpath/$vtlock" ]; then {
                            switch=true
                            vtlast=$vtlock
                    }; fi
            } else {
                    if [ ! -e "$vtpath/$vtlock" ]; then {
                            switch=true
                            vtlast=$vtuser
                    }; fi
            }; fi
            if [ "$switch" == "true" ]; then {
                    killall x11vnc > /dev/null 2>&1
                    killall -9 x11vnc > /dev/null 2>&1
                    x11vnc -display $vtlast -forever -noxfixes -rfbauth $vncpasswdfile -auth $vtpath/$vtlast > /dev/null 2>&1 &
                    echo "Switch to $vtlast ..."
                    switch=false
            }; fi
            sleep 5
    }; done

Revision history for this message
denixx baykin (denixx-baykin) wrote :

If I understood, it is a x11vnc problem? Am I right?
Is light-locker behavior appears anywhere in other screenlocker?
This bug is my main reason to stay at xubuntu 13.10, which is already reached end of support (I don't think it is a good idea to use workaround above - it is a "duct tape", I think). I'll be glad to use 14.04 LTS, but this bug forced me to downgrade (I'm glad I've made backups).
What can you say about importance of this bug?
Thanks.

Revision history for this message
Simon Steinbeiß (ochosi) wrote :

@denixx-baykin: You can always uninstall light-locker and use xscreensaver like in 13.10, so that's no definitive reason to stick to an EOL release.

Changed in light-locker (Ubuntu):
importance: Undecided → High
Revision history for this message
Quax Eros (quaxeros) wrote :

Same problem here.
Additionally: I manage to connect with the display-update script (thanx for the solution!),
but my connection with ssvnc crashes the lightdm(-gtk-greeter) within a few seconds and thus X-server and the session.
Restarting lightdm refuses any vnc afterwards. Restart needed.
Still lookin' at the logs to learn more.
I run a desktop Lubuntu 14.04 LTS and a laptop Ubuntu 14.04 LTS and they both have the same problem.

Revision history for this message
noizo (noizo) wrote :

Can confirm this issue.
Script above did not helped me.

All it does

sh vnc.sh
vnc.sh: 9: [: :1: unexpected operator
vnc.sh: 20: [: true: unexpected operator

Thats the script

#!/bin/bash
vncpasswdfile=/etc/x11vnc/passwd
vtpath=/var/run/lightdm/root
vtuser=:0
vtlock=:1
    vtlast=$vtlock
    switch=true
    while (true); do {
            if [ "$vtlast" == "$vtuser" ]; then {
                    if [ -e "$vtpath/$vtlock" ]; then {
                            switch=true
                            vtlast=$vtlock
                    }; fi
            } else {
                    if [ ! -e "$vtpath/$vtlock" ]; then {
                            switch=true
                            vtlast=$vtuser
                    }; fi
            }; fi
            if [ "$switch" == "true" ]; then {
                    killall x11vnc > /dev/null 2>&1
                    killall -9 x11vnc > /dev/null 2>&1
                    x11vnc -display $vtlast -forever -noxfixes -rfbauth $vncpasswdfile -auth $vtpath/$vtlast > /dev/null 2>&1 &
                    echo "Switch to $vtlast ..."
                    switch=false
            }; fi
            sleep 5
    }; done

My startup script is.
x11vnc -xkb -noxrecord -noxfixes -noxdamage -display :0 -auth /var/run/lightdm/root/:0 -forever -shared -bg -o /var/log/x11vnc.log -rfbauth /etc/x11vnc/passwd -rfbport 5900

Revision history for this message
VeganTommy (vegantommy) wrote :

I found this thread trying to remote access a Lubuntu workstation and make vino-server start at boot. unfortunatly, i could not get it yet. http://ubuntuforums.org/showthread.php?t=2264563

My workaround secure solution would be to set an autologin at boot, schedule a session lock 10 seconds later to locally secure the workstation and find a way to be able to remote desktop with vino as the session is locked. actually, i get a black screen when the Lubuntu locks.

So i think i may be also affected by this bug.

Revision history for this message
Josh Mckibbin (joshmckibbin) wrote :

Same issue on Xubuntu 14.04.3. VNC works flawlessly until the screen is locked, then a black screen.

Revision history for this message
Nick C (nick.c) wrote :

Still happening in Ubuntu 16.04.1 LTS (64-bit).
x11vnc is broken by lightdm/lock screen. If the local user's session times out, you can log in with x11vnc but the desktop is in a 'static' state where clicking on anything is not possible.

Revision history for this message
Claudio (claudio-fischer) wrote :

seems this has to do something with Unity and 3D acceleration.
I can confirm this bug in Ubuntu 16.04.1 LTS (64-bit).

I can log in to Ubuntu 16.04.1 running x11vnc without 3D acceleration.

How you can try this:

1) setup a virtual Ubuntu 16.04.1 in VirtualBox or VMWare (which one does not matter)
2) enable 3D acceleration for the guest Ubuntu and install x11vnc
   => you wont be able to log in after reboot or if lock-screen activates
3) disable 3D acceleration for the guest Ubuntu, it will use a fallback graphic mode.
   => now you are able to log in with vnc without problems

Revision history for this message
rad0n (rad0n) wrote :

This bug affects me, too.

Easy workaround if mouse input still works:
- Choose to switch the user (will open up another screen)
root@mymachine:~# ps axu | grep X
root 3073 2.1 2.2 229824 89520 tty7 Ssl+ 12:25 0:17 /usr/lib/xorg/Xorg -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
root 9081 2.8 1.1 101696 44216 tty8 Ssl+ 12:38 0:00 /usr/lib/xorg/Xorg -core :1 -seat seat0 -auth /var/run/lightdm/root/:1 -nolisten tcp vt8 -novtswitch

- start another x11vnc
root@mymachine:~# x11vnc -display :1 -geometry 1400x783 -nopw -auth /var/run/lightdm/root/:1
- connect to that with 'vncviewer ip:5901' (new port)
- login onto the same account
- other vnc session gets automatically unlocked

Revision history for this message
Nick C (nick.c) wrote :

Let me add a "research" bump to this - the black screen also happens if you're trying to use the built-in Desktop Sharing functionality in 16.04.1 as well, and (at any point) you switch user accounts.

It seems to really boil down to switching user accounts and the lock screen; it's not just an x11vnc issue but again also happens to a stock/up to date 16.04.1 machine even with just 1 user account after enabling Desktop Sharing.

Here's how to reproduce:
1) Enable Desktop Sharing, options don't really matter here. (You can give view-only, or you can allow control.) Confirming access, password, none of this matters.

1a) If you're connecting from a Windows machine using TightVNC Viewer, RealVNC Viewer, or UltraVNC Viewer, you'll have to disable encryption on the Ubuntu host. Simplest way to do this is pull up Terminal (admin/root not required) and execute: gsettings set org.gnome.Vino require-encryption false
Otherwise your Windows client will not understand the encryption and fail to connect. (See also: http://ubuntuhandbook.org/index.php/2016/07/remote-access-ubuntu-16-04/)

2) Connect to the Ubuntu [shared] host; I've used both RealVNC Viewer and UltraVNC Viewer.

3) After connecting and having the Ubuntu host in a VNC connection window, with control (or at the Ubuntu host keyboard), switch to the 'Guest Session' user. [You don't even need more than 1 user on the machine, just switch to a Guest Session.]

4) Your VNC window will now either still show the user's desktop (as it was) but it will be static and you will not be able to manipulate it

* OR *

Your VNC window will now be a black, blank screen.

Your Ubuntu host, however, will be at the Guest Session user screen.

Whether you disconnect and re-connect with your VNC application, it does not matter. You still have a static or black screen you cannot do anything with.

5) Log out of the Guest Session, which will return you to the lock screen where you can enter your user account's password. If you connect prior to logging in with your VNC client, you'll still have a static/black screen. However, after you type the user password to re-log in to the desktop at the Ubuntu host, you will be able to control (or view) from the VNC guest again.

I was hoping to use Desktop Sharing in lieu of using a different VNC Server in 16.04.1, however, that will obviously not work.

I have also tested this in Ubuntu MATE 16.04.1 and found all the above is still true.

Maybe I'm spoiled in Windows world, using UltraVNC Server on my Win7 boxes and being able to switch from user account to user account with no issues (other than a slight delay while the Windows login/user switch screen comes up and goes away). Maybe this is something out of spec for what Ubuntu is capable of.

I just wanted to share this in the hopes that a fix is finally found, since again, this is NOT only related to x11vnc as I think people initially thought. In that regard, if I need to post a new thread for this bug somewhere else, or my post needs to be moved accordingly, feel free to do so.

Revision history for this message
Nick C (nick.c) wrote :

Here's a picture of what happens.
UltraVNC Viewer on Windows host on left, connected to guest VM of Ubuntu 16.04.1
Actual Ubuntu guest VM on left running in VirtualBox

At this point, I'm showing you that the VNC Viewer is static, left, while the actual OS itself has "moved on" to the Guest Session desktop, right.

Once Guest Session logs out and I re-enter 'administrator' user account's password in Ubuntu, the VNC window becomes active again and can be manipulated.

(Hopefully I'm explaining this in enough detail.)

The reason I'm demonstrating this in a VM is because I no longer dual boot Ubuntu at home (but yearn to, immensely - I'm done with Microsoft). The reason this causes me issues specifically is I'm "dad" in a household of 4. My kids are on and off the computer all day. If one of my daughters goes to her desktop, leaves it, and I connect via VNC tunneled over SSH (from work) like I typically do, I have a dead/unusable session at work because my physical home machine is still on my daughter's desktop while my VNC session is pulling up my 'static' desktop which is for all intents and purposes, "dead" and inactive.

Revision history for this message
Alex R (abr28) wrote :

This is not specific to x11vnc. I'm experiencing this when using Xvnc too (i.e. starting a new X session on :1 or some other display). In my case 'Xvnc' is provided by the 'tigervncserver' package.

The restarting+reattaching trick won't work in this case. Is there any workaround for Xvnc? Do all screen-locks change screens when locking?

Revision history for this message
Nick C (nick.c) wrote :

One thing I've found that bypasses this and works is using X11 Forwarding over SSH (now using Ubuntu MATE though it should work for any flavor, regardless of DE).
Using that allows me to open my apps remotely, without having to worry about the desktop session and whether I can interact with it or not. The apps I use just open on my remote machine (which, in Windows' case, are running Xming Server to handle the X11 display).
I did have a hiccup with some apps not working and resulting in a segfault (core dump), but I've found the culprit there - due to the NVIDIA drivers and needing to put a symlink in /usr/lib/x86_64-linux-gnu. (http://askubuntu.com/questions/795418/open-gui-apps-on-a-ubuntu-16-04-machine-via-ssh-from-an-ubuntu-14-04-machine) Now, those apps open as well on my remote machine via X11 Forwarding.
Really neat stuff. :)

Revision history for this message
Theo Linkspfeifer (lastonestanding) wrote :

As stated in comments #8 and #12, this is not a bug in light-locker.

Changed in light-locker (Ubuntu):
status: Confirmed → Opinion
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.