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.
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.
Aug 03 11:45:34 localhost.localdomain lightdm: 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:
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
# start xfce4-session normally
- exec xfce4-session
+ exec dbus-launch xfce4-session
# if we got here, then exec failed
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.