TigerVNC server only getting black screen on connect

[dearZac]

I have a production machine (recently built and many hours of configuration have been put into it), so I tried things on a different machine I had sitting around first.

I tried the suggestion in #668 and downloaded https://bintray.com/tigervnc/stable/download_file?file_path=tigervnc-1.9.0.x86_64.tar.gz unpacked and moved to /

On my testing machine, I was able to connect correctly. I repeated the same exact TigerVNC install process on my production machine, and when I connect I just get a black screen.

The text machine is Xubuntu 18.04, and the projection machine is Ubuntu server 18.04 with the Xubuntu desktop added on top (sudo apt-get install xubuntu-desktop) because I wanted to use the server's install wizard to configure RAID.

I did a bunch of searching and found a different xstartup suggested here instead of the default created the first time vncserver is run: https://wiki.archlinux.org/index.php/Vncserver
#!/bin/sh unset SESSION_MANAGER unset DBUS_SESSION_BUS_ADDRESS exec startxfce4

(I'm not sure why the line breaks aren't showing ^)

I don't get black (I am able to see the desktop), but the log file has tons of errors (attached).

I'm assuming the default xstartup is fine (since it was on the other machine), and that I have something else going on.

machinename-1.log

[jmadams1]

I'm working through VNC issues as well on Xubuntu, Ubuntu Mate, and Lubuntu 18.04. I think I have it mostly figured out so far for Mate. My only guess I have for you is on the machine were you were getting the blank screen on with the configuration that ships with TigerVNC, was that you were also logged into the local GUI when you started the remote session.

The configuration file that ships with TigerVNC works great with 16.04 but doesn't work in 18.04 when you're running multiple sessions for the same user (either local GUI with vnc session or multiple vnc sessions.) That may not be TigerVNC's fault, but a change in 18.04 that needs to be worked out.

The change you made to the xstartup file seems to get around a dbus issue in 18.04 that the original xstartup file exposes. I'm using a very similar xstartup for Mate that also allows me to have multiple sessions for the same user.

Looking at the log, I wouldn't be concerned with the errors (that's just my opinion.)

John

[dearZac]

jmadams1, would you mind sharing your xstartup for Mate, so I can compare?

My only guess I have for you is ... that you were also logged into the local GUI when you started the remote session.

I ran across the logged-in-locally problem you're describing on my test machine, so I made sure not to log in on my production machine (even tried right after reboot launching the server via ssh then trying to connect), but it's still black.

A few differences between my test machine and production machine that could be triggering this black screen issue:

1. I have more than one user account on the production machine. I haven't yet tried adding more accounts to the test machine.
2. I have the production machine set to allow users to log in to the local GUI without typing a password (maybe the gui is started secretly before login because of this?).
3. I have manually set one program to launch on login for one of my users in Application Autostart (in Session and Startup).

These are total wild guesses.

When I get a chance, I can try adding users to my test machine and see if I can get it to fail the same way. I'll also try setting it so all local users require typing a password first.

I am kind of hoping that when the .deb files are made for 18.04 or when 1.9.x (or higher) is added to Ubuntu's repo, that this issue will just magically go away.

[jmadams1]

Here's a working xstartup file for Ubuntu Mate 18.04:

unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
mate-session &

John

[dearZac]

Thank you for your xstartup file.

From earlier:
I wish I knew enough to understand why you said you wouldn't worry about the errors. I'd rather there not be a black screen more, though.

And Update:
I rules out difference #2 by making all users type a password to login locally. I ruled out #3 by turning off the auto launch of the one program.

I still haven't tied adding more users to my test machine yet.

[dragonator4]

Facing the same issue here, and I repeated all that you discussed in this thread and in #668. Additionally, I discovered that running vncserver with sudo fixes the black screen, without the need to exec startxfce4. I checked the permissions on Xauthority, xinitrc, and they all seem fine. The following is a bit more info:

