On Monday, November 30, 2015 at 11:16:17 AM UTC-6, Aqueos Aqueos wrote: > > > > > > 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. >
Please allow me to clarify that I have no particular objection to nor animosity for Debian 8 "Jessie", or any earlier version of Debian. Nevertheless, Jessie absolutely is "quirky" in the objectively measurable sense that under some circumstances, the "status" command of its SysV init scripts returns 0 when the LSB specifications dictate a different return value. Others less generous than I might instead characterize that as a "flaw", or even a "bug". This particular quirk presents a problem for Puppet, and therefore for you. > > 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. > Debian 8 moves from SysV as the default init system (and systemd available as a technology preview) to systemd as the default init system and SysV as a backwards-compatibility alternative. IIRC, it also provides other alternatives, including at least upstart. Although it is not exactly wrong to describe that as "[D]ebian has 2 system of init to chosse[sic]", doing so doesn't really present an accurate picture. > > 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. > > I am not advocating for systemd. I am simply observing that Debian seems to have embarked on a switch to it, inasmuch as systemd is not just an alternative init system but the *default* init system for Jessie. Correlated with that switch, the behavior of the Debian SysV initscripts has changed so that the whole subsystem is no longer LSB-compliant. As a result, the approach Puppet takes to managing services on earlier versions of Debian *does not work reliably* on Jessie. Using the old system for Jessie was not a viable option. > 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. > > Debian seems not to offer quite the choice you think it does, as opting for sysvinit on Jessie is subtly inequivalent to using sysvinit by default on earlier Debians. As for packages, I have to take your word for what and how many packages are required, and for how much trouble that is. I confess, however, that I had supposed Apt to be a lot more capable and convenient than you seem to imply, and Debian's package collections -- even "unstable" -- to be more internally consistent. In any event, if the Puppet changes necessitated by the sysvinit changes in Jessie cause Puppet to cease to be advantageous for service management for you, then why would you continue using Puppet for that purpose? I hardly think it should be surprising to suggest preferring an alternative that is easier for you. I *do*, however, object to the assertion that Puppet forces you to do anything, as if you had no choice in the matter. With that said, you can perhaps adapt to the changes by supplying explicit 'status' commands for your Service resources, overriding the systemctl command Puppet uses on Jessie. Inasmuch as this overrides the provider, you would have to manually ensure that it applies only to systems for which the chosen command is appropriate. Alternatively, if you are managing only whether the service is currently running, as opposed to whether it is enabled to run automatically at system startup, then perhaps you would get the behavior you seem to want by choosing the 'init' provider instead of 'debian'. > 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. > What Puppet prefers is compliance with LSB *standards*. That's not an arbitrary whim, and Debian used to provide it. Jessie no longer does. Puppet does not demand that either you or Debian change that; instead it implements a workaround. Since you don't like that, either, I'm rather at a loss to determine what you think it should have done instead to solve the problem. > 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 ? > As I understand it, the problem is not individual init scripts, but rather a general change / new feature in sysvinit. As a result, Puppet on Jessie could not reliably use the old method to manage *any* service. Puppet did not break compatibility because Jessie already had done -- for all services, albeit not under all circumstances. > 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. > Doing nothing was not an option. The fix did not come arbitrarily out of thin air; the comments preceding the change show that a problem was discovered, diagnosed, and solved. > 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 :) > > Puppet's way would be to test for the systemctl program, rather than for a package. Indeed, although all bets are off when you run in --noop mode, if in normal mode the provider does not test for the availability of systemctl before trying to use it then that would be an issue appropriate for a ticket. HOWEVER, that does not mean that the old behavior would be a good option in the event that systemctl is not found. The old behavior is inappropriate on Jessie regardless of whether systemd or any part of it is installed. John -- 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/605e5ee5-7dbd-42cb-9c6c-b85f1d198666%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
