If you use the TurboVNC Server init.d script/service, we need your help

[DRC]

Because systemd v260 dropped support for SysV init script emulation (and
some distributions, such as SUSE 16, had already done so prior to
systemd v260), it was necessary to convert the optional TurboVNC Server
init.d script/service to a systemd service.  Even though this is
technically a new feature rather than a bug fix, it is being treated as
a bug fix because the init.d script prevented the official TurboVNC
packages from being installed on SUSE 16.  Thus, the feature will land
in the upcoming TurboVNC v3.3.1 release.  However, there is some
potential for disruption if you currently use the init.d script/service,
so I need current users of that feature to test the new systemd service
in the 3.3.1 pre-release packages available here:

https://s3.amazonaws.com/turbovnc-pr/main/linux/index.html


Expected behavior:

- When upgrading from v3.3- to v3.3.1+, the v3.3- init.d scripts will be
removed.  (Thus, there should no longer be any *tvncserver files under
/etc/init.d or /etc/rc.d.)  When freshly installing the v3.3.1+ DEB, the
v3.3- init.d scripts will be removed as well, because the v3.3- DEB
didn't clean them up.

- When freshly installing (not upgrading to) v3.3.1+, the tvncserver
service will be disabled by default.  (Previously, the RPM packages
default-enabled it, and the DEB packages did nothing.)  You can change
the default by creating a systemd preset file (e.g.
/usr/lib/systemd/system-preset/00-turbovnc.preset) with "enable
tvncserver.service".

- When v3.3.1+ is completely removed (not upgraded or downgraded), the
tvncserver service will be stopped and disabled.  (Previously, the DEB
packages did nothing.)

- DEB only: When downgrading from v3.3.1+ to v3.3-, the tvncserver
service will be disabled (to avoid leaving an orphaned file under
/etc/systemd.)

- If started, the tvncserver service will remain running during a
package upgrade/downgrade.  (Previously, the RPM package restarted the
service during an upgrade.)  Thus, the TurboVNC packages can now be hot
patched on systems with active TurboVNC sessions.

- 'systemctl [start|stop|reload|restart|try-restart] tvncserver' work
the same as they did with init.d emulation.  ('systemctl reload
tvncserver' notably kills all TurboVNC Server processes not listed in
/etc/sysconfig/tvncservers.  That is TightVNC legacy behavior, and I
wouldn't mind removing it, but it shouldn't ever happen automatically.)


I have thoroughly tested the feature on Ubuntu 18-26, RHEL 7-10, Fedora
44, and openSUSE 15-16, but I'm not perfect.  Please let me know briefly
if it works/doesn't work on a particular platform or whether the
aforementioned behavior might cause problems in your compute environment.

DRC

[Torsten Kupke]

Hi DRC,

in /etc/init.d/tvncserver there was a comment

### If you are using LDAP or another distributed authentication system, then
### be sure to add any services needed for your distributed authentication
### system to the Required-Start line below.

And I always appended "nslcd" to that line, so that the LDAP service is
started before the TVNC service:

# Required-Start: $syslog nslcd

Will it be possible to achieve the same service start order also with
the new systemd service for TVNC? I would expect, that this could be
achieved by giving a file
like /usr/lib/systemd/system-preset/00-turbovnc.preset another name
starting with something else than "00". But currently there is only one
file named 90-systemd.preset in /usr/lib/systemd/system-preset/, which
seems to only start systemd-own services. So how can I now control, that
the LDAP service is started before the TVNC service?

BR,

tkansgar

[DRC]

The preset files are only for establishing whether a service should be
enabled or disabled by default.  The service order is specified in the
service files themselves.

In this case, no modifications should be required, because nslcd.service
runs before multi-user.target and tvncserver.service runs after
multi-user.target.  However, let me know if you run into any problems.

DRC