I have a machine that is setup with Leap 15.4, this was inplace upgraded from 15.3.
I tend to use xfce4 as my desktop as it is nice and lightweight.
I use this machine both locally with the keyboard, mouse & monitor and remotely via vnc.
I have remote management with session management turned on in yast2.
I’m using lightdm as a displaymanager as the default (sddm), doesn’t work with vnc.
There seem to be 2 problems with this setup :
I can’t setup a persistent session from a VNC terminal, whenever I run vncsession-controller, I get the message:
‘session is not running under vncsession exiting’. So I can’t setup a named session.
If I leave myself logged in via vnc, and then try to login on the console I get a segfault in xfce4-session :
This happens after I enter my password to unlock the console, it just loops round and asks for my password again.
At this point I can regain control by using ctrl-alt-f1 and logging in on the text console and restarting X with init 3 followed by init 5. After this I can then login again.
Does anyone have any clues as to what could be causing this?
This only happens if the VNC user is the same as the user logged in on the console. A new user is able to connect without problems.
The problem also manifests if two VNC sessions of the same user are started, but not if different users login.
This suggests to me that the problem is caused by access to a resource that is user related.
normal (non root user) at the login screen set their environment to xfce.
Login as on the machine’s x session, (on the machine’s keyboard video & mouse**).
Connect via VNC and try to login as the same user as is logged in on the machine.
Enter user’s password
At this point the VNC will disconnect with “failed to recv data from socket”, I’m using TightVNC under
windows. Just tried on vncviewer from another suse box and that also does the same.
I’m connecting the vncviewer / tightvnc to machinename:5901
I’ve tried this on two machines now, the one upgraded from 15.3 experiences the crash, as above
the other a fresh 15.4 install doesn’t experience the crash, but the session dies without connecting.
If I connect to the VNC session first, and then try loging in on the machine, that loops round back to
the login screen after entering my password.
**Didn’t want to say machine’s console as this might be confused with the text mode console
This lacks information about your display manager and step where VNC server is being started is missing. I cannot reproduce it with vncserver xorg-x11-Xvnc package (TigerVNC) where vncserver is started manually in user session after user logs in.
Display manager is lightdm, it was in the first post.
vnc server is IIRC started by vncmanager, I believe that is what happens when you select “allow remote administration with session management” in the VNC Remote administration in Yast.
I’m yet to be able to get vnc working through yast, I follow the documentation laid out here and it just never connects via the webpage (port 5801) or a vnc viewer (5901).
I can get vnc to work if I don’t use yast, but that is not the optimal solution here. I really feel like something is wrong.
Fresh install, XFCE window manager
start yast, enable remote management
Allow Remote Administration With Session Management, enable access with web browser, open firewall ports selected
reboot the machine
No access via website (which does pull up the novnc page) or VNC client.
I’ve tried over and over again, clean install, -nothing- else, just never works.
Did you remember to change the display manager, the default sddm, doesn’t work with VNC, you can change it in yast, under alternatives. I have mine set to lightdm.
Aug 03 11:45:34 localhost.localdomain lightdm[18592]: Error activating login1 session: GDBus.Error:org.freedesktop.DBus.Error.NotSupported: Operation not supported
The problem is, lightdm does not pass seat name to session child so pam_systemd (which runs as part of login process) creates session without seat and tries to activate this session, but systemd-logind does not allow it:
if (!s->seat)
return -EOPNOTSUPP;
The same happens without vncmanager, using native lightdm VNC support.
That is something that must be fixed in lightdm. It exports seat information to scripts, but it does not export seat information to session process that actually performs PAM conversation.
May be lghtdm does not need to call ActivateSession at all in this case, but it is still something to fix in lightdm.
Unless you need multiple independent remote sessions for the same user (which is problematic anyway), workaround is to imply start Xvnc directly, without going via display manager (which cannot be disabled in vncmanager).
This was read herring. The same error also happens when session does not crash (although it would still be good if lightdm provided the proper seat).
Educated guess is that the second xfce4-session receives the same session D-Bus address as the already running Xfce session, so it got confused by “incorrect” responses (e.g. a lot of programs started as part of normal session are already registered even though the second xfce4-session did not yet even attempt to start them). As proof of concept, launching second session in separate D-Bis environment works:
bor@localhost:~> diff -up /etc/xdg/xfce4/xinitrc .config/xfce4/xinitrc
--- /etc/xdg/xfce4/xinitrc 2022-05-12 04:30:49.000000000 +0300
+++ .config/xfce4/xinitrc 2022-08-03 16:39:15.315315416 +0300
@@ -90,7 +90,7 @@ EOF
fi
else
# start xfce4-session normally
- exec xfce4-session
+ exec dbus-launch xfce4-session
fi
# if we got here, then exec failed
bor@localhost:~>
This is general direction today - there can be only one graphical session which is using session D-Bus and systemd user instance. Attempt to start second session always has mixed results (e.g. it may appear to be started but launched programs are shown on display associated with the session started first).
I am afraid it is simply not supported. Of course one may wish better error handling (like error popup telling user that session is already started), but that again is something to report/request upstream.
Is there any chance you could provide any insight as to why I can’t use yast to setup the web vnc session?
I just tried again this morning,
-fresh install Leap 15.4
-XFCE4 as the desktop
-update while installing
-Go to yast, select open ports, make website, etc.
When trying to connect through a webpage on a different computer on the same network I get nothing. When looking at the /var/log/messages I get:
“sslv3 alert bad certificate” when encryption is enabled in the novnc website settings &
“code 400, message Client must support ‘binary’ or ‘base64’ protocol”
“code 404, message File not found” when encryption is disabled.
