tigervnc: a working runit service for the tigervnc vncserver cannot be written

[zmudc]

Is this a new report?

Yes

System Info

Void 6.3.13_1 x86_64-musl GenuineIntel/VM notuptodate rFFF (I am not sure why this is reporting notuptodate)

Package(s) Affected

tigervnc-1.12.0_1

Does a report exist for this bug with the project's home (upstream) and/or another distro?

TigerVNC/tigervnc#1649
TigerVNC/tigervnc#1651

Expected behaviour

The package is supposed to be able to configure a vncserver service on Xvnc displays configured in /etc/tigervnc/vncserver.users on an ordinarily configured Void installation. It is expected that the service will start and run correctly after enabling it, allowing the user or users configured in /etc/tigervnc/vncserver.users to connect to the tigervnc server for a remote session.

Actual behaviour

The service starts and stops immediately in an endless loop (every second I think) unless the down file is added to the service directory. And even with the down file, the service will not start with the 'sv once vncserver' command (assuming the runit service directory is named vncserver) but instead exits without successfully starting. Details of the causes of these problems follow...

The first error in the log (presuming sockog is configured according to the handbook) is:

2023-08-10T14:30:22.21984 auth.crit: Aug 10 14:30:22 vncsession[1311]: pam_open_session failed: 28 (Module is unknown)

This error appears in the /var/log/socklog/secure/current logfile with the default socklog configuration.

After fixing the PAM configuration, the service still fails with a different error, also in the /var/log/socklog/secure/current logfile:

2023-08-10T14:50:30.43823 auth.warn: Aug 10 14:50:30 vncsession[2384]: vncsession: vncserver exited with status=2

This error is caused by the fact that upstream expects an Xsession wrapper script to be at /etc/X11/xinit/Xsession or /etc/X11/Xsession but a typical Void installation lacks those files. Other major distros such as Debian and Fedora have such files, but not Void.

This can be fixed by patching the vncserver perl script provided by upstream so it can find an appropriate Xsession wrapper script on Void.

After fixing the Xsession wrapper script, there is the third problem: The vncsession binary provided by upstream forks, detaches, and runs in the background without providing an option (not even a debug option) to run in the foreground, and this is totally incompatible with Void's runit system. This is also the cause of the endless loop of stop and start without having the down file in the service directory. This can be fixed by patching the vncession.c file in the upstream source so it runs in the foreground. That is what the above mentioned pull request to the upstream project does, but so far the upstream project has not responded in any way to the PR.

A PR has also been submitted to void-packages to fix all these issues and update the package to version 1.13.1:

#45307

Steps to reproduce

1. Install the XFCE desktop from the live image (I used the x86_64-musl version). I also did not do a network install to get the installation to have the XFCE desktop installed.
2. Update the system (i.e.: sudo xbps-install -Su)
3. Configure ordinary logging according to the handbook with socklog
4. Install the tigervnc package: sudo xbps-install tigervnc
5. Configure it according to the man pages (start with man vncsession): This requires at least mapping a user to display :1 in /etc/tigervnc/vncserver.users and also the other configuration files should be tweaked to set the session=xfce and the geometry to whatever your vnc viewer will support. Also, keep security settings in mind and listen only on localhost if you are not on a trusted network. Note that vncpasswd for some reason does not display a prompt to set a vncpasswd but it still works - you need to enter the password and hit enter, enter the password again and then it will ask if you want to enter a read-only password. And the password is changed successfully even without the prompt by vncpasswd.
6. Write an appropriate runit service according to the handbook. Hint: because the vncsession binary forks, detaches, and runs in the background, the run script needs to use fghack from the daemontools package (an ugly hack) unless the patch mentioned in Add option to run vncsession without forking and detaching TigerVNC/tigervnc#1651 is applied. If the vncsession.c file is patched so vncsession runs in the foreground, the main command needed in the run script is something like:
   exec /usr/libexec/vncsession-start "${DISPLAY:-:1}"
   Otherwise, you will need to use the ugly hack using fghack provided by the daemontools package:
   exec fghack /usr/libexec/vncsession-start "${DISPLAY:-:1}"
7. Observe the service does not start unless the fixes mentioned in tigervnc: update to 1.13.1, add service directory #45307 are applied.

[zmudc]

As @ahesford says here:

#45307 (comment)

Void will not accept the patch to not daemonize vncsession until upstream accepts it.

Therefore, this issue cannot be fixed without help from upstream, and upstream seems not interested in supporting systems like Void that do not use a Type=forking systemd service. For example, see the comment of an upstream developer here about non-systemd systems:

TigerVNC/tigervnc#1443 (comment)

and this comment of the same upstream developer which places the burden on downstreams like Void to adjust the upstream TigerVNC server to work with non-systemd service managers that downstreams might use:

TigerVNC/tigervnc#1443 (comment)

This makes it difficult to use the TigerVNC server on Void in a manner that upstream intends, because AFAICT Void does not currently have a way to port a Type=forking systemd service to runit, and upstream is not willing to do the work of supporting non-systemd system managers like runit on Void.

So what is the solution for the problem of porting an upstream component like vncsession that forks and is therefore not compatible with Void's runit system? Do we just say we cannot use that upstream component in the official Void packages?

[ahesford]

I don't see why upstream wouldn't accept a simple "don't daemonize" flag, which carries essentially no maintenance burden on them, doesn't involve ensuring that it works with any supervisor, and would generally be useful for debugging anyway.

[zmudc]

I don't see why upstream wouldn't accept a simple "don't daemonize" flag, which carries essentially no maintenance burden on them, doesn't involve ensuring that it works with any supervisor, and would generally be useful for debugging anyway.

Well, I guess we can wait and see if they review the PR I submitted upstream in which I point out there is not much much cost to adding the flag. So far, they have ignored the PR, and their comments about supporting non-systemd systems are not encouraging. Essentially, upstream is saying, "it's not our bug, it is downstream's bug if downstream can't use a systemd Type=forking service."

[ahesford]

Your entire issue is predicated on a failure to understand the behavior of runsv and an inability to make "an appropriate runit service" (which Void does not provide) control a daemonizing process. This is not a bug.

[zmudc]

Your entire issue is predicated on a failure to understand the behavior of runsv and an inability to make "an appropriate runit service" (which Void does not provide) control a daemonizing process. This is not a bug.

The issue was predicated on the fact that no one told me, until now, that Void has a strict policy requirement that runit services must run in the foreground. Not just that it is expected,
as the Handbook says.

[ahesford]

You seem incapable of distinguishing "policy" from "design requirements". The operation of runsv is described thoroughly in its manual page. The runit FAQ linked in the handbook also clearly states that processes must remain in the foreground. We expect users to read the documentation and, especially if they attempt to design custom components like system services, understand the mechanisms they are using.

Your service is broken because the run script you wrote fails to meet the requirements of runsv, plain and simple.