Alexandre Duret-Lutz <adl@lrde.epita.fr> writes:
On Sat, Oct 9, 2010 at 12:15 AM, Alexandre Duret-Lutz <adl@lrde.epita.fr> wrote:
Je me suis permis de tuer ce processus, qui ralentissait Dallas depuis 2 mois.
build 26182 97.9 0.1 8508 5456 ? R Aug13 79267:52 /usr/bin/swig -Wall -c++ -python -I../../milena -MD -MF .deps/point2d-wrap.Tcc -o point2d-wrap.cc ../../swilena/point2d.i
Bande de malpropres.
Je viens de tuer tout ça aujourd'hui. C'est pénible : Dallas est sur les genoux.
build 1095 0.0 0.0 2556 1024 ? S Nov02 0:00 /bin/sh -c if /usr/bin/swig -Wall -c++ -python -I/work/buildfarm/oln/oln_linux_gcc4_2/build/milena -MD -MF ".deps/point2d-wrap.Tcc" -o point2d-wrap.cc ../point2d.i; then \? mv -f ".deps/point2d-wrap.Tcc" ".deps/point2d-wrap.Pcc";\?else \? rm -f ".deps/point2d-wrap.Tcc"; exit 1;\?fi
[...] Désolé pour cette gêne. On vient de regarder avec Guillaume, ces processus correspondent à des builds interrompus (manuellement, depuis le site Web). Je ne sais pas qui est fautif (BuildBot ou SWIG), ni pourquoi. Peut-être que BuildBot n'envoie que SIGTERM aux processus du build, et que swig l'ignore... À l'avenir, nous essaierons de vérifier que les build slaves s'arrêtent complètement après une interruption manuelle.