ThinLinc version: 4.6.0post, build 5220. Server: Ubuntu 16.04 Server (x86_64), with ubuntu-desktop installed. Found when implementing bug 5742. > 2016-09-01 12:05:07,953: Installing services... > 2016-09-01 12:05:07,961: Installing service 'vsmserver'... > 2016-09-01 12:05:08,133: Output (stdout): > 2016-09-01 12:05:08,134: Cannot find /usr/lib/lsb/install_initd or /sbin/chkconfig. > 2016-09-01 12:05:08,134: Please make sure that vsmserver is started automatically at boot. > 2016-09-01 12:05:08,134: Failed to install service 'vsmserver'
There's an argument for this being a duplicate of bug 5828, but since that bug has been preoccupied with getting all the library dependencies installed I thought keeping this separate would allow it to get proper attention.
Installing and removing services is a big problem with distancing ourselves from LSB. We currently prefer the LSB utilities for installing and removing services, with fallbacks to distribution-specific tools to work around bugs for some cases. These LSB utilities are distribution-specific and are supplied by the distribution as part of their LSB packaging. If we replace "LSB-compliant" with a list of libraries in our list of requirements, we lose the ability to use the LSB scripts to install/remove services. For our recommended distributions, we'll be forced to use the distribution-specific tools for this - this is not a big deal given that we have only three recommended distributions. Where this is a problem is our supported-but-not-recommended distributions, where we have relied on the distribution's LSB packaging to provide scripts that integrate with their init system. The question is: can we still require install_initd/remove_initd/LSB for (some) distributions? If the answer is yes, we will have moved away from our initial decision to go down the "abandon LSB" path. I see no reason to have special lists of dependencies for RHEL if there's a perfectly good LSB support to be used. We can still adapt tl-setup to work with important platforms that lack LSB (Ubuntu, Suse.) If the answer is no, we will no longer be able to automatically install our software on systems that fulfills our requirements¹, moving the responsibility of managing this to the system administrator. I believe this calls into question both our commitment to having an installer that just works on supported distributions, and our attitude towards supported distributions. It used to be that "we think everything works, but no testing" - this would move us towards a "we know it won't work". ¹: unless you modify the requirements list with all Cendio-approved init systems.
Implemented as discussed on the developers meeting. Leaving the requirements documentation for bug 5828.
Works well on: - Ubuntu 16.04 - Fedora 24 - SLES 12 - RHEL 5 Not so well on: - openSUSE Tumbleweed It seems like openSUSE's chkconfig doesn't give systemd the nudge it needs. A 'systemctl daemon-reload' make systemd take notice though. However systemd thinks they are disabled, but they are still started on boot. I guess something executes legacy stuff in rc3.d. Perhaps we should avoid chkconfig on systemd systems to keep some sanity?
I looked in the wrong place. 'systemctl is-enabled' says that the services are enabled, even if they are done so via chkconfig. However we still need to run daemon-reload somewhere in the process. Switching over to systemd commands seems to work well on all systemd systems: systemctl daemon-reload systemctl enable ${service} (on SLES, RHEL and Ubuntu the daemon-reload wasn't needed) So the new code in install_service would be: if [ -x /bin/systemctl ] && systemctl >/dev/null 2>/dev/null; do /bin/systemctl daemon-reload /bin/systemctl enable ${service} elif...
(In reply to comment #14) > (In reply to comment #11) > (In reply to comment #12) > (In reply to comment #13) > > install_service, remove_service and service now tries to use systemctl if the > system looks to be using systemd. Tested installation of ThinLinc build 5239 on openSUSE Thumbleweed. Services was enabled and started as expected.
Also retested the following distributions and verified that services was enabled and running after tl-setup. - Ubuntu 16.04 - CentOS 6.8 - CentOS 7.0 Works as expected. Closing.
