[Pkg-puppet-devel] Bug#775795: Patch to use /usr/sbin/service in Debian service-provider

[Apollon Oikonomopoulos]

Hi,

On Fri, 06 Feb 2015 15:49:17 +0200 Faidon Liambotis <paravoid at debian.org> wrote:
> This seems like a nice approach for status/start/stop/restart but 
> unfortunately doesn't address enabled?/enable/disable at all. For 
> starters, puppet seems to call update-rc.d with "defaults", not 
> "enable". Even "enable", though, does not seem to be sufficient for 
> systemd-only service files :(
> 
> enabled? is similarly broken: it calls invoke-rc.d --query, which 
> returns 105 for test.service and puppet handles 105 by proceeding to 
> check for symlinks under /etc/rc*.d/...
> 
> Finally, self.instances is also broken, as it just lists /etc/init.d 
> init files. The systemd provider calls "systemctl list-unit-files --type 
> service --full --all" instead.
> 
> Honestly, I'd just switch the default provider for Debian 8+ to systemd 
> and let users who use a non-default init system handle it in their 
> manifest by supplying provider => debian or provider => upstart.

Unfortunately, switching the default provider to systemd wouldn't work 
either (see below). Besides that, we still have architectures where sysv-rc is
the default.

To put things in perspective, we currently have three types of services:

 A those shipping an initscript only
 B those shipping and initscript and a systemd service file
 C those shipping only a systemd service file and no initscript. This 
   type includes all systemd-specific services, and - inevitably - many 
   services written/managed by sysadmins.

Gaudenz's patch makes sure that start/stop works for all three types of 
services, however it does not change the enable/disable logic nor the 
service listing, which are still problematic:

 - `update-rc.d enable|disable' does not work for type C services, as 
   demonstrated by Faidon.
 - `update-rc.d -f remove && update-rc.d defaults' as currently used in 
   the `enable' does *not* enable type C *and* type B services at all.  
   `update-rc.d enable' would enable type B services but not type C.
 - querying service enable status using invoke-rc.d also doesn't work 
   for type C services.

If OTOH we were to change the default provider to systemd, we wouldn't 
be much better off:

 - `systemctl is-enabled' doesn't work for type A services, which are 
   still the majority:

   $ systemctl is-enabled ferm
   Failed to get unit file state for ferm.service: No such file or directory

 - `systemctl list-unit-files' as used by systemd's self.instances, does 
   not list type A services as well:

   $ systemctl list-unit-files --all --type service --no-pager | grep ferm
   $

So, we actually need a hybrid provider that will do the following:

 - Detect if we're running systemd as PID 1. This is trivial to do by 
   checking for the existence of /run/systemd/system.

 - Keep compatibility with sysv-rc (and I'd suggest to drop pre-2.88 
   support and spare an ugly call to dpkg).

 - If running under systemd:
   • Use `systemctl enable|disable' for *all* services. This works 
     correctly with our current systemd version for all three types of 
     services and invokes update-rc.d if appropriate.

   • Use `systemctl is-enabled` to query for enabled services only for 
     types B and C. Type A services can be detected because their 
     (auto-generated) units have the SourcePath property set to the 
     initscript path:

     $ systemctl show -pSourcePath ferm.service
     SourcePath=/etc/init.d/ferm

     For type A we need to keep the current invoke-rc.d implementation.

   • For self.instances, augment the type B and C services returned by
     `systemctl list-unit-files' with type A services from the init provider's
     self.instances.

The attached patch on top of 3.7.2-2 (hopefully) addresses all of these 
issues (and drops support for pre-2.88 sysv-rc if you don't mind). I 
have not tested it on a sysvinit Jessie system though, so if anyone could do
this it would be appreciated!

Cheers,
Apollon

P.S.: I'm a member of the Puppet maintainers team, but I haven't touched 
      the package (yet :). I could do an upload if anyone else can't.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-service-listing-and-enable-disable-in-Debian.patch
Type: text/x-diff
Size: 6229 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-puppet-devel/attachments/20150227/d43f120b/attachment-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-puppet-devel/attachments/20150227/d43f120b/attachment-0001.sig>