OK, cool. That wasn't clear from the context, and might do with a
comment in the test, but at least doesn't regress anything.
On Tue, Jul 19, 2011 at 15:51, Josh Cooper wrote:
> I didn't change the daemon code itself (which already skips those signals).
> I just changed the spec test to match th
I didn't change the daemon code itself (which already skips those signals).
I just changed the spec test to match the implementation on Windows.
In other words, the decision to abandon or not was already made before these
changes were made. With that said, the implications of what happens on
Windo
...and the features they enable on Unix? What happens with those?
If there has been a decision to abandon, for example, the ability to
reload the configuration file of a running Puppet Agent in daemon
mode, then great. Otherwise something to indicate that this is still
pending would be awesome.
HUP, USR1, and USR2 are not supported on Windows, so I don't see any point
in writing a pending test for something that will never happen.
Josh
On Tue, Jul 19, 2011 at 3:36 PM, Daniel Pittman wrote:
> On Tue, Jul 19, 2011 at 14:59, Josh Cooper wrote:
> > The signals HUP, USR1, and USR2 are not
On Tue, Jul 19, 2011 at 14:59, Josh Cooper wrote:
> The signals HUP, USR1, and USR2 are not supported on Windows. The
> Puppet::Daemon code already skipped trapping these on Windows,
> but the spec test was expecting them to be trapped. This commit
> just updates the spec test to match the existin
The signals HUP, USR1, and USR2 are not supported on Windows. The
Puppet::Daemon code already skipped trapping these on Windows,
but the spec test was expecting them to be trapped. This commit
just updates the spec test to match the existing daemon code.
Reviewed-by: Jacob Helwig
Signed-off-by: J
