Subprozesse in Perl Einheit Forking testet Anschläge beweisen; Test :: Harness Verlassen

Question

Ich habe versucht, den Perl-Dienstprogramm / Modul „beweisen“ als Testumgebung für einige Unit-Tests zu verwenden. Die Unit-Tests sind ein wenig mehr „System“ als „Einheit“, wie ich einige Hintergrundprozesse im Rahmen des Tests abzweigen muß, mit dem folgenden ...

sub SpinupMonitor{
   my $base_dir = shift;
   my $config = shift;

   my $pid = fork();
   if($pid){
      return $pid;
   }else{
      my $cmd = "$base_dir\/..\/bin\/monitor_real.pl -config $config -test";
      close STDOUT;

      exec ($cmd) or die "cannot exec test code [$cmd]\n";
   }
}

sub KillMonitor{

   my $pid = shift;

   print "Killing monitor [$pid]\n";
   kill(1,$pid);
}

Doch aus irgendeinem Grund, wenn ich meine .t Datei Spin haben einige zusätzliche Prozesse bis sie den Test Baum verursacht am Ende der ersten .t Datei, nachdem alle Tests abgeschlossen haben, eher zu hängen als auf die nächste Datei los oder verlasse, wenn man nur.

Zuerst fragte ich mich, ob es sein könnte, weil ich meinen Teilprozess wurde getötet und lasse sich nicht mehr. So habe ich ..

$SIG{CHLD} = \&REAPER;
sub REAPER {
   my $pid = wait;
   $SIG{CHLD} = \&REAPER;
}

Um den Code. Aber das hilft nicht. In der Tat auf geschlossene Prüfung stellt sich heraus, dass meine Perl-Testdatei verlassen hat und ist heute ein nicht mehr existierenden Prozess, und es ist das Wrapper-Skript beweisen, dass ihre Kinder nicht geerntet hat. In der Tat, wenn ich hinzugefügt, um eine des () Aufruf am Ende meines Testskript Ich habe ...

# Looks like your test died just after 7.

Also mein Skript verlassen, aber aus irgendeinem Grund das Gurtzeug entwirrt nicht.

Ich habe bestätigt, dass es auf jeden Fall Prozesse Unter meinen ist, das Stauchen ist es, wie wenn ich sie deaktiviert, während die Tests das Gurtzeug verließ ordnungsgemäß fehlgeschlagen.

Gibt es etwas, das ich mit der Art und Weise falsch mache ich meine Prozesse bin Inbetriebnahme, die den Gurt in irgendeiner Weise stören könnten?

Danke

Peter

Answer 1

Ich gehe davon aus, dass alle Ihre Kinder verlassen haben, bevor Sie Ihren Test verlassen? Denn sonst kann es zu STDERR hängen auf, die beweisen, verwirren kann. Wenn Sie STDERR schließen könnte, oder zumindest auf ein Rohr in der Eltern-Prozess umleiten, dass ein Problem sein kann, Sie haben.

Abgesehen davon, würde ich auch darauf hinweisen, dass Sie brauchen, um Schrägstriche nicht zu entkommen nach vorn, und wenn Sie nicht Shell-Metazeichen verwenden (Leerzeichen sind nicht Metazeichen Perl - denken „*?{}()“), sollten Sie explizit sein und erstellen Sie eine Liste:

use File::Spec;
my @cmd = File::Spec->catfile($basedir,
                              File::Spec->updir(),
                              qw(bin monitor_real.pl)
                             ),
          -config => $config,
          -test   =>;

close STDOUT;
close STDERR;

exec (@cmd) or die "cannot exec test code [@cmd]\n";

Answer 2

Beachten Sie, dass Sie nicht testen, ob fork() fehlgeschlagen. Sie müssen sicherstellen, dass $pid definiert machen bevor man davon ausgeht, dass „false“ bedeutet „Kind. "

Da Ihr $cmd Schale enthält Meta-Zeichen (Leerzeichen), Perl ist eigentlich eine Shell, wenn Sie exec() nennen. Während Ihr Monitor ausgeführt wird, gibt es (1) Perl, (2) ein Kind sh -c, und (3) ein Enkel Perl läuft monitor_real.pl. Was das bedeutet insbesondere, wenn Sie KillMonitor nennen, sind Sie nur die Hülle zu töten (denn das ist die PID ist Sie haben) und den Monitor nicht.

Sie auch interessieren könnten: Wie kann ich einen Dämon-Prozess blechen? aus dem Perl-FAQ.