Bash generiert ständig Kindprozesse und kann nicht gestoppt werden. Was ist los?

Bash generiert ständig Kindprozesse und kann nicht gestoppt werden. Was ist los?

In Kubuntu 20.04 oder KNOPPIX 9.1, in KDE unter Konsole viele Fenster und in jeder Bash-Version 5.2.15(1)-Release (i686-pc-linux-gnu).

Das in dieser Frage beschriebene Problem ist bei mir in den letzten Wochen häufig aufgetreten (aber noch nie zuvor).

Die Ursache liegt immer in einer falschen Befehlszeile in einem Quellskript oder einer Eingabe nach der Shell-Eingabeaufforderung.

Manchmal (heute nicht) verzweigt Bash endlos neue Prozesse.

Heute kann ich die falsche Befehlszeile melden, die die Ursache ist. Es geht nicht wörtlich um das, was ich eingegeben habe, sondern um das, was PS anzeigt:

ps -Flwwc -t pts/14

ps zeigt in der Spalte "CMD":

sed -r eval s=(.*)=\1; ZZZZZZZZZ;=p /root/.bash_history

Bitte beachten Sie, dass dieser falsche Befehl nicht Gegenstand meiner Frage ist (ich weiß, was ich versuche und was die nächsten Schritte sind).

Es geht darum, was der Crazy Bash macht und was die Hilfe ist.

bash zeigt diese beiden Zeilen in einer endlosen Folge:

sh -c: line 1: syntax error near unexpected token `('

sh -c: line 1: `val s=(.*)=1; ZZZZZZZZZ;=p'

In der Bash eines anderen Terminals führe ich aus

ps -Flwwc --sort=start_time -t pts/14

und ich sehe, dass zwei untergeordnete Prozesse aktiv sind:

  1. sed(wie oben gezeigt)
  2. less

Die PPID von beiden ist die defekte Bash.

Im kaputten Bash gibt es keine Mittel. ZB

Das Eintippen Returnbringt less mit seinem Inhalt. Schließe less, bin ich im Bash-Prompt, als wäre alles ok. Und im anderen Terminal ps -Flwwc ...wird angezeigt, als wäre alles ok: die beiden Kindprozesse sind verschwunden, der unterste Prozess ist die kaputte Bash.

Nun zurück zur kaputten Bash: Wenn ich Returnoder Ctrl- eingebe C, erhalte ich die Endlosfolge der beiden Zeilen und im anderen Terminal ps -Flwwc ...werden wieder die beiden Kindprozesse angezeigt.

Auch wenn von einem anderen Endgerät in einer While-Schleife via writevtI-Telegramme gesendet wird Ctrl- Cusw. in möglichst kurzer Abfolge - hilft das nichts.

Es gibt keine Möglichkeit, diese verrückte Sause auf normale Weise zu stoppen.

Der einzige Weg, den ich kenne, ist, die kaputte Bash zu beenden. Dadurch geht aber der Bash-Verlauf verloren.

(für andere Anwendungen verwende ich bash PROMPT_COMMAND ..., um zu erstellen history -a, aber darum geht es hier nicht).

Kennt jemand den Grund für dieses Verhalten von Bash und weiß, wie man dieses neue Verhalten verhindern kann?

Antwort1

Erklärung und Lösung gefunden:

In letzter Zeit experimentiere ich mit verschiedenen Arten von PROMPT_COMMAND, um diese zusätzlich in die History-Datei /dev/pts/nnzu schreiben.

Der falsche Code war Bestandteil des PROMPT_COMMAMD im Test.

Nach dem Beenden der untergeordneten Prozesse scheint also alles normal zu sein, und tatsächlich war alles normal.

Als ich dann in der kaputten Bash etwas eingegeben habe, was einen neuen Prompt verursachte, wurde innerhalb des PROMPT_COMMAND der falsche Code ausgeführt. Und dadurch wurden die Kindprozesse erneut erstellt usw.

Die Lösung besteht darin, der defekten Bash den Befehl zu geben

unset PROMPT_COMMAND

Dann hört der „Wahnsinn“ von Bash auf.

Ich könnte meine Frage also löschen. Mache ich aber nicht, denn manche Punkte sind es wert, von anderen gelesen zu werden, insbesondere ein Punkt sollte öffentlich bleiben:

Es ist wichtig, in Linux den Befehl zu haben writevt. Er sollte neu erfunden werden, um ein normaler Befehl jeder Linux-Distribution zu werden.

verwandte Informationen