• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Prozess automatisch neu starten

goeba

Hacker
Hallo,

ich suche nach einer einfachen Möglichkeit, einen Prozess automatisch neu zu starten. Hintergrund ist, dass der Prozess leider gelegentlich abstürzt.

Der Prozess soll mit userrechten laufen und benötigt einen laufenden X-Server.

Ich habe daher einen Autostarter in /etc/xdg/autostart platziert.

Ich überlege nun, statt des eigentlichen Prozesses ein Skript wie dieses einzusetzen:
Code:
#!/bin/bash
(while true; do
	mein_prozess
done) &

Natürlich könnte man auch systemctl dafür verwenden, aber soweit ich das verstanden habe, ist das eher für systemweite Prozesse.

Mir ist klar, dass das keine schöne Lösung ist, aber ich sehe mich außerstande, das zugrundeliegende Problem zu beheben.
(wer es unbedingt wissen muss: Es geht um die Software veyon. Diese verwendet einen Prozess, veyon-service, der einen x11_vnc startet, also den aktuell verwendeten Desktop per vnc verbreitet. Dieser stürzt gelegentlich ab, der Fehler findet sich zuhauf auch im Internet, und es scheint nicht trivial zu sein, diesen zu beheben).

Ich möchte aber keinen kapitalen Bock schießen, wenn das eine dumme Lösung ist, sagt es mir bitte!
 

spoensche

Moderator
Teammitglied
systemd wird auch für User spezifische Prozesse verwendet bzw. kann diese auch verwalten.
goeba schrieb:
Ich überlege nun, statt des eigentlichen Prozesses ein Skript wie dieses einzusetzen:
Code:
#!/bin/bash
(while true; do
	mein_prozess
done) &

Wenn du das script so laufen lässt, dann wird bei jedem Schleifendurchlauf "mein_prozess" gestartet. Folglich hast du in kürzester Zeit hunderte bzw. tausende "mein_prozess" Prozesse gestartet und zwingst dein System über kurz oder lang damit in die Knie.

Anmerkung zum Code:

Wo haste den Code her? Das Script startet die while Schleife und verfrachtet sie in den Hintegrund und startet dann den Prozess, ohne vorher zu prüfen ob es bereits einen laufenden Prozess gibt. Grausam, grausam und an Grausamkeit nicht zu überbieten, um es "irgendwie" in einer höflichen Umgangsform zu sagen.

Tu dir selbst den Gefallen und verwende dieses Script blos nicht.

Du kannst mittels Cron z.B. zyklisch prüfen, ob der Prozess "mein_prozess" bereits gestartet ist. Ist dies der Fall dann exit 0. Wenn der Prozess nicht gestartet ist, dann startest du ihn. Hat auch den Vorteil, dass die CPU nicht dauerbeschäftigt ist, wie bei einer while true Schleife.

Beispiel für die Cron Variante:
Code:
#!/bin/bash

pid=$(pidof mein_prozess || -1)

if [ $pid -gt 0 ]; then 
    exit 0
else#
    mein_prozess &
    exit 0
fi
 

abgdf

Guru
spoensche schrieb:
Wenn du das script so laufen lässt, dann wird bei jedem Schleifendurchlauf "mein_prozess" gestartet. Folglich hast du in kürzester Zeit hunderte bzw. tausende "mein_prozess" Prozesse gestartet und zwingst dein System über kurz oder lang damit in die Knie.
In der Tat. Ich war neulich doch ein bißchen überrascht, wie schnell es z.B. in Python geht, in eine Funktion zu springen und wieder hinaus. Auf meinem, nicht aktuellen Rechner so bei 50.000 mal pro Sekunde.
In bash ist es deutlich langsamer, ein paar Sekunden für 1.000 Sprünge. Aber dennoch:
Code:
#!/bin/bash

raise_a() {
     # Taking an argument and raising it by one.
     # See "Example 24-5. Dereferencing a parameter passed to a function"
     # at http://tldp.org/LDP/abs/html/complexfunct.html
     y=\$"$1"
     x=`eval "expr \"$y\" "`
     let "x += 1"
     eval "$1=\"$x\""
}

