Bug#775795: puppet: Service's debian provider assumes SysV init
Hi, This is especially broken for jessie default installs, which are systemd now. Service definitions -probably amongst the most used ones- are assuming init.d semantics, unless provider = systemd is supplied as an argument. The only reason puppet is not completely broken on jessie is that most packages still ship an init.d script [...] and with good reason (backward compatibility)! Which specific packages does this break in jessie? However, this means that Service (without an explicit provider) is broken for at least those two use cases: - enable = false/true doesn't work for packages that ship a systemd unit file, enabling/disabling uses update-rc.d -- this is not compatible with systemd? In that case: what is the widely compatible interface to enable and disable a service? - Service doesn't work at all with user-supplied systemd units or for (custom, mostly) packages that do not ship init.d scripts. No change compared to wheezy -- where's the regression? br, -- Robert BihlmeyerASSISTArrow ECS Internet Security AG -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775795: [Pkg-puppet-devel] Bug#775795: puppet: Service's debian provider assumes SysV init
Faidon Liambotis parav...@debian.org writes: On Debian systems (i.e. on $::operatingsystem == debian), the default provider is debian; this is a separate provider that inherits the init provider but overrides a few methods to add invoke-rc.d support. The systemd provider, on the other hand, is default only for osfamily archlinux and for osfamily redhat operatingsystemmajrelease 7. Is Puppet *using* invoke-rc.d for all actions? If so, this should actually work properly, I think, since that should use systemd where appropriate. Or did you mean update-rc.d instead of invoke-rc.d? However, this means that Service (without an explicit provider) is broken for at least those two use cases: - enable = false/true doesn't work for packages that ship a systemd unit file, - Service doesn't work at all with user-supplied systemd units or for (custom, mostly) packages that do not ship init.d scripts. At first glance, and without looking at any of the details, it seems like an appropriate fix would be for Puppet to just use the service command for start/stop/restart/reload/status, and update-rc.d for enable/disable. That should do the right thing in all three init systems. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775795: puppet: Service's debian provider assumes SysV init
Package: puppet Version: 3.7.2-1 Severity: serious Hi, Puppet has an abstraction concept called provider for its types. The Service type, one of puppet's basic types, is implemented by multiple different providers, depending on the underlying init system. There is the init provider, which implements SysV init semantics, systemd upstart which implement systemd and upstart semantics respectively, etc. The default provider on each system is assigned using facter rules, apparently relying on operatingsystem and osfamily facts. On Debian systems (i.e. on $::operatingsystem == debian), the default provider is debian; this is a separate provider that inherits the init provider but overrides a few methods to add invoke-rc.d support. The systemd provider, on the other hand, is default only for osfamily archlinux and for osfamily redhat operatingsystemmajrelease 7. This is obviously broken behavior -- puppet shouldn't make assumptions about the init system a system runs purely from its OS version. That is mostly tracked upstream with PUP-2023[1]. This is especially broken for jessie default installs, which are systemd now. Service definitions -probably amongst the most used ones- are assuming init.d semantics, unless provider = systemd is supplied as an argument. The only reason puppet is not completely broken on jessie is that most packages still ship an init.d script alongside a system service file and LSB init-functions make sure those init.d scripts call systemctl instead. However, this means that Service (without an explicit provider) is broken for at least those two use cases: - enable = false/true doesn't work for packages that ship a systemd unit file, - Service doesn't work at all with user-supplied systemd units or for (custom, mostly) packages that do not ship init.d scripts. This is borderline important serious in my mind, but it is a regression for Wheezy and it should probably be fixed in time for jessie, so I'm setting this to an RC severity. This could be potentially worked around by setting systemd as the default provider for kernel == Linux operatingsystem == Debian operatingsystemmajrelease = 8. This would be a hack, of course, as jessie optionally supports booting with SysV as well so a more dynamic/runtime check will be a better but more complicated fix. Regards, Faidon 1: https://tickets.puppetlabs.com/browse/PUP-2023 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
