Bug 4844 - systemd systems do not have /etc/init.d/<service>
Summary: systemd systems do not have /etc/init.d/<service>
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Other (show other bugs)
Target Milestone: 4.2.0
Assignee: Henrik Andersson
Depends on:
Blocks: 4294 4731
  Show dependency treegraph
Reported: 2013-10-11 15:45 CEST by Pierre Ossman
Modified: 2014-04-08 10:21 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:


Description Pierre Ossman cendio 2013-10-11 15:45:56 CEST
We have places in ThinLinc that assume services are started via SysV scripts. That is no longer the case with systemd so we need to be prepared to control them via systemctl (or possibly the service command). One example of this problem is the scripts that add ThinLinc CUPS queues.

Also see bug 4843 which is basically the same thing but for upstart.
Comment 1 Aaron Sowry cendio 2013-10-11 16:00:49 CEST
See also bug #4290
Comment 2 Henrik Andersson cendio 2014-01-30 16:11:04 CET
To clarify this bug:

On bug 4843 we added a service wrapper script to support starting / stopping of service on Ubuntu. This script uses the system provided 'service' command which in it turns is not a standard script but a wrapper script to handle multiple init systems.

We need to verify if this service script handles SysV services when used on a systemd only system or if we should explicitly use systemctl in our shipped service script. Our service wrapper script has a fallback to start/stop SysV services in that case.
Comment 3 Henrik Andersson cendio 2014-01-31 09:20:47 CET
With a Fedora 19 system the service wrapper script is shipped with initscripts package which provides the SysV inittab and /etc/init.d. This service script uses SysV services over SystemD if the service is available in both init systems.

There are a few pointers in http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/

SystemD has a compability layer upon SysV which is enabled at compile time. Fedora uses it but Arch does not. So it's all up to distributions decide if they should use both or just SystemD.

When SystemD have SysV compability starting a service which exists both as SystemS and SysV definition using systemctl, SystemD prioritizes the SystemD service over SysV.
Comment 4 Henrik Andersson cendio 2014-02-03 11:29:54 CET
After a lot of discussions around this issue, we are keeping the current approach using our service wrapper script. A new bug #4978 is created for explicit use of init system specific tools to solve identified problems.

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