Puppet

Mart,

Could I get some more info on your environment? There shouldn’t be any way that the

unlock

method could return false (indicating a failure to unlock) and yet still actually delete the PID file. Is it possible that your init script is cleaning up the PID file itself after Puppet has shut down? It’s the only explanation that makes any sense to me at this stage.

I think the reason could be that I use —confdir

Mart,

I’m not sure what you’re saying.

—confdir

shouldn’t have any effect on the location of the PID file (that’s —rundir), and it certainly shouldn’t have any bearing on whether we can delete the PID file or not. Basically, the code looks like this:

if we_own_the_pid_file
  delete_the_pid_file
else
  print "Could not remove PID file"
end

If there’s some other reason we can’t delete the PID (because, for instance, we don’t have permission to delete that file) then a completely different error would appear — things would explode, actually (probably not what we’re after, now that I think about it; I might tighten that up a bit).

Basically, I can’t reproduce the symptoms you reported, and the code doesn’t appear to do anything that would cause your symptoms, so I need to know more about what you’re doing and what you’re doing it in to debug this problem.

Ok, I got it:

It happens when I use —listen, without the use of listen everything works fine.