Bug 983232

Just a small ping about the issue - this is not fire and forget - if you need any further information, try different configuration - I will  gladly help.

*** Bug 984588 has been marked as a duplicate of this bug. ***

Same issue here. The vncserver unit file method worked fine before an upgrade to Fedora 19. I am using KDE.
I tried to run vncserver manually and that does work. Using the systemd unit method does not. Same thing happens that Alexander is describing. The service starts and then stops.
I can test any patches to fix this here. It would be really useful if this worked again.
Thank You.

The problem appears to be the detection of the Xvnc process / PID; systemd isn't picking it up and thinks the service has died, so it launches the ExecStop script almost immediately after vncserver (ExecStart) completes.

I was able to work around the problem by manually directing systemd to the Xvnc PID file in my homedir. The following line added to the /etc/systemd/system/vncserver@:1.service unit file Works For Me(TM):

PIDFile=/home/<USER>/.vnc/%H%i.pid

(In reply to "FeRD" (Frank Dana) from comment #4)
> The problem appears to be the detection of the Xvnc process / PID; systemd
> isn't picking it up and thinks the service has died, so it launches the
> ExecStop script almost immediately after vncserver (ExecStart) completes.
> 
> I was able to work around the problem by manually directing systemd to the
> Xvnc PID file in my homedir. The following line added to the
> /etc/systemd/system/vncserver@:1.service unit file Works For Me(TM):
> 
> PIDFile=/home/<USER>/.vnc/%H%i.pid

I can't make it work with this addition but maybe there is more to it. Could you please include the entire service section of your unit file? I'll copy your file and see if that works for me.

Created attachment 775960 [details]
systemd unit file for vncserver@:1.service, including explicit PIDFile= line

Sure, I'm attaching my unit file — as usual, all instances of <USER> should be replaced by the username under which the vncserver process should be run.

Another potential issue is if the %H specifier (which evaluates to systemd's idea of the hostname) doesn't expand to the same string as the hostname part of the logfile name that Xvnc generates. On my installation, they match, but just in case you might try hardcoding the hostname part as

PIDFile=/home/<USER>/.vnc/hostname%i.pid

Or even just skip all of the specifiers and hardcode the exact filename.

When systemd's correctly picking up the pidfile,
'systemctl status vncserver@:1.service' will include a line such as:

Main PID: 9385 (Xvnc)

showing that it's using the lifecycle of the Xvnc process to monitor the service state.

I can also report that on all 3 machines I have (real - i686, x86_64 and virtual - x86_64) the fix given by FrankDana in Comment 4 works fine.

> I can't make it work with this addition but maybe there is more to it. Could
> you please include the entire service section of your unit file? I'll copy
> your file and see if that works for me.

Eric - try what Frank Dana advised. My 2c will be to
1st. Remove the line and see hat is the name of the pid file that Xvnc generates in ~/.vnc - basically remove all the stale *.log and *.pid files there, start the vnc service via systemd and see what is the name of the generated file
2nd - add the PIDFile line and use hardcoded value at first and if successful and then try to use the %H and %i aliases
3rd - if the above does not work - tray setting the hostname with the hostnamectl utility and try 1 and 2 again

tigervnc-1.3.0-3.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/tigervnc-1.3.0-3.fc19

Package tigervnc-1.3.0-3.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing tigervnc-1.3.0-3.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-13650/tigervnc-1.3.0-3.fc19
then log in and leave karma (feedback).

tigervnc-1.3.0-3.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Just installed a fresh (virtual) Fedora 19 system with the latest tigervnc-server update, however, this problem still persists for me.
Log output (relevant part):
===============================
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Internal error:   Could not resolve keysym XF86AudioMicMute
Errors from xkbcomp are not fatal to the X server
/home/ben2404/.vnc/xstartup: line 5: x-terminal-emulator: command not found
XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":1"
      after 141 requests (140 known processed) with 0 events remaining.
cp: cannot stat ‘/usr/share/lxde/pcmanfm/pcmanfm.conf’: No such file or directory
===============================

Tried also with the adjustments in vncserver@:1.service, but unfortunately to no avail.

@brhalen (#12): From the output you showed us, I'm not sure that is the same problem -- it looks like perhaps the desktop environment you're trying to start inside the VNC server isn't installed completely/properly. (That failure to copy pcmanfm.conf is especially suspicious.)

If you manually run 'vncserver :1' as the appropriate user, do you get a working Xvnc? If the answer is NO (my prediction), then you're not experiencing this bug. It's a local issue (probably solved by installing some missing packages).

Also, if you ARE encountering the bug reported here, then there'll be an explicit
"runuser[###]: Killing Xvnc process ID ####"
line in /var/log/messages immediately after attempting to start vncserver@:1.service, like in Alexander's initial report.

Sorry, I forgot to mention that, I see now.

The pcmancfm.conf error is something that I see everytime, ever since Fedora 17. I had resolved it at one time, but can't remember how.

When running 'vncserver :1' manually, my VNC works without a problem.

You mean errors like these:
Aug  1 08:54:36 Bilbo systemd[1]: Starting Remote desktop service (VNC)...
Aug  1 08:54:36 Bilbo systemd[1]: Started Remote desktop service (VNC).
Aug  1 08:54:39 Bilbo runuser[1222]: New 'Bilbo.benweb.eu:1 (ben2404)' desktop is Bilbo.benweb.eu:1
Aug  1 08:54:39 Bilbo runuser[1222]: Starting applications specified in /home/ben2404/.vnc/xstartup
Aug  1 08:54:39 Bilbo runuser[1222]: Log file is /home/ben2404/.vnc/Bilbo.benweb.eu:1.log
Aug  1 08:54:39 Bilbo runuser[1222]: Killing Xvnc process ID 1246

Think I may have found the problem, at least, in my case:
The 'vncserver@.service' file, contains the following line:

ExecStart=/sbin/runuser -l <USER> -c "/usr/bin/vncserver -fg %i"

I was looking at this, when I realized that the only thing that seems to differ from running the line from the command-prompt, is the '-fg' switch, which, according to the man-page, is used to spawn the vncserver as a foreground process.
I just deleted this switch, did a systemctl daemon-reload, relinked the service and started it successfully.
My line therefore now is:
ExecStart=/sbin/runuser -l <USER> -c "/usr/bin/vncserver %i"

Your [Service] section should look like this:

[Service]
Type=simple
# Clean any existing files in /tmp/.X11-unix environment
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
ExecStart=/sbin/runuser -l <USER> -c "/usr/bin/vncserver -fg %i"

The only difference from this should be that <USER> is replaced by your username.

If you take out "-fg", that makes the Type=simple line wrong.

brhahlen: could you please paste in your [Service] section as it now is, in its working state?

This is the full vncserver@:1.service file that I have.
----------
[Unit]
Description=Remote desktop service (VNC)
After=syslog.target network.target

[Service]
Type=simple
# Clean any existing files in /tmp/.X11-unix environment
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
ExecStart=/sbin/runuser -l ben2404 -c "/usr/bin/vncserver %i -geometry 1600x850"

[Install]
WantedBy=multi-user.target
----------
I admit: my trying to remove the "-fg" was only due to the fact that it was the only difference I could think of from running it through CLI.
Also, reading the manpage, which said that the "-fg" switch makes it a foreground process, seemed odd to me, due to the fact that you're running it as a service, hence, not in the foreground.
However, this could just be my simplistic way of seeing things :-)

Could you elaborate on what the Type=simple line is meant for? I don't know too much about systemd and the service files, but am curious enough to want to find out.

systemd's Type= option is covered pretty well in the systemd.service(7) man page. The structure and operation of unit files in general is covered in systemd.unit(5), and the rest of the types have their own man pages as well (systemd.socket(5), systemd.target(5), systemd.mount(5), etc...)

Sorry, I knew I'd screw that up at least once. ALL of the man pages I mentioned are in section 5, including systemd.service.

Thanks Frank, I'll have a look at those :-)

brhahlen: so, your file looks fine except that it needs to have "-fg" before "%i" in the ExecStart line -- exactly the thing you said you needed to take out to fix the problem you were seeing.

I can't reproduce the problem you were seeing here. I use a service file with Type=simple and ExecStart having -fg in, and it all works as expected for me.

Is anyone else seeing problems with the as-shipped set-up, or is it perhaps something specific to brhahlen's machine?

The fix provided with the new package *worked for me an all* of my 3 configurations - x86 & 64 bit physical machines and the virtual 64 bit one.
Just adding for completeness - the provided fix changes the template file in
/lib/systemd/system/vncserver@.service
After the update - either regenerate your own file or use a diff tool such as meld to see the changes in lines and arguments.

Thanks for the tip, Alexander, this works for me on f19, in simple/-fg mode.

There does still appear to be a systemd regression with a PID file problem in forking mode, from what I can see from here.

I have the same problem.  Here is the systemd file I am using:

------------------------------------------
[Unit]
Description=Remote desktop service (VNC)
After=syslog.target network.target

[Service]
Type=simple
PIDFile=/home/uname/.vnc/%H%i.pid
#PIDFile=/home/uname/.vnc/ws1.mydomain.tld.pid
ExecStart=/sbin/runuser -l uname -c "/usr/bin/vncserver -fg %i -geometry 1590x998 -rfbport 5902 -nolisten tcp"
ExecStop=/sbin/runuser -l uname -c "/usr/bin/vncserver -kill %i"

[Install]
WantedBy=multi-user.target

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

I have tried it with each of the PIDFile definitions shown it the above listing.  Niether worked

When I run systemd start vncsserver@:3.service it appears to be OK and if I quickly run netstat -ntlp I see that port 5903 is opened.  But very soon it disapears.  I also see the PID file for a few seconds, which disapears when the vncserver instance disapears.

This is the status output:

-----------------------------------
[root@ws1 ~]# systemctl status vncserver@:3.service
vncserver@:3.service - Remote desktop service (VNC)
   Loaded: loaded (/usr/lib/systemd/system/vncserver@:3.service; disabled)
   Active: failed (Result: exit-code) since Mon 2013-09-23 14:43:25 PDT; 8s ago
  Process: 13764 ExecStop=/sbin/runuser -l emmett -c /usr/bin/vncserver -kill %i (code=exited, status=2)
  Process: 13685 ExecStart=/sbin/runuser -l emmett -c /usr/bin/vncserver -fg %i -geometry 1590x998 -localhost -rfbport 5902 -nolisten tcp (code=exited, status=0/SUCCESS)

Sep 23 14:43:20 ws1.mydomain.tld systemd[1]: Starting Remote desktop service (VNC)...
Sep 23 14:43:20 ws1.mydomain.tld systemd[1]: Started Remote desktop service (VNC).
Sep 23 14:43:25 ws1.mydomain.tld systemd[1]: vncserver@:3.service: control process exited, code=e...s=2
Sep 23 14:43:25 ws1.mydomain.tld systemd[1]: Unit vncserver@:3.service entered failed state.
-----------------------------------

System is fully updated Fedora 19 (9/23/13)

Emmett,

I'd suggest re-generating your vncserver@:N.service file from the template in /usr/lib/systemd/system/vncserver@.service. Your current unit file contains a mix of the non-daemonized fix ("Type=simple", "vncserver -fg") and the daemonized fix ("ExecStop", "PIDFile").

(I think the main problem is the ExecStop, which isn't used with Type=simple — systemd can just kill the vncserver process directly to stop it.)

I changed the service file to:

--------------------------------------
[Unit]
Description=Remote desktop service (VNC)
After=syslog.target network.target

[Service]
Type=simple
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
ExecStart=/sbin/runuser -l uname -c "/usr/bin/vncserver -fg %i -geometry 1590x998 -localhost -rfbport 5903 -nolisten tcp"

[Install]
WantedBy=multi-user.target
---------------------------------

And I still have the same problem.  The session starts (I see port 5903 open), then it disappears (I don't port 5903 open).

Here is the status report before it disappears:

-----------------------------------------------------
[root@ws1 emmett]# systemctl status vncserver@:3.service
vncserver@:3.service - Remote desktop service (VNC)
   Loaded: loaded (/usr/lib/systemd/system/vncserver@:3.service; disabled)
   Active: active (running) since Mon 2013-09-23 22:23:25 PDT; 1s ago
  Process: 22408 ExecStartPre=/bin/sh -c /usr/bin/vncserver -kill %i > /dev/null 2>&1 || : (code=exited, status=0/SUCCESS)
 Main PID: 22413 (runuser)
   CGroup: name=systemd:/system/vncserver@.service/vncserver@:3.service

Sep 23 22:23:24 ws1.webengineer.com systemd[1]: Starting Remote desktop service (VNC)...
Sep 23 22:23:25 ws1.webengineer.com systemd[1]: Started Remote desktop service (VNC).
-----------------------------------------------------

And here is is after it disapears:

-----------------------------------------------------
[root@ws1 uname]# systemctl status vncserver@:3.service
vncserver@:3.service - Remote desktop service (VNC)
   Loaded: loaded (/usr/lib/systemd/system/vncserver@:3.service; disabled)
   Active: inactive (dead)

Sep 23 22:13:16 ws1.domain.tld systemd[1]: Starting Remote desktop service (VNC)...
Sep 23 22:13:17 ws1.domain.tld systemd[1]: Started Remote desktop service (VNC).
--------------------------------------------------------

@Emmett: Have you tried taking out the -fg switch in the ExecStart part? That is what fixed my problem...

Doh.  That fixed it.  The file(s) now look like this:

-----------------------------
[Unit]
Description=Remote desktop service (VNC)
After=syslog.target network.target

[Service]
Type=simple
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
ExecStart=/sbin/runuser -l uname -c "/usr/bin/vncserver %i -geometry 1590x998 -localhost -rfbport 5903 -nolisten tcp"

[Install]
WantedBy=multi-user.target
---------------------------

And each vnc server session stays up until stopped using systemctl.

tigervnc-1.3.0-7.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/tigervnc-1.3.0-7.fc20

After you have tried running vncserver from a local login, you might need to specify the Desktop Manager, especially if you only have MATE Desktop installed.  I had to add the stop command and modify xstartup to make this work.  I did not need to remove the "-fg" toggle.

[Service]
Type=simple
# Clean any existing files in /tmp/.X11-unix environment
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
ExecStart=/sbin/runuser -l root -c "/usr/bin/vncserver -fg %i"
ExecStop=/sbin/runuser -l root -c "/usr/bin/vncserver -kill %i"


### ~/.vnc/xstartup
### fix for having only mate installed 
### - http://www.linuxreaders.com/2013/01/fix-blank-vnc-client-screen-on-mate-desktop-fedora.html
/usr/bin/mate-session

tigervnc-1.3.0-7.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.