Skip Menu |

This queue is for tickets about the Log-Log4perl CPAN distribution.

Report information
The Basics
Id: 60665
Status: resolved
Priority: 0/
Queue: Log-Log4perl
People
Owner: Nobody in particular
Requestors: ether [...] cpan.org
Cc:
AdminCc:
Bug Information
Severity: Normal
Broken in: 1.29
Fixed in: (no value)

History Show all quoted text
  Mon Aug 23 20:30:53 2010 bitcard [...] froods.org - Ticket created
Subject: Not every file is properly recreated when a signal is received, with recreate_check_signal
Log::Log4perl::Config::Watch is used to handle the appender config 'recreate_check_signal', which sets up a signal handler to recreate a file (e.g. if it was rotated out). However, it overwrites whatever signal handler was there before. *Perl signal handlers are global* -- there is only one hash table to store them all. Consequently, if there is more than one file appender set up, only one of them will be recreated on receipt of a signal. I have fixed this issue (with test cases) in the 'signal_handling_bug' branch at http://github.com/karenetheridge/log4perl.
  Thu Aug 26 00:45:16 2010 MSCHILLI [...] cpan.org - Correspondence added
Hi Karen, thanks for the patch. It looks like this is indeed a problem but there's an edge case where the solution won't work: $SIG{} entries can also be set to strings like 'IGNORE' or 'DEFAULT' (perldoc perlvar /SIG). It'd be easy to add a check/logic for that, but I wonder if there's a cookbook recipe for handling multiple sig handlers in a cooperative way?
  Thu Aug 26 00:45:16 2010 The RT System itself - Status changed from 'new' to 'open'
  Thu Aug 26 12:06:35 2010 ether [...] cpan.org - Correspondence added
On Thu Aug 26 00:45:16 2010, MSCHILLI wrote: Show quoted text
> It'd be easy to add a check/logic for that, but I wonder if there's a > cookbook recipe for handling multiple sig handlers in a cooperative way?
Good point; I'll look into it.
  Mon Aug 30 13:37:24 2010 ether [...] cpan.org - Correspondence added
On Wed Aug 25 21:45:16 2010, MSCHILLI wrote: Show quoted text
> It'd be easy to add a check/logic for that, but I wonder if there's a > cookbook recipe for handling multiple sig handlers in a cooperative way?
I've done some inquiries and it appears that the only systems for sharing signals like this are in big frameworks like AnyEvent or POE -- there is nothing if one doesn't make a lot of assumptions about the environment Log::Log4perl is running in. I'll keep looking around, but in the meantime I think the best we can do is simply accommodate the cases where the signal handler is a string.. this is at least better than wiping out whatever handler(s) were there before. commit 12b902f163f8cad9ed869934d4282b8be62232e8 Author: Karen Etheridge <ether@cpan.org> Date: Fri Aug 27 11:46:31 2010 -0700 don't attempt to call an old signal handler if it is a string like "IGNORE" or "DEFAULT". diff --git a/lib/Log/Log4perl/Config/Watch.pm b/lib/Log/Log4perl/Config/Watch.pm index d8115e3..6ebb51f 100644 --- a/lib/Log/Log4perl/Config/Watch.pm +++ b/lib/Log/Log4perl/Config/Watch.pm @@ -35,7 +35,7 @@ sub new { $SIG{$self->{signal}} = sub { print "Caught $self->{signal} signal\n" if _INTERNAL_DEBUG; $self->force_next_check(); - $old_sig_handler->(@_) if $old_sig_handler; + $old_sig_handler->(@_) if $old_sig_handler and ref $old_sig_handler eq 'CODE'; }; # Reset the marker. The handler is going to modify it. $self->{signal_caught} = 0;
  Tue Aug 31 00:54:24 2010 MSCHILLI [...] cpan.org - Correspondence added
Applied, thanks! http://github.com/mschilli/log4perl/commit/139c0d1619e5eb6cc8985f4b63e15cfb73248efe -- Mike
  Tue Aug 31 00:54:27 2010 MSCHILLI [...] cpan.org - Status changed from 'open' to 'resolved'
  Tue Oct 12 17:08:05 2010 RUZ_ADMIN - Requestor ETHER added
  Tue Oct 12 17:08:05 2010 RUZ_ADMIN - Requestor bitcard@froods.org deleted