Ich habe einen Code, wo ich einen Befehl auf einem entfernten Linux-Rechner ausführe und die Ausgabe mit Paramiko lese. Der Code-Def sieht so aus:
%Vor%Der obige Code funktioniert für kleine Ausgaben, aber er bleibt für größere Ausgaben hängen.
Gibt es hier ein pufferbezogenes Problem?
Ich sehe kein Problem mit dem Stdout-Kanal, aber ich bin mir nicht sicher, wie Sie stderr handhaben. Kannst du bestätigen, es ist nicht die Stderr Capture das Problem verursacht? Ich werde Ihren Code ausprobieren und Sie wissen lassen.
Aktualisierung:
Wenn ein Befehl, den Sie ausführen, viele Meldungen in STDERR enthält, bleibt Ihr Code stehen. Ich bin mir nicht sicher warum, aber recv_stderr(600) könnte der Grund sein.
So erfassen Sie den Fehlerstrom auf die gleiche Weise, wie Sie die Standardausgabe erfassen.
etwas wie,
Sie können sogar versuchen, recv_stderr(600) in recv_stderr(1024) oder höher zu ändern.
Eigentlich glaube ich, dass alle obigen Antworten das eigentliche Problem nicht lösen können:
Wenn das Remote-Programm eine große Menge stderr output first erzeugt, dann
%Vor%würde für immer hängen. obwohl
%Vor%würde diesen Fall auflösen, aber es wird fehlschlagen, falls das Remote-Programm eine große Menge von stdout output first erzeugt.
Ich habe noch keine Lösung ...
Es ist einfacher, wenn Sie die High-Level-Repräsentation einer offenen SSH-Sitzung verwenden. Da Sie bereits Ihren ssh-client zum Öffnen Ihres Kanals verwenden, können Sie einfach Ihren Befehl ausführen von dort, und vermeide die zusätzliche Arbeit.
%Vor%Sie müssen zurückkommen und von diesen Dateien wieder lesen, wenn Sie danach noch weitere Daten erhalten.