I understand your dissatisfaction, but I feel obligated to observe
that Puppet isn't forcing you to do anything. *Because of
peculiarities in Debian*, Puppet cannot properly manage services on
some versions of that distro via straight sysV initscripts. This in
no way forces you to install systemd; you also have the alternative of
not managing services via Puppet in this quirky environment.
Inasmuch as this particular characteristic apparently affects only
newer versions of Debian (and Debian-derived Ubuntu), I'm inclined to
suppose that it arises in part because of a shift in Debian away from
SysV init infrastructure, which indeed seems to have become quite the
thing to do in the last few years. If you want to complain about
someone driving you toward systemd, I suggest you focus on your distro
itself.
John
hi,
i am sorry that you take it that way, i am not here to argue with you
if you think debian is a quirky distribution, that may be the case but
this is the one we use so that's why i found this issue.
The fact is that debian has 2 system of init to chosse, sysV and the
systemd ecosystem that do init but also so many other thing that it
cannot be used in a lot of chroot like scenario.
Right now until this particular push of new code all was working as
intended for us, but this code was added in the service sysV init
provider a check of systemD in the sysvinit part. So you can be an
advocate of systemd and there is no problem on that but sytemd cannot
work on a lot of situations and i do not see the point of calling it
inside a sysvinit part without any way to ovveride this choice :) If
people install systemd they will use the systemd provider not the
sysvinit one.
Debian offer me the choise between systemd and sysinit and the
modification to the service provider simply make things hard and
increase surface of problems as even with sysvinti system we must now
install the systemd packages and all the dependency hell (and even the
wrapper install daemon cgroup crtl script and a bunch of thing
unneeded). Your solution on maintening my own system instead of running
puppet is rather an unexpected answer.
the problem you refers to should be the distro problem to fix the
init.d script that do not behave like you want them (ie return reliable
value on status), i do not think you should break ascended compatibility
to ack that some script do not respond like puppet want. I know that a
lot of sysvinit script return unreliable values but this was, is, and
will be the case. Why break the compatibility for this ? For all
services ? Best case scenario people fix the scripts, worst case it goes
away in debian9 as we will all move to freeBSD or use systemd anyway.
Also i assume it should not be that hard to test for the systemd package
to be present to allow this test or not and therefor make ascended
compatibility work as it was before this code change :)
best regards,
Ghislain.
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/565C7684.2050000%40aqueos.com.
For more options, visit https://groups.google.com/d/optout.
