[gelöst] Unerwünschte, remanente Prozesse mit gnuplot_qt

[TuxPeter]

Hallo Debianfreunde,

bei der Arbeit mit gnuplot - tolles Programm - fiel mir auf, dass der PC auf einmal deutlich langsamer und zäher zu laufen schien. Ich entdeckte eine große Menge von Prozessen, alle schlafend, alle mit dem Namen gnuplot_qt.

Diese Prozesse "überstanden" sowohl eine Ab- und Anmeldung des Users sowie einen Neustart des Computers, was ja eigentlich gar nicht sein kann. Es gibt aber jeweils neue PIDs, die Dinger werden also neu generiert.

Weg bekommt man die Zombies leicht, mit "kill `ps -C gnuplot_qt -o pid=`" sogar alle auf einmal, das ist bei mir jetzt schon über die history schnell greifbar, also kein wirklich dringender Lösungsbedarf. Aber schon ein gewisses Interesse daran, was da eigentlich los sein könnte.

So sieht das beispielsweise nach einer einzigen gnuplot-Session aus:

~$ ps -lC gnuplot_qt
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
0 S 1000 2078 2049 0 80 0 - 168979 SyS_po tty1 00:00:00 gnuplot_qt
0 S 1000 2079 2049 0 80 0 - 168982 SyS_po tty1 00:00:00 gnuplot_qt
0 S 1000 2080 2049 0 80 0 - 168980 SyS_po tty1 00:00:00 gnuplot_qt
0 S 1000 2081 2049 0 80 0 - 168979 SyS_po tty1 00:00:00 gnuplot_qt
0 S 1000 2082 2049 0 80 0 - 168980 SyS_po tty1 00:00:00 gnuplot_qt
0 S 1000 2083 2049 0 80 0 - 168979 SyS_po tty1 00:00:00 gnuplot_qt

Diese PIDs kommen von einem einzigen Lauf, sonst gibt es auch noch verschiedene PPIDS.

Ich kann das inzwischen auch rekonstruieren: In dem Xterm, in dem gnuplot läuft versehentlich ^S gegeben, und schon steht die Geschichte, und das Terminal blockiert und reagiert nicht mehr auf Tastendrücke. Getestet mit Xfce-Terminal und uXterm. Es wartet vermutlich auf einen Dateinamen zum Abspeichern, aber der kann nirgends eingegeben werden.
Deshalb neues Xterm oder neuer Tab geöffnet, weiter machen. Allerdings bleibt der alte Prozess am Leben, das Plot-Fenster bleibt auch geöffnet, ebenfalls unbedienbar geworden. (es ist also nicht gnuplot selber, das sich aufhängt, sondern eher das Terminal-Fenster. Man kann die Fenster dann alle noch mit der Maus schließen, und alles sieht prima aus - bis auf die im Hintergrund sich anhäufenden Prozesse.

Ich habe versucht, das Verhalten mit einem anderen interaktiven Terminal-Prog - mit "bc" - zu rekonstruieren. Das Xterm bleibt genauso bei ^S stehen, aber es bleiben keine Prozesse übrig, die gekillt werden müssen.

Ich habe des Weiteren die Markierung beim Abmelde-Dialog von Xfce4 "Sitzung für weitere Anmeldungen speichern" entfernt. Ohne Einfluss.

Es würde mich schon interessieren, was da eigentlich schief läuft.

[smutbert]

Eventuell ist wirklich das Speichern der Sitzung von Xfce schuld ("letzte Sitzung speichern" oder so) - das versucht sich zu merken welche Programme beim Abmelden gelaufen sind und startet sie beim nächsten Anmelden wieder.
Ich weiß nur nicht mehr wo man das Einstellen kann - gibt es den Haken im Abmelde-/Herunterfahrdialog?

Dagegen würde ich die Prozesse killen, mich dann noch einmal mit Speichern der Sitzung abmelden, nach dem nächsten Anmelden schauen ob die Maßnahme erfolgreich war und wenn ja, von da an die Sitzung nicht mehr speichern.

Prozesse die mit gleichbleibender PID das Ab- und wieder Anmelden überleben können dagegen auch einfach tatsächlich weitergelaufen sein. systemd erlaubt es Prozessen weiterzulaufen, unterbinden kann man das mit

Code: Alles auswählen

KillUserProcesses=yes

in »/etc/systemd/logind.conf«

[MSfree]

Diese Prozesse "überstanden" sowohl eine Ab- und Anmeldung des Users sowie einen Neustart des Computers, was ja eigentlich gar nicht sein kann.

KDE und andere Desktopumgebungen merken sich beim Abmelden und/oder Runterfahren die laufenden Programme und deren Fensterpositionen und -größe und starten sie beim Anmelden erneut. Die gemerkten Informationen werden in einem Ordner im ~-Verzeichnis abgelegt und überleben so auch Neustarts.

In dem Xterm, in dem gnuplot läuft versehentlich ^S gegeben, und schon steht die Geschichte, und das Terminal blockiert und reagiert nicht mehr auf Tastendrücke.

Das ist in der Tat Absicht. Ctrl-S stoppt die Ausgabe auf Standard-Out. Mit Ctlr-Q kann man die Verarbeitung fortsetzen.

[TuxPeter]

Danke für Eure schnellen Antworten!
@Smubert: Also, die Markierung beim Abmelde-Dialog von Xfce4 "Sitzung für weitere Anmeldungen speichern" entfernt. hatte ich schon entfernt und vorher alle entsprechenden PIDs gekillt, das Verhalten blieb aber gleich, auch bei zu Testzwecken extra erzeugten Zombies in weiteren Test-Durchgängen.

Das mit dem

KillUserProcesses=yes

werde ich noch ausprobieren

@MSfree: Dass mir das Paar Ctrl-S Ctrl-Q nicht eingefallen ist - das gab es doch schon zur DOS-Zeit! - ist jedenfalls eine gute Hilfe, einfach weiterzumachen. (Da ich meine Plotbefehle in einem Editorfenster entwickle und dann dort erst mal mit ^S speichere, bevor ich sie im gnuplot-Fenster starte, werde ich den Fehler, im Eifer gerade im falschen Fenster zu sein, auch zukünftig wohl kaum vermeiden können.

[smutbert]

Das Problem ist (wahrscheinlich) das letzte Abmelden mit noch aktiviertem Speichern der Sitzung: die gnuplot-Leichen dieser Sitzung bleiben gespeichert und werden immer wieder gestartet solange du dich nicht noch einmal mit aktiviertem Speichern abmeldest (und vorher die gnuplot-Leichen killst).

[TuxPeter]

Das Problem ist (wahrscheinlich) das letzte Abmelden ...

Das wird es sein. Habe jetzt systematisch den ganzen Vorgang ein paar mal in verschiedenen Varianten durchgespielt, etwas verwirrend, das Ganze.

Sicher erscheint mir jedenfalls, dass es mit dem ^-S nichts zu tun hat, das sorgt nur für einen verwaisten Prozess, nämlich das Gnuplot-Fenster. Und dem Mechanismus, mit Nicht-mehr-speichern der Sitzung, den man erst mal speichern muss, damit er nicht mehr speichert, bin ich wohl, obwohl mir grundsätzlich bekannt, mal wieder mal auf den Leim gegangen.

Und Dank für Eure Tipps zu dem Problemchen!

TuxPeter