local in that place won't work because local's scope ends with the
block. So it didn't do anything -- you put it at the end of a block.
Assigning to $SIG will last thru the fork exit() at the end of the
routine.
Also, I'd switch REAPER to use reaper_specific rather than reaper_all.
Your child process is still in the parent group and can be caught by
the background poller as well as by a signal.
The -1 sounds like waitpid overwriting $? when finds no more kids to
reap. Did you localize $? in BOTH places?
The other possibility is that the parent reaps the kid by mistake; then
IPC::Run tries to reap it - but it's gone, so it gets the -1. Since it
doesn't expect someone else to have reaped it, the -1 is an error.
(Which is reasonable since Cron has prevented IPC from getting the exit
status.)
I think assigning to $SIG and switching to reaper_specific has a good
chance of solving your problem.
Roland may have other thoughts.
On Tue Jun 28 11:51:25 2011, DRTECH wrote:
Show quoted text> On Tue Jun 28 11:41:39 2011, tlhackque wrote:
> > In the forking case, there's no need to localize as the fork is
just
Show quoted text> > going to evaporate. Doing anyting with the signal is unnecessary.
>
> Yes - and I think it is this existing SIG{CHLD} handler from the
parent
Show quoted text> which is interfering with system calls in the child.
>
> > $SIG{CHLD}='DEFAULT';
>
> yeah, i should have done this. Instead, i tried with local $SIG{CHLD}
> in the same position.
>
> Even with this change and localizing the two extra vars, I was still
> getting similar errors, with IPC::Run::run() returning false (which
> indicates an error, unlike system()) and $? set to -1.
>
> Also, my DB connection disappears every now and again, and gives me
> "can't connect". NO idea what is going on there.
>
> That said, I've gone back to 0.99 again and all is running smoothly.
