Skip Menu |

This queue is for tickets about the Schedule-Cron CPAN distribution.

Report information
The Basics
Id: 4917
Status: resolved
Priority: 0/
Queue: Schedule-Cron

People
Owner: roland [...] cpan.org
Requestors: Luca.Bolcioni [...] yacme.com
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 0.05
Fixed in: 0.97



Subject: Reaper problem (?) [patch provided]
Module: Schedule-Cron 0.05 Perl: 5.6.1 OS: Linux 2.4.18 (RH 7.3) Apply patch with: patch -p0 < schedule-cron-lb.patch Hope it helps. When run from a process (e.g. Proc::Simple) that has installed its own signal handler for $SIG{CHLD} zombies are generated whenever a dispatched process terminates. My patch borrows the reaper code from Proc::Simple (a simplified one) and installs a new $SIG{CHLD} only when Schedule::Cron->run is executed. It also keeps track on the spawned children trying to reap them individually without blocking. This is useful if there is a long running task (say task A). Using the original reaper, if a second task B, started after task A, finishes before it, a third task C will have to wait. This causes task C to start its activity in an unpredictable moment.
diff -ruN Schedule-Cron-0.05/Cron.pm Schedule-Cron-0.05-lb/Cron.pm --- Schedule-Cron-0.05/Cron.pm Wed Jul 5 10:02:26 2000 +++ Schedule-Cron-0.05-lb/Cron.pm Mon Jan 12 19:23:24 2004 @@ -71,6 +71,7 @@ use Time::ParseDate; use Data::Dumper; +use POSIX ":sys_wait_h"; use strict; use vars qw($VERSION $DEBUG); @@ -79,6 +80,7 @@ $VERSION = q$Revision: 1.5 $ =~ /(\d+)\.(\d+)/ && sprintf("%d.%02d",$1-1,$2 ); my $DEBUG = 0; +my %STARTEDCHILD = (); my @WDAYS = qw( Sunday @@ -116,13 +118,14 @@ ); sub REAPER { - my $waitedpid = 0; - while($waitedpid != -1) { - $waitedpid = wait; - } - $SIG{CHLD} = \&REAPER; + foreach my $pid (keys %STARTEDCHILD) { + if (my $res = waitpid($pid, WNOHANG) > 0) { + # We reaped a truly running process + delete $STARTEDCHILD{$pid}; + } + } } -$SIG{CHLD} = \&REAPER; + =item $cron = new Schedule::Cron($dispatcher,[extra args]) @@ -444,6 +447,9 @@ $self->build_initial_queue; die "Nothing in schedule queue" unless @{$self->{queue}}; + $SIG{'CHLD'} = \&REAPER; + + my $mainloop = sub { while (42) { my ($index,$time) = @{shift @{$self->{queue}}}; @@ -672,7 +678,9 @@ if ($pid = fork) { # Parent - return; + # Register PID + $STARTEDCHILD{$pid} = 1; + return; } else { # Child my $dispatch = $self->{dispatcher};
Hello Luca, [guest - Mon Jan 12 13:27:03 2004]: Show quoted text
> When run from a process (e.g. Proc::Simple) that has installed its own > signal handler for $SIG{CHLD} zombies are generated whenever a > dispatched > process terminates. > My patch borrows the reaper code from Proc::Simple (a simplified one) > and installs a new $SIG{CHLD} only when Schedule::Cron->run is > executed. It also keeps track on the spawned children trying to > reap them individually without blocking. This is useful if there is > a long running task (say task A). Using the original reaper, if a > second task B, started after task A, finishes before it, a third > task C will have to wait. This causes task C to start its activity > in an unpredictable moment.
Thanks a lot for your patch, which will I include in the next version of Schedule::Cron (which I plan to released in the next few weeks) However, I still see some problems with SIGCHLD handlers installed from outside Schedule::Cron, since they will get lost with your approach. Probably REAPER should remember and call the old handler as well..... ...roland
[ROLAND - Mon Jan 26 05:32:54 2004]: Show quoted text
> > Thanks a lot for your patch, which will I include in the next version > of Schedule::Cron (which I plan to released in the next few weeks) > > However, I still see some problems with SIGCHLD handlers installed from > outside Schedule::Cron, since they will get lost with your approach. > Probably REAPER should remember and call the old handler as well..... > > ...roland
Hi Roland. The patch I suggested works in my special case ..... I can't really say if it definitely solves the problem with zombies and the like. For sure what I can offer you is a test bench for your next release. Let me know as soon as you will be ready so that I can provide you with some (i hope useful) feed back.
From: adam [...] marchex.com
This appears to still be an issue in the latest version of Schedule::Cron (0.9). Is there an ETA for having this patch comitted? [guest - Thu Jan 29 17:32:30 2004]: Show quoted text
> [ROLAND - Mon Jan 26 05:32:54 2004]: >
> > > > Thanks a lot for your patch, which will I include in the next version > > of Schedule::Cron (which I plan to released in the next few weeks) > > > > However, I still see some problems with SIGCHLD handlers installed from > > outside Schedule::Cron, since they will get lost with your approach. > > Probably REAPER should remember and call the old handler as well..... > > > > ...roland
> > > Hi Roland. > > The patch I suggested works in my special case ..... I can't really say > if it definitely solves the problem with zombies and the like. > > For sure what I can offer you is a test bench for your next release. Let > me know as soon as you will be ready so that I can provide you with some > (i hope useful) feed back.
Hi Luca, [guest - Tue Aug 2 19:23:15 2005]: Show quoted text
> This appears to still be an issue in the latest version of > Schedule::Cron (0.9).
Sorry for the very looong delay, but I didn't worked on it quite for a time. I have to confess, I forgot to apply the patch for the 0.9 release. Show quoted text
> Is there an ETA for having this patch comitted?
I'm planning a 0.91 release for next week (exclusively for your patch ;-). Show quoted text
> > For sure what I can offer you is a test bench for your next release. Let > > me know as soon as you will be ready so that I can provide you with some > > (i hope useful) feed back.
It would be very nice, if you could add some tests until next week for this functionality. I attached the current Cron.pm, which contains your patch + possibly chained calling to an already existant child handler. ciao .... ...roland

Message body is not shown because it is too large.

Hi, On Di. 02. Aug. 2005, 19:23:15, guest wrote: Show quoted text
> This appears to still be an issue in the latest version of > Schedule::Cron (0.9). > > Is there an ETA for having this patch comitted?
so, finally, I made it to a new release. Could please checkout Cron::Schedule 0.96, which includes your patch ? It should fix this particular problem. sorry for the long silence ..... ...roland Show quoted text
> > [guest - Thu Jan 29 17:32:30 2004]: >
> > [ROLAND - Mon Jan 26 05:32:54 2004]: > >
> > > > > > Thanks a lot for your patch, which will I include in the next version > > > of Schedule::Cron (which I plan to released in the next few weeks) > > > > > > However, I still see some problems with SIGCHLD handlers installed
from Show quoted text
> > > outside Schedule::Cron, since they will get lost with your approach. > > > Probably REAPER should remember and call the old handler as well..... > > > > > > ...roland
> > > > > > Hi Roland. > > > > The patch I suggested works in my special case ..... I can't really say > > if it definitely solves the problem with zombies and the like. > > > > For sure what I can offer you is a test bench for your next release. Let > > me know as soon as you will be ready so that I can provide you with some > > (i hope useful) feed back.
> >
Subject: Reaper problem - introduces a bug
From: DRTECH [...] cpan.org
Hi there Your latest patch for $SIG{CHLD} introduces a bug, because it assumes that handlers are only code refs, while they can be set to DEFAULT or IGNORE as well. I have attached a patch to check that it is a coderef before trying to execute it. Thanks Clint
diff -ruN Schedule-Cron-0.96/Cron.pm Schedule-Cron-0.96-sigchld_ignore/Cron.pm --- Schedule-Cron-0.96/Cron.pm 2006-11-05 18:13:41.000000000 +0100 +++ Schedule-Cron-0.96-sigchld_ignore/Cron.pm 2006-11-25 16:32:06.000000000 +0100 @@ -692,7 +692,7 @@ my $old_child_handler = $SIG{'CHLD'}; $SIG{'CHLD'} = sub { &REAPER(); - if ($old_child_handler) + if ($old_child_handler && ref $old_child_handler eq 'CODE') { &$old_child_handler(); }
Hi Clint, On Sa. 25. Nov. 2006, 10:38:52, DRTECH wrote: Show quoted text
> Your latest patch for $SIG{CHLD} introduces a bug, because it assumes > that handlers are only code refs, while they can be set to DEFAULT or > IGNORE as well. > > I have attached a patch to check that it is a coderef before trying to > execute it.
Thanks for the patch. I have it included into 0.97 which I just have released. Could you please verify that it works for you ? bye... ...roland
Hi Rolan Thanks for that - it works fine for me. Clint