a=0
echo $a
for (( i=0;i<1000;i++ ))
do
    raise_a a
done
echo $a
Man muß also ein bißchen aufpassen, was man in eine Schleife schreibt, das wird innerhalb von ein paar Sekunden zigtausendmal ausgeführt. ;)
 
OP
G

goeba

Hacker
Hallo,

vielen Dank für die Hinweise.

Es ist allerdings so, dass der Prozess (es steht kein "&" hinter dem Aufruf) nur einmal aufgerufen wird, der erneute Aufruf geschieht erst, wenn der Prozess beendet wurde (in diesem Fall also: abgestürzt ist).

Die übrigen Hinweise treffen sicherlich zu, deswegen habe ich ja gefragt, weil mir das unschön schien.

Ich habe zwischenzeitlich noch eine Programmoption gefunden, die die Stabilität verbessert, sodass das Programm nun nicht mehr ständig abstürzt. Ich werde das jetzt eine Weile prüfen, wenn es immer noch zu Abstürzen kommt, werde ich eine Eurer Lösungen umsetzen.

Vielen Dank!
 

spoensche

Moderator
Teammitglied
goeba schrieb:
Es ist allerdings so, dass der Prozess (es steht kein "&" hinter dem Aufruf) nur einmal aufgerufen wird, der erneute Aufruf geschieht erst, wenn der Prozess beendet wurde (in diesem Fall also: abgestürzt ist).

Mit dem "&" am Ende wird ein Prozess nach dem Start in den Hintergrund geschoben und ermöglicht das Terminal weiter zu verwenden. In dem Script wird die while Schleife und der Start des Prozesses gruppiert und mit "&" in den Hintergrund geschoben. Unsauber eben und einfach schlampig dahin gerotzt, ohne mal kurz drüber nachzudenken.

Unter Umständen blockiert es auch den Shutdown des Rechners, weil der Prozess ständig ohne irgendeine Abbruchbedingung immer neu gestartet wird.


goeba schrieb:
Ich habe zwischenzeitlich noch eine Programmoption gefunden, die die Stabilität verbessert, sodass das Programm nun nicht mehr ständig abstürzt. Ich werde das jetzt eine Weile prüfen, wenn es immer noch zu Abstürzen kommt, werde ich eine Eurer Lösungen umsetzen.

Unsere Tipps sind keine Lösungen, sondern Würgarounds. Eine Lösung wäre, den Prozess mit gdb starten um herauszufinden an welcher Stelle der Prozess abstürzt und warum er das macht, gefolgt von Bug im Quellcode beseitigen, neu kompilieren und das Ding vernünftig ans laufen zu bekommen. Ja das benötigt Zeit, Zeit die zu investieren ist, wenn man ein funktionierendes Programm haben will und der Allgemeinheit zur Verfügung stellt. Alles andere ist halbgar und hat was von M$ Manier, funktioniert nicht wirklich bis gar nicht, inkl. eigenleben und wird mit Lügen und Täuschung als voll Funktionsfähig angepriesen.
 

abgdf

Guru
spoensche schrieb:
Unsere Tipps sind keine Lösungen, sondern Würgarounds. Eine Lösung wäre, den Prozess mit gdb starten um herauszufinden an welcher Stelle der Prozess abstürzt und warum er das macht, gefolgt von Bug im Quellcode beseitigen, neu kompilieren und das Ding vernünftig ans laufen zu bekommen.
:D Ja, sehr schön. Dafür muß man das Programm zunächst mit Debuginformationen neu kompilieren, so daß der Source-Code mit in die ausführbare Datei geschrieben wird.
Dann sollte man ein grafisches Frontend für gdb verwenden.
Und dann kommt Kernighans Problem: "Debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"
Aber im Prinzip bleibt das natürlich der richtige Weg.
 

spoensche

Moderator
Teammitglied
abgdf schrieb:
:D Ja, sehr schön. Dafür muß man das Programm zunächst mit Debuginformationen neu kompilieren, so daß der Source-Code mit in die ausführbare Datei geschrieben wird.

