The powershell zombie killer is not a great generic solution though for
automated killing.  Since looking at the hanging test on
AZAWAWI/Farabi-0.47.tar.gz we'd need to look for:
"C:\strawberry\perl\bin\perl.exe" t/01-basic.t
which is generic enough that a background watch and kill script would find
t/01-basic.t is often used.
If there was a way to also filter by the module we are testing; that would
make it a bit better....but I don't see the Farabi string anywhere in the
command line arguments of any of the parent perl processes doing the work.
(though if we start a sort of watchdog module in the CPAN::Reporter the
currently tested module could easily be used...or maybe there's a way to
get it already)

I understand the want to not skip and leave a hanging test... it needs to
be fixed (though if no one is debugging it; a falling tree makes no sound
with no one around).  But when enough smokers hang camels, there should be
a way to as a community document the module as having hanging tests, update
the code with skips, and maintain a list of skips.  There isn't really a
list of tests that were turned into skips and still are..or were and now
fixed; so just updating the test to skip is great, though then people
forget what has been skipped and why...

So, yes, I am still very interested in other people's thoughts on how to go
about automating the remediation of hanging camels and documenting
problematic modules&tests across platforms.
I will mention that Farabi works great on my mac and is nice work!

What about CPAN::Reporter::WatchDog or something else?

cheers,
--dave
https://dave.thehorners.com/tech-talk/programming/510-perl-cpan-packaging-notes



On Thu, Aug 7, 2014 at 8:57 AM, David Cantrell <da...@cantrell.org.uk>
wrote:

> On Thu, Aug 07, 2014 at 08:29:41AM -0400, Dave Horner wrote:
>
> > it seems to happen more on windows than other platforms...
>
> Unfortunately I know exactly --><-- that much about Windows so can't
> help with that - although I'm sure you could write a watchdog thingy in
> perl if you don't have a decent shell available.
>
> > I haven't gone so far as to schedule it to run in the background looking
> > for problematic on my smokers, but i may in the future.
>
> I suppose you'd be better off forking twice. Fork once from whatever
> script controls your smoker *and wait for the child to terminate*. Then
> in the child, fork off a grandchild to watch the child and kill it if
> necessary. Of course, the child should, as the last thing it does before
> exiting normally, kill the grandchild.
>
> > I suppose an automatic timeout that is set high enough takes care of many
> > issues; but a test could be long running.
>
> An hour or so should do the trick. I can't think of anything off the top
> of my head that takes that long to test, even if you include the time it
> takes to fetch and test all its dependencies. And hardly anything needs
> the timeout, so waiting that long shouldn't be a problem.
>
> --
> David Cantrell | Pope | First Church of the Symmetrical Internet
>
>     Fashion label: n: a liferaft for personalities
>     which lack intrinsic buoyancy
>

Reply via email to