I am running Desktop Ubuntu 18.04.1 on a desktop computer, and have configured another user. Both users have to enter passwords to log in. The guake terminal emulator starts with login for both users. I installed Tiger VNC through the Ubuntu repositories, then purged that install to copy over the generic Tiger VNC build (using rsync if that matters, as suggested in #668). The command I use to spawn the vncserver is:

vncserver :4 -depth 24 -geometry 1920x1080 -nolisten tcp -localhost

which works almost perfectly fine with sudo, but gives a black screen without. I am attaching the logs produced with sudo and without. I am logged into the GUI of my user on the machine, and am launching the vncserver from a terminal. I am connecting to the spawned vncserver from the same machine using Remmina (localhost:5904).

It almost works perfectly with sudo because the Ubuntu 18.04 dock does not show up in the remote desktop. However, a small dock does appear when I click on activities. Gnome shell extensions and other settings are carried over.

WithoutSU.log
WithSU.log

[dragonator4]

And the other thing I noticed was that $HOME/.Xresources is not created, and does not exist. This is the case when run as user and as root.

I'm trying to enable remote login for both users on the machine, using the method in this SO question and answer I asked. I'm not sure starting vncserver as root is a workable solution.

[dragonator4]

Another update:

I modified the xstartup file shared by @jmadams1 by changing mate-session to gnome-session. I can get this modified xstartup file to work correctly if and only if I am logged in to the GUI of the physical machine. If I am not logged in, I get org.gnome.Shell.desktop errors. Check the journalctl log file attached.

Changing the mate-session to startxfce4 gives the Xfce4 desktop, without the errors @dearZac reports (I was getting the same errors with exec startxfce4 in the xstartup).

jctl.log

[CendioOssman]

I am working on a new, more systemd compatible, startup of vncserver. It sounds like it might solve the issues you guys are seeing.

[krentiken]

Hi!

I also see a black screen on my Fedora
29 when launching the vnc through the systemd.
If you run from the command line, then everything works fine.

[rolfvreijdenberger]

+1 on getting the black screen on fedora 29.
launching vncserver from the cmd line as a normal user works fine and I get a normal desktop.
using the provided systemd service files (template) does not work since I get a black screen and a window with "enter password to unlock your login keyring".

one difference I noted was that the xauthority file was different for both types of startup:
cmd line: /usr/bin/Xvnc :1 -auth /run/user/1000/gdm/Xauthority
systemd: /usr/bin/Xvnc :1 -auth /home//.Xauthority

[perrstep]

+1 on the Fedora 29 black screen here too.

[tlaronde]

FWIW, I have the same issue on a NetBSD node. I'm launching a VNC server at boot time, as a specific user. The applications and the window managers complain that they can't open the DISPLAY so I get a black screen.

In the xstartup script, I circumvent the problem by testing the return status of the window manager (in my case, twm) and if there is an error, sleeping and restarting the Vnc server.

What I don't get is why it fails the very first time and succeeds the next. I suspected that some system services were not fully launched but to no avail.

Best regards to the developers.

[etienne678]

I had this issue too on ubuntu, and on my side it was the power management settings.
after i set them to never turn off the screen this never happened again.

[tlaronde]

On Thu, May 16, 2019 at 12:43:39AM -0700, etienne678 wrote: I had this issue too on ubuntu, and on my side it was the power management settings. after i set them to never turn off the screen this never happened again.

Thanks for the tip. I will try to see if in my case, on NetBSD, there is a place during the boot sequence this could apply (now NetBSD is using a framebuffer so perhaps before allowing to log the card is reset for the VT). Best, -- Thierry Laronde <tlaronde +AT+ polynum +dot+ com> http://www.kergis.com/ http://www.sbfa.fr/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C

[John-Whitehead]

Can confirm still happening (the black screen) on Fedora 30. Very easy to reproduce:

1. Boot Fedora 30 Workstation Live from DVD-ROM or USB
2. sudo dnf install tigervnc tigervnc-server
3. vncserver :10
4. vncviewer :10

[CendioOssman]

Just a FYI, that method will probably never be supported. In general a modern Linux system doesn't allow multiple sessions as the same user. So the VNC session will need to be started as a service, and the user cannot be logged in locally.

[dwreski]

Is there another solution? Another vncviewer implementation? Perhaps x0vncviewer?

One problem I've had is that I've been able to connect and view the remote desktop, but any subsequent windows that were created are displayed on the actual desktop, not my viewer virtual desktop.

I can connect to the remote machine via ssh as a regular user, then run the following:

vncserver :1 -geometry 800x600 -depth 24

It then prints the following when I connect:

Thu May 23 18:38:10 2019
vncext: VNC extension running!
vncext: Listening for VNC connections on all interface(s), port 5901
vncext: created VNC server for screen 0

Thu May 23 18:38:14 2019
ComparingUpdateTracker: 0 pixels in / 0 pixels out
ComparingUpdateTracker: (1:-nan ratio)

Thu May 23 18:38:38 2019
Connections: accepted: 68.195.199.42::43322
SConnection: Client needs protocol version 3.8
SConnection: Client requests security type VeNCrypt(19)
SVeNCrypt: Client requests security type TLSVnc (258)
VNCSConnST: Server default pixel format depth 24 (32bpp) little-endian rgb888
VNCSConnST: Client pixel format depth 24 (32bpp) little-endian rgb888

It then prompts me for my password three times - the first to "create a color profile", the second to "refresh the system repositories" and the third to again "create a color profile."

After authenticating, it displays the standard display manager screen, but running an application like a terminal or the file manager appears to start, but apparently displays on the console display, not my virtual display.

This is my ~/.vnc/xstartup file:

$ cat .vnc/xstartup
#!/bin/sh
PATH=/usr/bin:/usr/sbin
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
exec /etc/X11/xinit/xinitrc

[CendioOssman]

I'm afraid the issues you describe sound like other things.

One problem I've had is that I've been able to connect and view the remote desktop, but any subsequent windows that were created are displayed on the actual desktop, not my viewer virtual desktop.

You cannot be logged in locally and have a VNC session running at the same time. This is a limitation of modern Linux systems, and not us, so it's not something we can do much about.

It then prompts me for my password three times - the first to "create a color profile", the second to "refresh the system repositories" and the third to again "create a color profile."

This is a (well known) bug in your desktop environment. Please nag them. It seems we need to be a lot of us before they consider this a priority to fix.

[CendioOssman]

I've pushed my current working copy to #838 for those who want to see where things are heading. It still requires a lot of work, so it's not ready for general use quite yet.

If you have any comments, please file them on the PR.

[TheRoarkster]

This is still open, so I'm going to post my similar issue here. Let me know if I should move it.

Issue: Connecting to TigerVNC server on Raspberry Pi 4 ("Rpi4") from any client leads to black screen on connect.

Expected Behavior: View of the Rpi4's desktop.

** Settings**:

• Rpi4 is running Manjaro GNOME 3.34
• xstartup is:

#!/bin/sh
PATH=/usr/bin:/usr/sbin
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
exec /etc/X11/xinit/xinitrc

But I have tried at least 20 variants, including:

#!/bin/sh

#unset SESSION_MANAGER

[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
x-terminal-emulator -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
x-window-manager &

gnome-panel &
gnome-settings-daemon &
metacity &
nautilus &

Others have recently posted similar issues. See here for example.

I am starting the server via this command: vncserver :1 -geometry 1366x768 -depth 24.

All efforts lead to:
(A) vnc starting on the Rpi4 with this message:

New 'rpi4:1 (rsync)' desktop is rpi4:1

Starting applications specified in /home/rsync/.vnc/xstartup
Log file is /home/rsync/.vnc/rpi4:1.log

(B) a black screen on the client.

[bitboy85]

I'm currently trying out xrdp + tigervnc + debian stretch + xfce. A black screen is the result of the lock screen. After it the screen is locked there seems no way to login again through vnc, the screen keeps black.
As a workaround the lock screen can be disabled under settings -> session and startup -> automatic start -> screen lock (Not sure about names in the english version)
i'm not suggesting to do so as its a security feature and i hope there will be a fix for this.

[dman777]

I figured it out.... It runs x server on boot up. So, place your xinitrc somewhere it can be executed like in your home directory and chmod 777 it. Modify your /home/one/.vnc/xstartup to run the /home/one/xinitrc file. Also, make sure you have xterm installed because it needs a terminal emulator still.

[skvenkat]

I have done the following to get the twm desktop manager on vnc screen:

Here is the xstartup file content

#!/bin/sh

unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
OS=uname -s
if [ $OS = 'Linux' ]; then
case "$WINDOWMANAGER" in
gnome)
if [ -e /etc/SuSE-release ]; then
PATH=$PATH:/opt/gnome/bin
export PATH
fi
;;
esac
fi
if [ -x /etc/X11/xinit/xinitrc ]; then
exec /etc/X11/xinit/xinitrc
fi
if [ -f /etc/X11/xinit/xinitrc ]; then
exec sh /etc/X11/xinit/xinitrc
fi
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
twm &

1. Kill any existing VNC session explicitly
   kill -9 <pid-of-vncserver>

2. Remove any other vnc server rather than TigerVNCserver
   dpkg -l | grep vnc
dpkg -r <other-vnc-server-pkg-name>

3. Remove the ~/.vnc directory
   rm -rf ~/.vnc

4. Reconfigure the alternative for vncserver
   sudo update-alternatives --config vncserver

mostly the options should only show tigervncserver as entries and choose the auto (0) mode by entering 0 for the input prompt

5. Restart the vncserver
   vncserver

Now the TigerVNCserver will be invoked and prompt for password.

[zuber-bioinfo]

Finally I have got the success on Ubuntu 20.04 (gnome)

$ sudo apt install tigervnc-standalone-server
$ vncpasswd
$ vncserver :1

Permission:
$ chmod u+x ~/.vnc/xstartup

xstartup file:

#!/bin/sh
PATH=/usr/bin:/usr/sbin
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
exec /usr/bin/gnome-session &

$ vncserver :1 -geometry 1680x1050 -depth 24 -localhost no

Done....

[stratus-ss]

PATH=/usr/bin:/usr/sbin
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
exec /usr/bin/gnome-session &

This didn't work for me on Ubuntu 20.04. I am still getting a black screen when trying to use systemd to launch the vncserver.
If I run vncserver -localhost no on the interactive CLI over SSH, the vncserver works as expected. When launching with systemd, I only get a black screen

[yununusmulla]

Help please``

[fabiogfernandes]

As @dragonator4 said "$HOME/.Xresources is not created". I created the file and it worked as suggested in here:
https://wiki.parabola.nu/TightVNC (6.3 Window manager issues)

[falconws]

As @dragonator4 said "$HOME/.Xresources is not created". I created the file and it worked as suggested in here:
https://wiki.parabola.nu/TightVNC (6.3 Window manager issues)

I have tested this solution but it doesn't work for me.
The attached png file is the result.
Black screen and uncontrollable desktop (If click any icons it does not work. If right-click the desktop,
doesn't show me the menu.)
Seems to freeze.

[chrisbitmead]

@falconws the fact you seem to have a dock and a menu bar makes me think it's mostly working for you. What if you add an
xterm &
in your startup script, do you see the xterm? You seem to be close.

[falconws]

@chrisbitmead My xstartup script is below.

#!/bin/bash

xrdb $HOME/.Xresources
vncconfig -iconic &
startxfce4 &

Are you said like this one?

#!/bin/bash

xrdb $HOME/.Xresources
vncconfig -iconic &
startxfce4 &
xterm &

[falconws]

@chrisbitmead
xterm is appeared.
But can't input any character, can't drag and drop, can't resize.
Looks like freeze.

[chrisbitmead]

You will probably find you can input to the xterm if you hover the mouse over it. If you can't see your mouse, move the imaginary mouse there.

If I were you, I'd install another window manager like fvwm and see if it works with that instead of startxfce4, as a way to narrow it down.

BTW, normally with xstartup scripts, the last command does not have an "&" after it. Your xsession ends when that program exits. Typically it is the window manager, or whatever program starts the window manager, but could be anything like xterm.

[falconws]

@chrisbitmead I have tested this startup script

#!/bin/bash

xrdb $HOME/.Xresources
vncconfig -iconic &
xterm &
startxfce4

No difference result.

You will probably find you can input to the xterm if you hover the mouse over it. If you can't see your mouse, move the imaginary mouse there.

I can see the mouse cursor, and even if hover the mouse over xterm, can't input any character.

I want to use xfce4 instead of fvwm...

If not using systemd and manually execute vnc server run command via ssh session is working perfectly.

/usr/bin/vncserver -geometry 1920x1080 -localhost no -alwaysshared :1

TigerVNC * systemd is so bad...

[chrisbitmead]

I only suggested using fvwm as way of narrowing down where the problem might be, since fvwm is much simpler than xfce4. It's quite odd that vnc seems to run well enough to display some docks and xterms, but doesn't take input. I'd be tempted to try the TightVNC viewer to see if you get the same result. The other possibility is that xfce4 has gone into some screen lock or screen saver mode. I'd be disabling that in the xfce4 settings. Another reason to try the simplest possible setup to begin. If you don't want to install fvwm, just comment out startxfce4 leaving only xterm, and see if then you can input into it. If you can, then the problem is somewhere in xfce4.

[falconws]

@chrisbitmead Thank you very much for your advice.
I will try your advice tomorrow.

Thanks.

[falconws]

@chrisbitmead

If you don't want to install fvwm, just comment out startxfce4 leaving only xterm, and see if then you can input into it. If you can, then the problem is somewhere in xfce4.

I have tested.
Not start xfce4 and only start xterm is worked. I can input commands to xterm.

The other possibility is that xfce4 has gone into some screen lock or screen saver mode. I'd be disabling that in the xfce4 settings.

1. start vncserver manually via ssh command (vncserver -geometry 1920x1080 -localhost no -alwaysshared :1)
2. disable the screensaver and the screen lock from xfce4 gui setting.
3. stop vncserver via ssh command (vncserver -kill :1)
4. start vncserver via system (sudo systemctl start vncserver.service)
5. access vncserver

I can't input any operation, It seems like a freeze.

If you can, then the problem is somewhere in xfce4.

Yes. Is this xfce4 problem? fmm....
Why worked correctly via ssh command.
Why doesn't work via systemd.

[falconws]

Maybe this is related.
https://bugzilla.redhat.com/show_bug.cgi?id=1633805

[chrisbitmead]

You've probably reached the end of my knowledge. I will say that I've personally also ended up with frustration trying to start guis from systemd for some reason. The only obvious advice I can give is either to forget xfce4 and go with something simpler like a plain window manager.... or... start xfce4 from an ssh script just before you login rather than systemd, or... don't use vnc. VNC is actually much inferior to xrdp. While some people might unfairly associate xrdp with Microsoft, it just plain works better, especially with multiple monitors. VNC is awful with multiple monitors, xrdp works great. I don't know if that will help your systemd issues, but rdp is the future, and vnc is no good.

[mmrtnt]

This is the xstartup file that worked for me on a Fedora 33 Mate-Compiz VM after initially experiencing a blank screen when attempting to connect:

`#!/bin/sh

unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS
xrdb $HOME/.Xresources
exec /usr/bin/mate-session`

[reinzor]

For xfce4 Ubuntu 20.04 (coming from 18.04), adding the following command to the startup script did the trick:

exec /usr/bin/xfce4-session

[scobi84]

For xfce4 Ubuntu 20.04 (coming from 18.04), adding the following command to the startup script did the trick:

exec /usr/bin/xfce4-session

God bless you, @reinzor, after wasting a day trying to get it working on 20.04 it's finally operational

[falconws]

@reinzor I have tested but not working.

[Howitzer105mm]

I will relay my experience with this transition.
I was getting the black screen issue as well on my FC32 and FC33 system.
I worked my way through several of the suggestions here, and while I would see the KDE start screen, it would then change to the black screen.
As I was playing I realized that the screen was active, just black.
My method was using the "vncserver : 1" from a running KDE session, and then using TigerVNC to attach to the 5901 port.
I finally got my solution by changing how I launched VNC.
My working method is to:
Add a "session=plasma" to my ~/.vnc/config file
ssh
systemctl start vncserver@:1
logout

Start TigerVNC, and connect to port 5901 (i.e. : 1)
Now when I get through the "servername" and "authorization" phases, I can login to my system, and get a full KDE desktop.

Note: I have not seen any impact from adding entries into my ~/.vnc/xstartup

[RNCTX]

None of these solutions worked when launching TigerVNC via a systemd socket listener, tried Unity and Gnome with various xstartup configs accepted as solutions in various stackoverflow questions and those posted in this bug report, all resulted in nothing but a black screen. Nothing in the systemd logs but "success" connects, and nothing in the syslog but "success" notes from systemd in relation to the session.

It's... just... broken.

If it makes anyone feel any better, all TightVNC got me was a grey screen with the "X" mouse cursor from 2001-era Red Hat desktops.

All these Ubuntu distress are basically a poor knockoff of Windows XP at this point. It won't start a second desktop session on a second monitor, it won't start one via VNC in a virtual TTY either.

[xpusostomos]

If you can get the "X" mouse cursor... it's probably working! You just don't have any apps running... you're especially missing a window manager. Find your startup script and run one. Recommend fvwm for testing, because it's simple and won't fail. Run an xterm as well, at least you'll then have a command prompt to start window managers / apps.

fvwm &
xterm &

[Formartha]

anyone was able to solve it? I'm facing the same issue.
that's my startup script (docker container with xfce4 and the script is a startup endpoint).

`#!/bin/bash

how to build?

---------------

docker build -t orion-docker-runner:10.4.1 .

how to run?

-------------

docker run -d --rm -p 5999:22 -p 5998:5901 orion-docker-runner:10.4.1 <-- deatached

docker run -ti --rm -p 5999:22 -p 5998:5901 orion-docker-runner:10.4.1 <-- attached

start_ssh() {
# -- starting up vnc server -- #
/usr/sbin/sshd -D

}

configure_vnc() {
# -- configure vnc session -- #
echo "#!/bin/bash
xrdb $HOME/.Xresources
startxfce4 &" > ~/.vnc/xstartup

  chmod +x ~/.vnc/xstartup

}

-- docker startup --

configure_vnc && vncserver :1 -localhost no -geometry 1920x1080 -depth 32 && tail -f /dev/null && exec /usr/bin/xfce4-session`

[lhzw]

Seems one user can only start one kde desktop, the extras are black screen. Just now xdm and vnc show me the desktop, I think, is because I don't login to the desktop.

Replace sddm to xdm fix the black screen problem, refert to this:
https://forums.opensuse.org/showthread.php/532320-vncserver-blank-screen

Switch your Display Manager to XDM, KDM (you would have to install that in Yast, first), or LightDM on the machines you are trying to access.

Code:
su -
and give the password, then:
Code:
update-alternatives --config default-displaymanager
choose your Display Manager from the list.

SDDM does not work well with VNC yet.

[zanco]

This might or might not help other people. Today I have been struggling for hours to get something other than the black screen with vnc (running tigervnc on the 22.04 system) by SSH access.

Nothing appeared to work, until I connected an HDMI monitor to the headless system. Suddenly the active black vncviewer session popped to my desktop screen....

[bitboy85]

@zanco this reminds of different articles i read thats not possible to take screenshots if no display is connected. Xvfb might help in this case as it provides some sort of virtual display but i never used it on my own.

[Bialogs]

Having the same issue when connecting via VNC to a user other than ec2-user on Amazon Linux 2.

[hans2520]

For those who have a working solution when launching via SSH, but cannot get it to work via systemd, I found the solution for this, and it seems pretty airtight -- https://unix.stackexchange.com/a/611494/444609

I compared the log output when running via SSH vs running via systemd, and observed that the difference was with the latter, we see the following message: org.gnome.Shell.desktop[12960]: Window manager warning: Unsupported session type -- which then leads to gnome-session[12882]: gnome-session-binary[12882]: CRITICAL: We failed, but the fail whale is dead. Sorry.... -- and is unrecoverable. The session type is controlled by the XDG_SESSION_TYPE environment variable, and sure enough, when launching via systemd, there are no XDG variables set at all.

Setting the "PAMName" option in the unit config should handle this -- but there appears to be bugs with it and systemd -- systemd/systemd#8598

So simply logging on as the user using normal su (vs SSH which is an unnecessary additional layer) in the command is the surefire way to go here. I had instant success using the solution outlined on the above stackexchange answer

[hans2520]

I don't think TigerVNC needs a reliance on the XDG_SESSION_TYPE or XDG_SESSION_ID variables, but since it apparently does, some sort of documentation around this would be beneficial.

Edit: I also realize that this dependency could be coming from gnome and not TigerVNC... but I'm not 100% sure if the issue exists with other VNC clients and gdm, or if affects all VNC clients using gdm

[CBx86]

I've been stuck with a black screen since this year, anyone?
Many thanks

[xpusostomos]

@CBx86 Did you read the above thread? What did you try?

[CendioOssman]

This is an issue that has been resolved ages ago, and with a very generic description. It's not a productive place for new bug reports. Please use the discussion group to get help with debugging your setup.