:schockiert: Das kann ja fast jeder. :)
In der Regel liefert der Debugger die aufgerufene Funktion und alle folgende Frames sind also in der Funktion. Die Debug- Symbols brauchst du nicht zwingend bei jedem Fehler. Wenn es ein Memleak ist, dann lässt man Valgrind drauf los und bekommt auch ohne Debug-Symbols genug Infos.

abgdf schrieb:
Dann sollte man ein grafisches Frontend für gdb verwenden.

Debuggen, ich habe nicht von Pixel schubsen gesprochen. ;) :)

abgdf schrieb:
Und dann kommt Kernighans Problem: "Debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"

Das ist sein Problem und kann er gerne behalten. Das heisst ja nicht, dass es bei jedem so ist. :)
 
OP
G

goeba

Hacker
Ich kann Programme debuggen, das ist nicht das Problem (insbesondere, da es sich um ein c++-Programm handelt, womit ich mich viel besser auskenne als mit Shellprogrammierung (was nicht meine Domäne ist, wie man sicher in diesem Faden gemerkt hat)).

Nur: Wenn ich das bei jedem Programm machen würde, das mal abstürzt, dann käme ich zu sonst nichts mehr.

In diesem Fall hatte ich einen ganz konkreten Anlass, das nicht tun zu wollen.

Die Software heißt "veyon", ein Programm, das vorrangig für den Einsatz im Klassenzimmer gedacht ist. Auf jedem Schülerrechner wird ein VNC-Server gestartet. Am Lehrerrechner läuft ein VNC Client, der dann alle Schülerrechner in einer Übersicht anzeigt und auch einzelne Rechner auf Wunsch im Vollbild.

veyon verwendet x11vnc (ist als Dependency mit im Source tree). Ich hatte, um diesem Absturz auf die Spur zu kommen (und auch, um zu prüfen, ob andere VNC-Lösungen stabiler laufen), verschiedene VNC Server ausprobiert, und alle (!) stürzten auf meinem Testsystem gelegentlich ab. Im Internet findet man dazu tausende Beiträge. Offenbar funktionieren viele VNC Server schlecht im Zusammenhang mit KDE.

Und ja, natürlich hatte ich den Kompositor ausgeschaltet.

Da dieses Problem also sehr häufig auftritt, auch mit verschiedenen VNC Lösungen, hielt ich es für sehr sehr unwahrscheinlich, dass ausgerechnet ich, der im Bereich VNC ein reiner Anwender ist und von dem Protokoll keine Ahnung hat, dieses Problem einfach so lösen kann. Deshalb hatte ich nach einem Workaround gesucht (und auch gefunden, wie gesagt, xdamage deaktivieren, und es stürzt nur noch sehr selten ab).

Davon abgesehen war ich aber davon ausgegangen, dass es so etwas wie eine "Prozessüberwachung" geben müsste, die dafür sorgt, dass bestimmte Prozesse laufen. Das ist ja auch offenbar der Fall.
 
OP
G

goeba

Hacker
Hallo,

das bekomme ich als Ausgabe:
Code:
28/02/2018 15:12:20 increased wireframe timeouts for slow network connection.
28/02/2018 15:12:20 netrate: 74 KB/sec, latency: 1 ms
caught XIO error:
28/02/2018 15:12:21 deleted 53 tile_row polling images.

Ich habe mittlerweile herausgefunden (auch durch Verwendung in anderen VNC-Servern), dass der Crash irgendwo in der xcb - Bibliothek stattfindet, und zwar nur, wenn man den KDE Desktop verwendet.

Da gibt es offenbar einen Bug in QT im Zusammenspiel mit xcb.

Hier ist das Problem beschrieben:

https://github.com/TigerVNC/tigervnc/issues/300

Auch dort wurden verschiedene VNC Server ausprobiert.

Ich habe gerade xfce am Laufen - wow ist VNC da schnell! Das ist ein ganz anderes Feeling als mit KDE + deaktiviertem xdamage. Seufz, ich mag KDE wirklich, aber da gibt es immer eine Menge Probleme mit anderer Software ...
 
OP
G

goeba

Hacker
So,

ich habe mir die Mühe gemacht, den VNC Server nochmal auf Tumbleweed laufen zu lassen (verwendet QT 5.10).

