We have run into the infamous black screen problem with tigervnc under CentOS7, which prompted me to look into how vnc is configured here. https://access.redhat.com/solutions/966063 Am I reading this correctly - root needs to set up a systemd vnc service for every user and display individually? Compared to e.g. CentOS before 7, or indeed any other Linux/Unix system where vnc is completely under user control?
On 12/19/18 4:36 AM, isdtor wrote:> We have run into the infamous black screen problem with tigervnc under CentOS7, which prompted me to look into how vnc is configured here. > > https://access.redhat.com/solutions/966063 > > Am I reading this correctly - root needs to set up a systemd vnc service for every user and display individually? Compared to e.g. CentOS before 7, or indeed any other Linux/Unix system where vnc is completely under user control? >openSUSE always spawned VNC sessions for each user through xinetd. The user did not have "control" of the sessions. Do you get a login screen? Does the screen go "black" after login? If so, in my experience, the user logging in already has a desktop session running (usually on the console). Make sure to try logging in with a user that is not already logged in. Linux can deal with multiple DIFFERENT users logged in but the desktops can only deal with one login and home directory per user. Mike, W1NR
Mike McCarthy, W1NR writes:> > On 12/19/18 4:36 AM, isdtor wrote: > > We have run into the infamous black screen problem with tigervnc under CentOS7, which prompted me to look into how vnc is configured here. > > > > https://access.redhat.com/solutions/966063 > > > > Am I reading this correctly - root needs to set up a systemd vnc service for every user and display individually? Compared to e.g. CentOS before 7, or indeed any other Linux/Unix system where vnc is completely under user control? > > > > openSUSE always spawned VNC sessions for each user through xinetd. The > user did not have "control" of the sessions.Noted.> Do you get a login screen? Does the screen go "black" after login? If > so, in my experience, the user logging in already has a desktop session > running (usually on the console). Make sure to try logging in with a > user that is not already logged in. Linux can deal with multiple > DIFFERENT users logged in but the desktops can only deal with one login > and home directory per user.What you describe doesn't make much sense to me either. In this case, there are no user logins on the console, this is meant to be a remote login server. Anyone logging in via vnc gets the black screen treatment. There is no login screen, only the vnc password prompt. For this type of machine, multi-user.target should be sufficient, although it is set to graphical.target right now.
On Wed, Dec 19, 2018 at 09:36:44AM +0000, isdtor wrote:> We have run into the infamous black screen problem with tigervnc > under CentOS7, which prompted me to look into how vnc is configured > here. > > https://access.redhat.com/solutions/966063 > > Am I reading this correctly - root needs to set up a systemd vnc > service for every user and display individually? Compared to > e.g. CentOS before 7, or indeed any other Linux/Unix system where > vnc is completely under user control?No. Users can run vncserver and attach to them like you could before, or you can run Xvnc -inetd, just as a systemd service/socket pair instead of out of xinetd. The black screen problem that you mentioned does sound familiar -- I've seen it with VNC clients that don't support OpenGL, with the GNOME desktop (which uses a compositing display manager), it just crashes when you log in. -- Jonathan Billings <billings at negate.org>
> No. Users can run vncserver and attach to them like you could before, > or you can run Xvnc -inetd, just as a systemd service/socket pair > instead of out of xinetd. > > The black screen problem that you mentioned does sound familiar -- > I've seen it with VNC clients that don't support OpenGL, with the > GNOME desktop (which uses a compositing display manager), it just > crashes when you log in.Looked at this a bit more. There is a crash, but for a different reason: Dec 19 07:59:31 host dbus-daemon: YPBINDPROC_DOMAIN: Domain not bound Dec 19 07:59:31 host dbus-daemon: YPBINDPROC_DOMAIN: Domain not bound Dec 19 07:59:31 host gnome-session-binary[12324]: ERROR: Failed to connect to system bus: Exhausted all available authentication mechanisms (tried: EXTERNAL, DBUS_COOKIE_SHA1, ANONYMOUS) (available: EXTERNAL, DBUS_COOKIE_SHA1, ANONYMOUS)#012aborting... Dec 19 07:59:31 host gnome-session: gnome-session-binary[12324]: ERROR: Failed to connect to system bus: Exhausted all available authentication mechanisms (tried: EXTERNAL, DBUS_COOKIE_SHA1, ANONYMOUS) (available: EXTERNAL, DBUS_COOKIE_SHA1, ANONYMOUS) Dec 19 07:59:31 host gnome-session: aborting... I've seen this before, and the solution was to make sure that the NISDOMAIN is defined in /etc/sysconfig/network. https://marc.info/?l=centos&m=152806243921469&w=2 NIS setup is correct and working, question is why it is being ignored by dbus. After restarting dbus, there is still a crash, but a different log. Dec 19 08:22:30 host org.a11y.Bus: Activating service name='org.a11y.atspi.Registry' Dec 19 08:22:31 host org.a11y.Bus: Successfully activated service 'org.a11y.atspi.Registry' Dec 19 08:22:31 host org.a11y.atspi.Registry: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry Dec 19 08:22:31 host dbus[25267]: [system] Activating via systemd: service name='org.freedesktop.login1' unit='dbus-org.freedesktop.login1.service' Dec 19 08:22:56 host gnome-session-binary[28570]: WARNING: Failed to connect to systemd: Error calling StartServiceByName for org.freedesktop.login1: Timeout was reached Dec 19 08:22:56 host kernel: gnome-session-b[28570]: segfault at 8 ip 00000000004216f1 sp 00007ffdfcfc77b0 error 4 in gnome-session-binary[400000+45000] Dec 19 08:22:56 host gnome-session: gnome-session-binary[28570]: WARNING: Failed to connect to systemd: Error calling StartServiceByName for org.freedesktop.login1: Timeout was reached Dec 19 08:22:56 host gnome-session: gnome-session-binary[28570]: GLib-GObject-WARNING: invalid (NULL) pointer instance Dec 19 08:22:56 host gnome-session: gnome-session-binary[28570]: GLib-GObject-CRITICAL: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed Dec 19 08:22:56 host gnome-session: gnome-session-binary[28570]: GLib-GIO-CRITICAL: g_dbus_proxy_call_sync_internal: assertion 'G_IS_DBUS_PROXY (proxy)' failed Dec 19 08:22:56 host gnome-session-binary[28570]: GLib-GObject-WARNING: invalid (NULL) pointer instance Dec 19 08:22:56 host gnome-session-binary[28570]: GLib-GObject-CRITICAL: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed Dec 19 08:22:56 host gnome-session-binary[28570]: GLib-GIO-CRITICAL: g_dbus_proxy_call_sync_internal: assertion 'G_IS_DBUS_PROXY (proxy)' failed Dec 19 08:22:56 host dbus[25267]: [system] Failed to activate service 'org.freedesktop.login1': timed out Dec 19 08:22:56 host abrt-hook-ccpp: Process 28570 (gnome-session-binary) of user 14728 killed by SIGSEGV - dumping core
On 12/19/18 4:36 AM, isdtor wrote:> We have run into the infamous black screen problem with tigervnc under CentOS7, which prompted me to look into how vnc is configured here. > > https://access.redhat.com/solutions/966063 > > Am I reading this correctly - root needs to set up a systemd vnc service for every user and display individually? Compared to e.g. CentOS before 7, or indeed any other Linux/Unix system where vnc is completely under user control? > >I have always run an instance of vnc-server for each user.? I never gave the user control, just assigned the port number for the user. I have been doing this at least since CentOS4. Now the fun comes in as to what GUI you are using.? The install is for Gnome, and if you want any other GUI, you have work in front of you.? I have it working for Xfce. I have a separate systemd service file for each user. And I enable them all, just the way I run things.? I suppose there are ways you can have the user start his specific systemd service from their ssh shell.