Issue #3088 has been updated by Josh Anderson.

Estimated time set to 1.00

This problem was caused by changes to agent.rb introduced to fix Issue #2661. 
See the diff 
"here":http://projects.reductivelabs.com/projects/puppet/repository/revisions/adc0a4ed939a717e8735485d493bde28ceab5ac0/diff/lib/puppet/agent.rb
 .

As far as I can tell, what happens is that the modified rescue clause catches 
SystemExit and it doesn't make its way up the stack like it should. Therefore, 
the client stops running but doesn't actually exit.

You should be able to duplicate this by sending puppetd a SIGTERM in the middle 
of a configuration run. This is potentially an issue for anyone who uses a 
package manager (or other automated process) to deploy new versions of Puppet.

Adding a second rescue clause to each function which catches and re-raises the 
SystemExit has fixed this for me.

----------------------------------------
Bug #3088: Puppetd fails to stop after receiving SIGTERM
http://projects.reductivelabs.com/issues/3088

Author: Josh Anderson
Status: Unreviewed
Priority: Normal
Assigned to: 
Category: 
Target version: 
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.

Reply via email to