Bug #4624

SIGUSR1 should ignore splay

Added by eric sorenson over 1 year ago. Updated 5 months ago.

Status:Accepted Start date:08/26/2010
Priority:Normal Due date:
Assignee:- % Done:

0%

Category:agent
Target version:-
Affected Puppet version:0.25.5 Branch:
Keywords:splay signal usr1
Votes: 0

Description

When testing whether I could trigger an immediate run to a running puppetd, I found I could not. I can understand HUP (restart) simply causing a from-the-top restart of execution, but it surprised me that USR1 (reload) behaved the same. IMO if I’m actively sending a reload signal to the daemon, I’d like it to take action immediately, not restart the splay timer.

notice: Starting Puppet client version 0.25.5
info: Sleeping for 902 seconds (splay is enabled)

[1]+  Stopped                 puppetd --no-daemonize --debug
[root@pt-linux17 /etc/rc.d/init.d]# killall -USR1 puppetd
[root@pt-linux17 /etc/rc.d/init.d]# fg
puppetd --no-daemonize --debug
notice: Caught USR1; calling reload
info: Sleeping for 179 seconds (splay is enabled)

[1]+  Stopped                 puppetd --no-daemonize --debug
[root@pt-linux17 /etc/rc.d/init.d]# killall -USR1 puppetd
[root@pt-linux17 /etc/rc.d/init.d]# fg
puppetd --no-daemonize --debug
notice: Caught USR1; calling reload
info: Sleeping for 1366 seconds (splay is enabled)

History

Updated by eric sorenson over 1 year ago

Damn Trac curly-braces are hardwired into my brain. Please assume everything from ‘notice’ onwards is wrapped in a PRE tag.

Updated by Markus Roberts over 1 year ago

  • Status changed from Unreviewed to Needs Decision

Updated by James Turnbull about 1 year ago

  • Assignee set to Nigel Kersten

Updated by Nigel Kersten about 1 year ago

  • Status changed from Needs Decision to Accepted
  • Assignee deleted (Nigel Kersten)

Updated by Daniel Pittman 5 months ago

Normally, we only splay once. It isn’t clear what the best semantics around this would be:

  1. Always splay when we run (eg: as it is implemented now)
  2. Force an immediate run when you get the signal, but splay on the next scheduled run.
  3. Force an immediate run when you get the signal, and consider ourselves “splayed” already.

I agree that splaying when you are asked to run is wrong; so does the documentation.

I think that forcing an immediate run, but doing the splay normally next time around, is the right long term behaviour.

Updated by Nigel Kersten 5 months ago

+1 I concur.

Also available in: Atom PDF