Issue #12465 has been updated by Andreas Ntaflos.
As discussed with _rc on IRC, the described behaviour is due to the fact that during an active puppet run (as triggered by `puppet agent --verbose --no-daemonize --onetime`) the status reported by `/etc/init.d/puppet status` indicates that a puppet daemon is indeed running. This, however, only happens when the system uses the patched LSB init functions, as mentioned above. Why is that? Because the unpatched, and broken `status_of_proc`, or, more specifically, `pidofproc` function (as per [https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/683640](https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/683640)) always returns *4* when called like in the puppet init script, with a `${PIDFILE}` as argument: status_of_proc -p "${PIDFILE}" "${DAEMON}" "${NAME}" This is because when the daemon is not running, *there is no PID file* to check, so `pidofproc` always fails. This works in puppet's favour, which only checks if the return value of the status operation is zero (0) or non-zero (!=0). However, the patch from bug 683640 restores the correct behaviour, namely that the existence or absence of a PID file is not enough to check if a daemon is running. If no PID file is specified then `pidofproc` uses `/bin/pidof` to check the process table for a matching process (`/usr/bin/puppet` in this case). And of course it will find a running puppet process during an active puppet run. So the real bug here is either in the "debian" service provider, or the puppet init script. It used to work only because of the broken implementation of `status_of_proc`/`pidofproc` in `/lib/lsb/init-functions`. Once this brokenness goes away (hopefully soon and officially, though I dare not get my hopes up) the problems I describe here will not affect just me, but anyone who uses Ubuntu (and probably Debian) and puppet. To fix this it somehow must be possible to differentiate between a puppet run that has been initiated by `--onetime --no-daemonize` and a regular puppet run. As it is now (with patched LSB init functions), the init script will always report that the puppet daemon is running, even when it is only a `--onetime` run. This results in puppet always trying to stop the puppet daemon, when so instructed by `ensure => stopped`. ---------------------------------------- Bug #12465: Puppet misinterprets return value of "/etc/init.d/puppet status" (3) on Ubuntu 10.04 as "daemon is running" https://projects.puppetlabs.com/issues/12465 Author: Andreas Ntaflos Status: Needs More Information Priority: Normal Assignee: Category: service Target version: Affected Puppet version: 2.7.10 Keywords: Branch: We run our puppet agents from cron and thus want to make sure the puppet agent daemon is not running. We use `ensure => stopped` in a `puppet::agent::service` class: service { 'puppet': ensure => 'stopped' enable => 'false', hasstatus => true, hasrestart => true, require => Class['puppet::agent::install'], } Problem is, puppet always thinks the service is running and therefore stops it, even when the service is not actually running. See this `--debug` output: debug: Service[puppet](provider=debian): Executing '/etc/init.d/puppet status' debug: Service[puppet](provider=debian): Executing '/etc/init.d/puppet stop' notice: /Stage[main]/Puppet::Agent::Service/Service[puppet]/ensure: ensure changed 'running' to 'stopped' The return value of `/etc/init.d/puppet status` is **3**, which is correct (see next paragraph), since the puppet agent is not running. But apparently this return value gets misinterpreted by puppet as "agent is running" or at least "status unknown". This is on Ubuntu 10.04.3, which I suspect is the reason for this problem. Ubuntu 10.04 (and up) has a long-standing bug in `status_of_proc` (from `/lib/lsb/init-functions`) that makes it always return **4** ("program or service status is unknown") instead of **3** ("program is not running"), when the daemon in question is not running, even when **3** would be the correct value. Of course this is a constant source of irritation among anyone who works with and needs LSB-compliant init scripts. I am sure the puppet devs have had their share of frustration in this regard. I know I have. This bug is described in [https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/683640](https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/683640). I applied the simple patch provided there to `/lib/lsb/init-functions` so that `status_of_proc` returns the correct values. We need that so that our Corosync/Pacemaker clusters can correctly manage LSB services. So it seems that puppet only interprets a return value of **4** as "daemon not running", even though it should properly treat **3** as such, as well. Is this a bug in puppet and/or an unfortunate side-effect of dealing with the Ubuntu-specific brain damage in `status_of_proc`? Note that this problem only occurs on systems where I have patched `status_of_proc` to work correctly. Is there anything that I can do to further debug this? I have tried finding where this behaviour comes from but it seems I am not fluent enough in Ruby and the puppet source tree to do any good. Running puppet 2.7.10 from apt.puppetlabs.com on Ubuntu 10.04.3. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
