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 >