I am working with TigerVNC on Fedora 33. The latest update on TigerVNC switches from vncserver to vncsession. Systemd unit file is updated to reflect the latest change. However, I cannot start VNC with the latest systemd unit file and I am debugging it. The service runs properly (I add -x to the wrapper bash code to see if the vncsession was called properly) and then service turns inactive.

The basic structure of the unit file is:

Type=forking
ExecStart=/.../vncsession-start DISPLAY

The vncsession-start is actually a wrapper:

...
exec /.../vncsession USER DISPLAY

The problem is when I systemctl start the service, it ends without error (only main PID is listed and ExitCode=0). But I run it in two other ways:

• run directly from bash: it runs, Xvnc launches
• modify unit file to ExecStart=/bin/bash -cx 'strace -f vncsession USER DISPLAY' and change Type=simple: Xvnc also launches

The first try is to rule out wrong vnc configurations; the second is to check SELinux setup.

The Type=forking handles fork() syscall, according to doc. I checked vncsession with strace, what I see is:

• bash exec vncsession
• vncsession calls clone(), not fork()
• vncsession then calls execev() to launch Xvnc

So my question is: what is the 1) proper Type= for this case, is forking the right choice? 2) how to debug this type of problem?

Thank you!

Update:

I have solved the problem. I will share my experience here:

• The new vncsession will fork and keep check status on the child
• The child checks /home/$USER/.vnc/. Actually the main issue is with this folder. It seems this folder is created before, and SELinux context is different than vncsession. Remove the folder and re-create password.
• Compile tigervnc following the RPM spec, remember that the RPM version uses prefix /usr but git version uses /usr/local.
• Replace all perror with syslog(LOG_CRIT, ... to truly capture the error message.

The main issue is the forked process' errors are not reflected in either in journalct -t vncsession or journalctl -u vncserver@:$DISPLAY. You need to modify vncsession's source code to find out the root cause.

Original question:

I am working with TigerVNC on Fedora 33. The latest update on TigerVNC switches from vncserver to vncsession. Systemd unit file is updated to reflect the latest change. However, I cannot start VNC with the latest systemd unit file and I am debugging it. The service runs properly (I add -x to the wrapper bash code to see if the vncsession was called properly) and then service turns inactive.

The basic structure of the unit file is:

Type=forking
ExecStart=/.../vncsession-start DISPLAY

The vncsession-start is actually a wrapper:

...
exec /.../vncsession USER DISPLAY

The problem is when I systemctl start the service, it ends without error (only main PID is listed and ExitCode=0). But I run it in two other ways:

• run directly from bash: it runs, Xvnc launches
• modify unit file to ExecStart=/bin/bash -cx 'strace -f vncsession USER DISPLAY' and change Type=simple: Xvnc also launches

The first try is to rule out wrong vnc configurations; the second is to check SELinux setup.

The Type=forking handles fork() syscall, according to doc. I checked vncsession with strace, what I see is:

• bash exec vncsession
• vncsession calls clone(), not fork()
• vncsession then calls execev() to launch Xvnc

So my question is: what is the 1) proper Type= for this case, is forking the right choice? 2) how to debug this type of problem?

Thank you!