Hier sind ein paar Dinge, die Sie ausprobieren sollten, um Ihr Problem am besten zu lösen, im schlimmsten Fall, um herauszufinden, was es "nicht" ist. In einigen Fällen möchten Sie möglicherweise die Schritte kombinieren (z. B. strace und 'try with cleared environment').
Ulimit
Überprüfen Sie mit dem folgenden Befehl, ob ungewöhnlich niedrige Grenzwerte für die Anzahl der zulässigen Prozesse in Ihrer Shell oder Pipeline festgelegt sind: ulimit -a
Wenn Sie können, hängen Sie die Ausgabe dieses Befehls an Ihre Frage an.
Protokollierung
Bei älteren Versionen von Bash konnten Pipelines aufgrund von aktivierten Protokollierungsfunktionen brechen (Bash <4.1).
type log
Das sollte etwas wie 'log: not found' zurückgeben. Wenn stattdessen eine Funktionsdefinition zurückgegeben wird, löschen Sie sie mit dem Befehl unset log.
Debug-Falle
trap -p
Prüfen Sie, ob Traps ausgegeben werden, die mit DEBUG oder der Protokollierung verknüpft sind. Wenn sie definiert sind und / oder eine Protokollfunktion definiert ist, müssen Sie herausfinden, wo sie definiert sind, und sie (zumindest vorübergehend) entfernen.
Sie können in .bashrc, .bash_profile und anderen zugehörigen Initialisierungsdateien definiert werden. Da es sich scheinbar auch auf root auswirkt, wird es wahrscheinlich in einer Datei auf Systemebene wie / etc / bashrc oder / etc / profile gefunden .
Zumindest können Sie die Trap- und Log-Funktion aus Ihrer aktuellen Umgebung löschen und sehen, ob das Problem dadurch gelöst wird.
Versuchen Sie es mit einer gelöschten Umgebung
Eine andere Methode, um dies zu überprüfen, ist die Ausführung der übergebenen Befehle mit (fix).
env -i ls | env -i grep a | env -i grep b | env -i grep c | env -i grep d
um die Umgebung (für diese Befehlsfolge) zu löschen. Möglicherweise müssen Sie Ihre Befehle so ändern, dass sie vollständige Pfade enthalten. Es lohnt sich zu sehen, ob die Werte ulimit -ain dieser Umgebung auch anders sind.
Bash-Debug-Ausgabe
Bevor Sie Ihre gepipste cmd-Sequenz ausführen, geben Sie set -xin die Befehlszeile ein. Dadurch wird das Bash-Debugging aktiviert. Alle Befehle hinter den Kulissen werden auf dem Bildschirm gedruckt. Es ist möglich, dass Sie etwas Ungewöhnliches sehen - ein Haken an einer anderen Funktion, die ähnlich wie das oben diskutierte Protokollproblem genannt wird - oder eine andere Ungewöhnlichkeit.
Strace
Führen Sie den Befehl mit strace aus:
strace ls | grep a | grep b | grep c | grep d
und sehen was genau los ist. Wenn Sie diese Ergebnisse veröffentlichen möchten, müssen Sie sie wahrscheinlich auf Pastebin oder einer ähnlichen Website veröffentlichen und einen Link posten. Dies ist der wahrscheinlichste Ansatz, um das Problem zu lösen, die Ausgabe kann jedoch schwierig zu decodieren sein.
Aktualisieren
Nachdem Sie Ihre Protokolle überprüft haben:
Bei der Verwendung von env -i muss jede Stufe der Pipe verwendet werden - jede Stufe ist tatsächlich eine separate Shell-Instanz. Mein Fehler.
env -i ls | env -i grep a | env -i grep b | env -i grep c | env -i grep dDie Protokollierungsfunktion, die zwischen jedem Aufruf und dem DEBUG-Trap aufgerufen wird, ist fast definitiv der Fehler, auf den ich mich bezogen habe. Leider kann der Fehler auch mit meinem RHEL-Abonnement nicht angezeigt werden. Es ist https://bugzilla.redhat.com/show_bug.cgi?id=720464
Dieser Fehler führte zu einer Wettlaufsituation, als die Protokollierung in Verbindung mit Debug-Traps auftrat. Genau das, was Sie gerade gemacht haben - das set -x zeigt deutlich die ziemlich umfangreiche Protokollierung (in syslog) jedes Befehls, der ausgegeben wird.
Da eine Pipe Sub-Shells erstellt, können Sie sie nicht einfach in der Shell der obersten Ebene löschen und Pipe-Befehle ausgeben. In der nächsten Pipeline-Stufe wird es definiert. Das erneute Testen mit der Änderung in Punkt 1 oben zeigt, dass es ohne diese Haken funktioniert.
Der Fehlerbericht zeigt keinen Rückport des Fixes an. Ich habe hier einige Details von Rhel eingefügt: http://pastebin.com/dymenY7e
Sie müssen den Trap löschen und / oder die Definition der Protokollierungsfunktion history_to_syslog entfernen. Wenn Sie über Root-Zugriff verfügen, können Sie diese definitiv entfernen. Ich habe in meiner ursprünglichen Antwort einige Tipps gegeben, wo ich suchen muss.
Sie könnten versuchen, nach einem Update für basos 5 für centos 5 zu suchen, aber die Informationen, die ich oben verlinkt habe, besagen, dass kein rückseitiger Port für rhel 5 erstellt wurde. Es ist also unwahrscheinlich, dass man für centos 5 war.
Kurzes Update:
Um die Verbindung zwischen dem Fehler und dem Fehlermodus ein wenig zu verdeutlichen, werden Aufrufe zur Interaktion mit Prozess-IDs, die der Protokollierungsfunktion und dem DEBUG-Hook zugeordnet sind, außerhalb der Reihenfolge - der Race-Bedingung - ausgeführt, was zu Aufrufen wie beispielsweise getppid führt, die auf Referenzprozesse verweisen die gerade geschlossen wurden, was zu dem Fehler führt, den Sie sehen.
Nebenbei bemerkt ist dies eine aggressive Protokollierungsfunktion. Der Sysadmin glaubt eindeutig nicht an den Vertrauenskreis.