Alceu Rodrigues de Freitas Junior <glasswal...@yahoo.com.br> writes: > Hi Slaven, > > Thanks for all the comments. I made myself some below: > > Em 21/01/2018 19:18, Slaven Rezic escreveu: >> Alceu Rodrigues de Freitas Junior via cpan-testers-discuss >> <cpan-testers-discuss@perl.org> writes: >>
[...] >> I guess that some of us indeed have watchdogs. A simple one is to setup >> a CPU limit (my smokers use one hour). If you're lucky and the >> misbehaving distribution has a busy endless loop, then the test will be >> automatically killed after an hour and a proper fail report is sent out. >> It's even quiet easy to recognize this, like in this report: >> http://www.cpantesters.org/cpan/report/3556e864-4490-11e7-a21f-d75903976bbd >> Typically, in such reports CPU usage is somewhat larger than 3600s, and >> exit code of one of the tests is 9 (SIGKILL). > > I'm wondering how you implemented that... for Linux there is ulimits > and cgroups, but I don't know how to do the same with OpenBSD. FreeBSD has the limits command, and maybe OpenBSD has it, too. A quick test on a FreeBSD 11 system with zsh: $ time limits -t 3 perl -e 'while () {}' [2] 99733 killed limits -t 3 perl -e 'while () {}' limits -t 3 perl -e 'while () {}' 3.96s user 0.01s system 99% cpu 4.006 total Another approach is to use BSD::Resource. > >> However, the just hanging ones without eating CPU need a real watchdog. >> I have an unpublished script which looks for inactivity on the tty. If >> there's no output for 200s, then the watchdog notices the process id and >> possible distribution name+version, but does not do anything. Only if >> the distribution is in a list of known problematic >> distributions+versions, then the watchdog actually kills the test >> script. This watchdog is not really ready for the public (data & code >> live in the same file, and there's only support for linux, freebsd, and >> windows), but if somebody is interested, I can share. > > If I may, I would suggest you to release it on Github as is and see > what comes around. I'll do minimal polishing of the script and will make it available. [...] > >>> 3. We don't have any simple way to contact the distribution author to >>> let him/her know their respective distribution is blocked for some >>> reason. >> >> This can go the normal way: write a bug report. I made a habbit to note >> the ticket number in the files I used for blocks or automatic kills. >> This way I can also see if a distribution is lacking a bug report --- >> sometimes the problems are many and time is sparse, and I don't write >> immediately for every noticed problem a bug report. > > Well, I guess time is not on my side in this one. > But it just occurred to me that the same test report could be created > and sent to the author in the case his/her distro was blocked for some > reason. That should give enough information for the author fix > anything on that matter. A special kind of NA or UNKNOWN report? [...] >>> For that, I reviewed the distroprefs specification (from the CPAN >>> module POD) and there aren't fields that I think would be required to >>> include into the YAML: >>> >>> * The OS name and version > > I meant to provide the information from where the distroprefs were > created, so it could help the distro author. The same thing that the > test reports already does, basically. This is not applicable for my setup --- I create distroprefs files typically after looking at a lot of reports from different operating systems and perl versions. [...] > > Regards, > > Alceu > Regards, Slaven -- Slaven Rezic - slaven <at> rezic <dot> de BBBike - route planner for cyclists in Berlin WWW version: http://www.bbbike.de Perl/Tk version for Unix and Windows: http://bbbike.sourceforge.net