Da tritt das Problem nicht auf.

Leap läuft noch mit QT 5.6, seufz ....

Da werde ich wohl die Systeme, auf denen ich das performant + stabil brauche, früher als geplant auf Leap 15.0 umstellen müssen.
 

spoensche

Moderator
Teammitglied
QT 5.10 gibts auch für Leap 42.3.

http://download.opensuse.org/repositories/KDE:/Qt:/5.10/openSUSE_Leap_42.3/
 
OP
G

goeba

Hacker
ja, das habe ich auch gesehen - nur der Hinweis "die Verwendung von QT > 5.6 für Leap 42.3 wird NICHT empfohlen, da Software aus den Standard- und Fremdrepositories, die QT verwendet, dann wahrscheinlich nicht mehr funktioniert!" hat mich etwas gestört!

Hat das hier jemand am Laufen?

Edit: ich meine diesen Hinweis

Note for openSUSE Leap 42.x users: Leap 42.x ships with Qt 5.6.x, which is not recent enough for Plasma 5.10+, so to use KDE:Frameworks5, KDE:Qt5 is required. Use of that is not recommended as applications in the main or 3rd party repos might break due to API/ABI changes.

auf dieser Seite

https://en.opensuse.org/SDB:KDE_repositories#KDE_Frameworks_5_.26_Plasma_5
 
OP
G

goeba

Hacker
Ich habs ausprobiert.

kde 5.12 + qt 5.10 funktioniert soweit mit Leap 42.3 (habe kurz getestet), aber das VNC-Problem hat sich damit nicht gelöst, im Gegenteil, jetzt stürzt es noch schneller ab.

Das hängt wohl irgendwie komplex mit dem Zusammenspiel von X, KDE und QT zusammen.

Ich stelle jetzt den vorherigen Zustand wieder her (gefiel mir besser, ich hatte da einiges an Konfigurationsarbeit reingesteckt) und teste mal das Verhalten von Leap 15.0 in einer virtuellen Maschine.
 
OP
G

goeba

Hacker
Unter Leap 15.0 (in einer virtuellen Maschine) läuft x0vnc (das ist das Desktop-sharing von TigerVNC) absolut stabil.

Veyon muss ich noch testen.
 

marce

Guru
goeba schrieb:
Ich habe gerade xfce am Laufen - wow ist VNC da schnell! Das ist ein ganz anderes Feeling als mit KDE + deaktiviertem xdamage. Seufz, ich mag KDE wirklich, aber da gibt es immer eine Menge Probleme mit anderer Software ...
... und diese, von Dir gefundene Lösung ist keine?

(kleiner ot-side-rant: Wenn es KDE nicht gäbe würden sich gefühlt die Hälfte aller Enduser-Probleme in Luft auflösen...)
 
OP
G

goeba

Hacker
Doch, natürlich ist das auch eine Lösung.

Da hängt in meinem Fall aber eine Menge dran, es geht mir nicht primär um mich selbst, sondern um das Schulnetzwerk, das ich betreue. Wenn man da "mal eben schnell" den Desktop umstellt, muss man mit Begleiterscheinungen rechnen.

Ferner habe ich den Eindruck, dass KDE seit 5.8.4 auf einem ganz guten Weg ist. Viele Probleme, die ich hatte, wurden zwischenzeitlich behoben.

Aber Du hast schon recht, von den Problemen, die ich habe, sind nicht wenige KDE-bezogen. Ich werde das in den kommenden zwei Jahren sehr genau beobachten. Wenn KDE den Weg "weniger neue Features, mehr Stabilität" geht, dann wird es wohl auch längerfristig mein Desktop der Wahl sein. Wenn hingegen gerade dann, wenn KDE 5.x anfängt gut zu werden, KDE 6 herauskommt und alles wieder von vorne beginnt, dann war´s das für mich mit KDE.

Wo wir schon bei off-topic sind: Wie bringt man thunar unter Opensuse eine Dateisuche bei? Unter Ubuntu gibt es catfish, SuSE scheint das nicht zu kennen?

Gruß!
 
Oben