Issue #3088 has been updated by Mark Plaksin.
We're seeing something similar with 0.25.4rc2. We have a cron job that
restarts Puppet once a day. On Linux where we're using the init script
included with Puppet itself, restart says this: "Could not create PID file:
/var/puppet/run/puppetd.pid" This sometimes happens when I run
'/etc/init.d/puppet restart' on the command line.
Here's some sample craziness:
Starting puppet: [ OK ]
sock_0:~ # /etc/init.d/puppet restart
Stopping puppet: [FAILED]
Starting puppet: Could not prepare for execution: Could not create PID file:
/var/puppet/run/puppetd.pid
[ OK ]
On HP-UX and Solaris we have our own init scripts. They have various amount of
sleep time in them between stopping Puppet and trying to start it again. We
added the sleeps way back when because puppetd often took a while to go away
after we told it to stop. It looks like the same thing is happening on Linux
now.
With 0.25.4rc2 on HP-UX, there are times when puppetd *never* exits after being
sent a TERM signal.
----------------------------------------
Bug #3088: Puppetd fails to stop after receiving SIGTERM
http://projects.reductivelabs.com/issues/3088
Author: Josh Anderson
Status: Investigating
Priority: Normal
Assigned to:
Category:
Target version: 0.25.4
Affected version: 0.25.2
Keywords:
Branch:
This is a weird issue that I encountered while lab testing 0.25.2.
My setup: ruby 1.8.7p160, puppet 0.25.2, Solaris 10 SPARC and x86
Here's what happens:
1. If puppetd receives a SIGTERM during a config run, it fails to stop
completely. (Explanation below.)
2. If puppetd receives a SIGTERM when it's not in the middle of a run, it stops
normally.
What does failing to stop mean? It logs that it's stopping, closes all
logfiles, and then hangs. Truss says that it's poll()ing repeatedly.
To see exactly what happened, I inserted some not-very-clever tracing code into
daemon.stop:
<pre>
# Stop everything
def stop(args = {:exit => true})
if agent
set_trace_func Proc.new { |event, file, line, id, binding,
classname|
mesg = "[%8s] %30s %30s (%s:%-2d)\n" % [event, id, classname,
file, line]
File.open('/var/tmp/trace.txt', 'a') { |f| f.write(mesg) }
}
end
<pre>
The rather lengthy trace output for a failed stop ends with:
<pre>
[ return] __signal__ SignalEmitter
(/opt/ruby/lib/ruby/site_ruby/1.8/puppet/external/event-loop/signal-system.rb:98)
[ return] signal SignalEmitter
((eval):2 )
[ line] select EventLoop
(/opt/ruby/lib/ruby/site_ruby/1.8/puppet/external/event-loop/event-loop.rb:126)
[ call] sleeping! EventLoop
((eval):1 )
[ line] sleeping! EventLoop
((eval):2 )
[ return] sleeping! EventLoop
((eval):2 )
[ line] select EventLoop
(/opt/ruby/lib/ruby/site_ruby/1.8/puppet/external/event-loop/event-loop.rb:127)
[ c-call] + Array
(/opt/ruby/lib/ruby/site_ruby/1.8/puppet/external/event-loop/event-loop.rb:127)
[c-return] + Array
(/opt/ruby/lib/ruby/site_ruby/1.8/puppet/external/event-loop/event-loop.rb:127)
[ c-call] select IO
(/opt/ruby/lib/ruby/site_ruby/1.8/puppet/external/event-loop/event-loop.rb:127)
</pre>
I've attached log files and trace output for both successful and failed stops.
--
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://reductivelabs.com/redmine/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.
