Hey John! Thanks for the responses and analysis of the situation! You're spot on in several areas which prompted this change in the first place. Comments inline:
> 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. > ... > 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. > > Yes - this is the exact issue which prompted us to use systemd to determine service status in Debian 8 / Ubuntu 15.04 and above. As you've mentioned below, this presented a very large dilemma for Puppet, as it could no longer properly manage these services through the systemd / sysvinit compatibility layer. It should be noted, however, that this only affects default installations which still include both the systemd and sysvinit bits. > > >> 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. > > The key difference here, I believe, is that Ghislain (and probably others) have actively purged systemd from their Debian 8 systems, such as by following this guide: http://without-systemd.org/wiki/index.php/How_to_remove_systemd_from_a_Debian_jessie/sid_installation. When doing this, you are effectively reinstating sysvinit as the chief init system and more or less reverting to how things worked back in Debian 7. >From my brief tests around this, it seems that the old init scripts which were LSB compliant are brought back and used, meaning that Puppet can work properly. All of this being said, I believe that the fix to use systemctl to determine service status is absolutely necessary on the default case of Debian 8 systems using the sysvinit / systemd compatibility layer (as is what you get upon a fresh installation). Not doing so breaks Puppet's ability to manage many services. However, I also think it's reasonable to check that systemctl is present on the system first, falling back to init scripts if it is not. This will allow use cases such as this one where systemd has been purged from the system. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/6dd17998-3be4-429c-9ace-27fa8cf4a42d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
