Bug 5974 - tl-setup can't install services on Ubuntu 16.04
Summary: tl-setup can't install services on Ubuntu 16.04
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Server Installer (show other bugs)
Version: 4.6.0
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.7.0
Assignee: Karl Mikaelsson
URL:
Keywords: hean01_tester, ossman_tester, relnotes
Depends on:
Blocks: 5828 5829
  Show dependency treegraph
 
Reported: 2016-09-01 12:25 CEST by Karl Mikaelsson
Modified: 2022-04-22 07:59 CEST (History)
3 users (show)

See Also:
Acceptance Criteria:


Attachments

Description Karl Mikaelsson cendio 2016-09-01 12:25:23 CEST
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'
Comment 1 Karl Mikaelsson cendio 2016-09-01 12:43:25 CEST
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.
Comment 2 Karl Mikaelsson cendio 2016-09-02 11:13:01 CEST
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.
Comment 6 Karl Mikaelsson cendio 2016-09-06 13:58:52 CEST
Implemented as discussed on the developers meeting.

Leaving the requirements documentation for bug 5828.
Comment 9 Pierre Ossman cendio 2016-09-09 13:17:51 CEST
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?
Comment 10 Pierre Ossman cendio 2016-09-09 14:09:28 CEST
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...
Comment 15 Henrik Andersson cendio 2016-09-19 08:52:03 CEST
(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.
Comment 16 Henrik Andersson cendio 2016-09-19 09:56:39 CEST
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.

Note You need to log in before you can comment on or make changes to this bug.