The unit file works when manually started. systemctl --user enable does not auto-start the service after user login.

Unit File

Description = VNC Duplicate Display RDP
After = default.target

Type = simple
ExecStart = /opt/tigervnc/usr/bin/x0vncserver -passwordfile /etc/.vncpasswd -display :0
TimeoutSec = 30
RestartSec = 10
Restart = always

WantedBy = default.target

I have reloaded and reenabled this unit

$ systemctl --user daemon-reload
$ systemctl --user reenable x0vncserver


Status after user login

● x0vncserver.service - VNC Duplicate Display RDP
   Loaded: loaded (/usr/lib/systemd/user/x0vncserver.service; enabled; vendor preset: enabled)
   Active: inactive (dead)

Target Status

$ systemctl --user --type target
basic.target   loaded active active Basic System
default.target loaded active active Default
paths.target   loaded active active Paths
sockets.target loaded active active Sockets
timers.target  loaded active active Timers

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

5 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

Manual Start

$ systemctl --user start x0vncserver
$ systemctl --user status x0vncserver
● x0vncserver.service - VNC Duplicate Display RDP
   Loaded: loaded (/usr/lib/systemd/user/x0vncserver.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2017-08-07 18:27:00 IST; 5s ago
 Main PID: 2999 (x0vncserver)
   CGroup: /user.slice/user-1004.slice/[email protected]/x0vncserver.service
           └─2999 /opt/tigervnc/usr/bin/x0vncserver -passwordfile /etc/.vncpasswd -display :0

Aug 07 18:27:00 Machine systemd[930]: Started VNC Duplicate Display RDP.
Aug 07 18:27:00 Machine x0vncserver[2999]: Mon Aug  7 18:27:00 2017
Aug 07 18:27:00 Machine x0vncserver[2999]:  Geometry:    Desktop geometry is set to 1920x1080+0+0
Aug 07 18:27:00 Machine x0vncserver[2999]:  Main:        XTest extension present - version 2.2
Aug 07 18:27:00 Machine x0vncserver[2999]:  Main:        Listening on port 5900


I've looked around and found users with similar issues but none of the proposed solutions fixed my issue


This happens to a particular user. systemctl --user enable works for at least one other user on the same device.

  • What does journalctl tell you? Aug 7, 2017 at 13:06
  • Good question, it tells nothing. Cannot find the text x0vncserver
    – Lordbalmon
    Aug 7, 2017 at 13:07
  • "works for at least one other user", what is the user that it works for and what are the permissions on /etc/.vncpasswd? Also, it might only work for one user at a time if all instances attempt to listen on the same port (5900 is the default)
    – smokes2345
    Jul 10, 2018 at 20:00
  • See also unix.stackexchange.com/questions/374638/…
    – rogerdpack
    Oct 28, 2019 at 4:06

2 Answers 2


I had the same problem, what fixed it for me was using it as follows:

/usr/bin/x0vncserver -PasswordFile=/home/luserid/.vnc/passwd -display=:0

it seems it won't start right without the -display=:0.

  • This is necessary for the --system bus. However, the --user bus is pretty good at setting $DISPLAY automatically. That's nice in case it isn't always :0
    – Stewart
    Jun 6, 2021 at 19:54

To let systemd run a VNC server, that server needs two things:


If you are running on the user-bus (which you are), these are often set automatically. I've found that when these variables are reliably set, I don't need to be explicit with --display which is good because it can change based on my configuration. Tigervnc might be different, but I would expect it to use $DISPLAY if --display isn't specified.

So how do you ensure these are reliably set when you start your service?

These may not be set immediately if your user logs in before the X-server is fully up and running. I find this happens on systems where I use auto-login from GDM, or if I log in via SSH or a TTY before logging in via display-manager.

The solution I use on my Debian system is to only run my vnc server after Xauthority is guaranteed to be available. I detect that with a *.path unit:

# ~/.config/systemd/user/vnc.path


# ~/.config/systemd/user/vnc.service
ExecStart=x11vnc -shared -many -nopw

You only need to systemctl --user enable vnc.path for this to work.

The path unit will sit and wait for /run/user/1000/gdm/Xauthority to exist. That will only exist AFTER your user has access to a display. When it is created, the path unit will start vnc.service and your VNC server will start with $DISPLAY and $XAUTHORITY variables set automatically.

The path %t/gdm/Xauthority is a default path on Debian. %t is short for /run/user/1000 and I like using that short-hand because it works if your UID is not 1000. Take a look at echo $XAUTHORITY if you need a different path if you're on a different distro.


The systemd design has some targets of interest. default.target is meant to be symlinked to graphical.target which has some relationships with graphical-session.target which is implemented the desktop environment (e.g. gnome-session.target).

Theoretically, using WantedBy=graphical-session.target and After=graphical-session.target is a simpler and better solution to the *.path I mentioned, but unfortunately the implementation needs to be done by the desktop-environments, and that does not appear to have happened yet on all DEs. I've found that graphical-session.target isn't raised on all desktop environments reliably, hence the *.path solution is my recommendation.

  • When I run echo $XAUTHORITY on Ubuntu 20 from a terminal running gnome on a remote connection, I get nothing. I do get a value for echo $DISPLAY
    – Jon
    Jun 13 at 21:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .