[gelöst] PID-Wert nicht nachvollziehbar

[TomL]

Moin @ all

Ein etwas umfangreicheres Script enthält diese folgende Code-Passage. Das Script erfüllt eine bestimmte Aufgabe und um den Job verfolgen zu können wird hier sowas wie ein Trace-Fenster geöffnet, um Live die Aktionen über den Umweg von aktuellen Log-Einträgen verfolgen zu können.

Code: Alles auswählen

$TerminalApp -geometry 120x20+1+1 -e "tail $Log -n 100 --sleep-interval=2 -f --pid=$$" &
LogPID=$(ps -x | grep $TerminalApp | grep "tail $Log" | awk -F ' ' '{ print $1 }')

Tu dies und tu das
und schreib alles wichtige ins log
und am ende tu aufräumen

if [[ $LogPID -gt 0 ]]; then
    if kill -0 $LogPID 2>1 >/dev/null; then
        kill -SIGTERM $LogPID
    fi
    LogPID=0
fi

Im ersten Versuch hatte ich natürlich probiert, mit $! den letzten gestarteten Hintergrundjob zu erhalten, ich hatte hier die PID für die gestartete TerminalApp erwartet. Aber der Rückgabewert war alles mögliche, aber niemals das neue Fenster, bis hin zu der Feststellung, dass überhaupt kein Prozess dieser PID entsprach. Gelöst habe ich das Problem dann über diesen mir sehr umständlich erscheinenden Würgerund, der imho sogar noch 'weniger' ist, als ein Workaround. Soll heissen, es funktioniert, aber so richtig wohl fühl ich mich damit nicht. Weiss jemand, warum $! nicht funktioniert und wie stattdessen eine bessere Lösung aussehen könnte? Wobei ich natürlich nur sicher sein will, nicht einen falschen Prozess zu entfernen.

[smutbert]

Was ist denn $TerminalApp

[Tintom]

Ich kann das Verhalten hiermit reproduzieren:
#!/bin/bash
gnome-terminal -e "cat /dev/zero > /dev/null &" &
echo $!
Mit strace kann ich auch sehen, dass die Funktion clone() sich der PID annimmt und der Prozess anschließend beendet wird. Aber warum?

[TomL]

Was ist denn $TerminalApp

In diesem besonderen Fall 'xterm'. Könnte aber auch 'urxvt' oder 'lxterminal' o.ä. sein... wobei das Statement dann jeweils bezgl. der Parameter angepasst wird. Das Script öffnet damit ein weiteres neues Fenster, um darin die Ausgaben zur erzeugen.

[smutbert]

Bei xterm versteh ich es nicht, aber wegen dem was Tintom geschrieben hat, habe ich gefragt:

gnome-terminal hat da irgendwo so etwas ähnliches wie eine client-/server-Architektur. Der eigentliche Prozess ist /usr/lib/gnome-terminal/gnome-terminal-server, der nur einmal gestartet wird und zwar sogar von systemd

Code: Alles auswählen

$ systemctl --user status gnome-terminal-server.service
● gnome-terminal-server.service - GNOME Terminal Server
   Loaded: loaded (/usr/lib/systemd/user/gnome-terminal-server.service; static; vendor preset: enabl
   Active: active (running) since Fri 2019-10-25 10:43:16 CEST; 3h 38min ago
 Main PID: 1429 (gnome-terminal-)
   CGroup: /user.slice/user-1000.slice/user@1000.service/gnome-terminal-server.service
           ├─1429 /usr/lib/gnome-terminal/gnome-terminal-server
           ├─1434 zsh
           ├─3688 zsh
           ├─3701 systemctl --user status gnome-terminal-server.service
           └─3702 pager

Okt 25 10:43:16 iolaos systemd[968]: Starting GNOME Terminal Server...
Okt 25 10:43:16 iolaos gnome-terminal-server[1429]: Display does not support owner-change; copy/past
Okt 25 10:43:16 iolaos systemd[968]: Started GNOME Terminal Server.

und gesteuert wird der dann eben von /usr/bin/gnome-terminal, das sich aber natürlich gleich wieder beendet.


Verlässlich funktionieren sollte es, wenn du die PID von tail nimmst oder die PID der Shell in der tail läuft, aber mir ist noch keine Idee gekommen woher du die bekommst, außer die PID in eine Datei zu schreiben.

[TomL]

Verlässlich funktionieren sollte es, wenn du die PID von tail nimmst oder die PID der Shell in der tail läuft, aber mir ist noch keine Idee gekommen woher du die bekommst, außer die PID in eine Datei zu schreiben.

Ich habe die PID vom Fenster ja (scheinbar) erfolgreich ermittelt... wenn ich das Fenster vom Script dann via SIGTERM schließe, ist tail natürlich auch weg. Allerdings habe ich die ganze Zeit so ein Gefühl von "Zufall", denn einfach aus der Prozess-Liste was rauszugreppen hat ja immer was von Zufall. Und das ist das was mich dabei stört. Die aktuelle Lösung unterstellt Einmaligkeit... aber eben dafür gibts leider keine Gewähr.

[Tintom]

Bei xterm versteh ich es nicht, aber wegen dem was Tintom geschrieben hat, habe ich gefragt:

Mit bash -c "cat /dev/zero > /dev/null &" & bekomme ich das gleiche Resultat. Der bash-Prozess beendet sich, aber cat läuft munter weiter.

[smutbert]

Ok, das passiert wegen des ersten &
Das habe ich zuerst übersehen und das hat TomL ja gar nicht drin.

Wegen der Einmaligkeit: Wenn das Skript ohnehin zu jeden Zeitpunkt nur einmal laufen soll und mehrere Instanzen sinnlos sind könntest du vielleicht wirklich so etwas in der Art machen

Code: Alles auswählen

PID_FILE=/run/user/$UID/meinSkript.pid
# falls es als root läuft eher /run/meinSkript.pid

$TerminalApp -geometry 120x20+1+1 -e "echo \$$ > $PID_FILE ; tail $Log -n 100 --sleep-interval=2 -f --pid=$$" &
LogPID=$(cat $PID_FILE)

# tu dies und jenes
# LogPID killen

rm $PID_FILE

Wenn mehrere Instanzen gleichzeitig laufen sollen, könntest du statt dem immer gleich benannten PID_FILE mit mktemp eine von Instanz zu Instanz unterschiedliche benannte temporäre Datei anlegen, in die du die PID schreibst.

[...]
Weiss jemand, warum $! nicht funktioniert und wie stattdessen eine bessere Lösung aussehen könnte? Wobei ich natürlich nur sicher sein will, nicht einen falschen Prozess zu entfernen.

Andere Ideen warum es nicht funktioniert gehen in die gleiche Richtung wie die von gnome-terminal. uxterm und lxterm sind einfach Shellskripte die ihrerseits xterm aufrufen. Ich habe xterm nicht installiert und kann nicht einfach nachsehen. aber es kann natürlich sein, dass hier die PID vom eigentlichen xterm eine andere ist als von dem Prozess der im Hintergrund gestartet wurde.

Ähnliches machen andere Terminals vielleicht aus anderen Gründen, wie man es beispielsweise von firefox kennt. Wenn bereits ein firefox-Prozess läuft dann öffnen weitere Aufrufe nur neue Fenster, Tabs,... des bereits laufenden Prozesses und der Prozess, den man eigentlich gestartet hat, ist schneller wieder weg als man schauen kann.

[mat6937]

Allerdings habe ich die ganze Zeit so ein Gefühl von "Zufall", denn einfach aus der Prozess-Liste was rauszugreppen hat ja immer was von Zufall.

Evtl. geht es auch ohne greppen. Z. B. mit pidof und ps:

Code: Alles auswählen

:~$ pidof tail && ps -o ppid= -p $(pidof tail) && ps -fp $(ps -o ppid= -p $(pidof tail))
4792
 4790
UID        PID  PPID  C STIME TTY          TIME CMD
xx        4790  2598  0 09:55 pts/5    00:00:00 xterm -e tail -f

[TomL]

Ich habe den kleinen Code-Block mal angepasst... und mit dem Ergebnis bin ich jetzt restlos überfordert...

Code: Alles auswählen

$TerminalApp -geometry 120x20+1+1 -e "echo $$ > $TempFileName; tail $Log -n 100 --sleep-interval=2 -f --pid=$$" &

LogPID=$(cat $TempFileName)
echo "1: $LogPID" >>$Log

LogPID=$(ps -x | grep $TerminalApp | grep "tail $Log" | awk -F ' ' '{ print $1 }')
echo "2: $LogPID" >>$Log

Die zwei Ergebnisse der PID-Abfragen ...stehen oben, mit bei den ersten Zeilen des Logs. Die zweite ist die richtige. Kapier ich nicht Das wiederholt sich bei mehreren Versuchen, die Ergebnisse sind immer unterschiedlich.
1: 6601
2: 6673

Nachtrag: Ich habs rausgefunden, was die 6601 ist.... das ist die PID des laufenden Prozesses, also der, der den beschriebenen Befehl ausführt. 6601 wird als das eigentliche Script vom Anwender via Desktop-Starter gestartet und dieses Script startet dann den genannten $TerminalApp-Befehl, der dann zu 6673 wird.

@mat6937
Besteht bei pidof nicht das gleiche Problem durch die Prozessnamen-Abfrage? Was ist, wenns einen weiteren Tail-Prozess gibt? Ich hatte damit auch schon gespielt, ebenso mit pgrep.... aber imho bleibt das Problem bestehen... das ist nicht exklusiv.

[smutbert]

[...]
Nachtrag: Ich habs rausgefunden, was die 6601 ist.... das ist die PID des laufenden Prozesses, also der, der den beschriebenen Befehl ausführt.

Ja, weil das $$ bereits beim Aufruf ersetzt wird. Deshalb habe ich es mit einem \ escaped, dann wird es von der Shell ersetzt, die du in der $TerminalApp startest,

[mat6937]

@mat6937
Besteht bei pidof nicht das gleiche Problem durch die Prozessnamen-Abfrage? Was ist, wenns einen weiteren Tail-Prozess gibt?

Der weitere/andere evtl. existierende tail-Prozess wird aber nicht als Parent-PID, die PID eines xterm-Prozesses haben. Ich denke damit ist Exklusivität schon vorhanden bzw. kann hergestellt werden.

[TomL]

Ja, weil das $$ bereits beim Aufruf ersetzt wird. Deshalb habe ich es mit einem \ escaped, dann wird es von der Shell ersetzt, die du in der $TerminalApp startest,

Ja, das hatte ich anfangs sogar 1:1 so übernommen und bin dann in die Interpretationsfalle getappt... denn mit und ohne escape waren in beiden Fällen die PIDs weiterhin unterschiedlich. Jetzt und nach Deinem Hinweis hat sich bei genaueren Hinsehen aber gezeigt, dass das mit \$$ zwar eine andere PID ist, aber die ist dennoch richtig . Mein Grep-Call hat die PID von tail ermittelt, \$$ ermittelt hingegen die zu tail gehörende bash-PID.

Schließe ich die tail-PID, wird automatisch auch der bash-prozess geschlossen, schließe ich den bash-prozess, ist tail natürlich auch weg. Ja, ich denke, das könnte die Lösung sein...

@mat6937
Ich muss gestehen, dass ich dieses kryptische Statement ohne es in Einzelteile zu zerlegen kaum verstehe. ich glaube, smutbert's Vorschlag ist da Wartungsfreundlicher .... falls ich da vielleicht erst in 2 Jahren wieder das nächste Mal draufgucken sollte....

Nachtrag:
Ich hab mir das kryptische Statement gerade mal vorgenommen... ich denke, dass das nicht klappen kann, weils auf das Schlüsselwort "tail" prüft. Habe ich 2 tails am Laufen, kann es nicht mehr feststellen, welche das gewünschte ist und liefert beide PIDs.

[mat6937]

Habe ich 2 tails am Laufen, kann es nicht mehr feststellen, welche das gewünschte ist und liefert beide PIDs.

Wenn beide tails via xterm gestartet werden, ist das richtig. Wenn immer nur ein tail mit xterm gestartet wird, dann kann man die schon unterscheiden. Z. B.:

Code: Alles auswählen

:~$ pidof tail && ps -o ppid= -p $(pidof tail) && ps -fp $(ps -o ppid= -p $(pidof tail))
3481 3458
 2606
 3479
UID        PID  PPID  C STIME TTY      STAT   TIME CMD
xx        2606  2550  0 08:40 pts/1    Ss     0:00 /bin/bash
xx        3479  2618  0 08:46 pts/3    S+     0:00 xterm -e tail -f

[TomL]

Das echo-Statement hats gelöst. Nach mehreren Tests läufts es jetzt genau so, wie ich es mir gedacht habe. Danke für Eure Unterstützung.