Autostart von Programm und Neustart nach Absturz
Hallo Liste, ich habe folgendes Problem: Auf einem SBC (Single Board Computer) soll ein Programm zur Steuerung angeschlossener Hardware automatisch beim Booten gestartet werden, und wenn es abstürzt, soll es automatisch neu gestartet werden. Mit Hilfe aus dcoulm habe ich es teilweise hinbekommen, aber ein Teil fehlt mir noch: Von dem Steuerungs-Programm gibt es zwei Varianten, eins mit und eins ohne X-Windows-Oberfläche. Die Variante ohne Oberfläche läuft jetzt automatisch an, wenn Runlevel 3 erreicht ist und startet nach "Abschuss" auch wieder. Und zwar habe ich in inittab ein Script eingetragen und respawn davor gesetzt, in dem Script wird 10 Sekunden "geschlafen" und dann das Programm neu gestartet. Leider klappt das mit der anderen X-Version in Runlevel 5 nicht, denn wenn ich die aus inittab heraus starte, kann sie X-Windows nicht finden (weil es wohl noch nicht ganz da ist). Aus /etc/init.d/rc... kann ich sie auch nicht starten, denn ich kann das Script per Runlevel-Editor nicht einladen (Fehlermeldung 126?). Auf X läuft KDE 3.04, da könnte ich die X-Version über den KDE-Autostart laden, aber dann funktioniert der Neustart nach Absturz nicht, oder? Oder kann man respawn auch in einem normalen Script anwenden? Bin nicht gerade der Held in Script/Bash/Linux-Interna. Dann wäre noch die Möglichkeit, das Programm quasi als X-Shell zu starten, AFAIR wie in einem KIOSK-Modus. Aber auch dann ist nach Absturz Schluss, oder? Bin für jeden Tip dankbar. Mit freundlichem Gruß / Best regards, Jens -- embesso - embedded software solutions (http://www.embesso.com) Hinter der Bahn 1 a | D 31162 Bad Salzdetfurth Tel:(+49)5064 9504-33 | Fax:(+49)5064 9504-59
* On Fri, 10 Jan 2003 at 11:24 +0100, Jens Nixdorf wrote:
ich habe folgendes Problem: Auf einem SBC (Single Board Computer) soll ein Programm zur Steuerung angeschlossener Hardware automatisch beim Booten gestartet werden, und wenn es abstürzt, soll es automatisch neu gestartet werden. [...] Oder kann man respawn auch in einem normalen Script anwenden?
while true ; do befehl1 ; befehl2 ; befehl3 ; done -- Adalbert GPG welcome, request public key: mailto:adalbert+key@lopez.at
Hallo Adalbert, Am Freitag, 10. Januar 2003, 13:27:53, schrubtest Du:
while true ; do befehl1 ; befehl2 ; befehl3 ; done
Das heißt, wenn es in meinem script so aussieht: ---------------------------------------- while true; do sleep 10; programmaufruf; done ---------------------------------------- dann wird durch das While true schon überprüft, ob das Programm läuft? Dann ist das respawn bei der Konsolen-Version quasi doppelt gemoppelt? Mit freundlichem Gruß / Best regards, Jens -- embesso - embedded software solutions (http://www.embesso.com) Hinter der Bahn 1 a | D 31162 Bad Salzdetfurth Tel:(+49)5064 9504-33 | Fax:(+49)5064 9504-59
Jens Nixdorf
Das heißt, wenn es in meinem script so aussieht:
---------------------------------------- while true; do sleep 10; programmaufruf; done
----------------------------------------
dann wird durch das While true schon überprüft, ob das Programm läuft? Dann ist das respawn bei der Konsolen-Version quasi doppelt gemoppelt?
oh no, natürlich nicht,denn woher soll das while denn weissen??? Nein while ist einfach ein Schleifenkonstrukt, wie in anderen Programmiersprachen auch. und "true" ist ein Programm, welches bei jedem Aufruf 0 (also für die Shell der Wert für "wahr") als Exitcode abliefert. Um zu testen ob ein Programm schon läuft gibt es viele Möglichkeiten. Die einfachste: ps -aux | grep "programmname" | grep -v wenn da nix angezeigt wird, dann läuft das Programm nicht, wird was angezeigt, dann läuft es. Es gibt natürlich ausgefeiltere Techniken mit Lock-files etc, höngt vom Programm ab. also sowas wie (ungetestet): while true; do sleep 10 if [ `ps -aux | grep programmname | grep -v| wc -l` -eq 0 ] then programmaufruf & fi done sollte gehen. Jürgen -- Dr.rer.nat. Juergen Vollmer, Viktoriastrasse 15, D-76133 Karlsruhe Tel: +49(721) 9204871 Fax: +49(721) 24874 juergen@informatik-vollmer.de,vollmer@cocolab.de,Juergen.Vollmer@acm.org www.informatik-vollmer.de
* Jürgen Vollmer schrieb am 10.Jan.2003:
Um zu testen ob ein Programm schon läuft gibt es viele Möglichkeiten. Die einfachste: ps -aux | grep "programmname" | grep -v
Kann man noch einfacher mache: ps -aux | grep [p]rogrammname programmname steht hier natürlich für den Programmname. Einfach den ersten Buchstabe in [ ] setzen, so wird dann auch nur programmname gefunden, nicht aber [p]rogrammnamen, also nicht das grep selber.
if [ `ps -aux | grep programmname | grep -v| wc -l` -eq 0 ]
Auch das ist eine Nummer zu kompleziert. Warum auf die Gleichheit mit 0 testen? if überprüft den Exitcode. Wenn er 0 ist, dann wird der thenTeil, wenn nicht dann der elseTeil ausgeführt. [ ... ] bzw. test, was das Gleiche ist, gibt einen Exitcode aus. Aber das ist hier nicht nötig, da das auch grep schon macht. Es reicht somit: if ps -aux | grep -q [p]rogrammname then .... else .... fi Ein else-Teil muß natürlich nicht vorhanden sein. Wenn grep was findet, so gibt es den Exitcode 0 zurück und if gibt wahr aus, es wird then ausgeführt. Wenn greb hingegen nichts findet, dann gibt es 1 zurück und der else Teil, falls vorhanden, wird ausgeführt. Das -q im grep bewirkt, daß es keine Ausgabe gibt. Nur den Exitcode. ps -e tut es glaube ich auch. Ich nehme immer ps -ef, wobei das -f aber nur für die Länge der Ausgabe zuständig ist. Ergo reicht ps -e Bernd -- Alle meine Signaturen sind rein zufällig und haben nichts mit dem Text oder dem Schreiber zu tun, dem ich antworte. Falls irgendwelche Unrichtigkeiten dabei sein sollten, so bedauere ich das. Es wäre nett, wenn Du mich benachrichtigen würdest. |Zufallssignatur 0
ich:
Um zu testen ob ein Programm schon läuft gibt es viele Möglichkeiten. Die einfachste: ps -aux | grep "programmname" | grep -v
B.Brodesser@t-online.de (Bernd Brodesser):
Kann man noch einfacher mache: ps -aux | grep [p]rogrammname
nein, aber ich hatte auch eine Fehler, richtig müsste es heissen: ps -aux | grep "programmname" | grep -v "grep" Grund: ps findet auch den grep "programmname", den will man aber nicht sehen, deshalb den grep wieder 'raus nehemen. Jürgen -- Dr.rer.nat. Juergen Vollmer, Viktoriastrasse 15, D-76133 Karlsruhe Tel: +49(721) 9204871 Fax: +49(721) 24874 juergen@informatik-vollmer.de,vollmer@cocolab.de,Juergen.Vollmer@acm.org www.informatik-vollmer.de
* Jürgen Vollmer schrieb am 10.Jan.2003:
ich:
Um zu testen ob ein Programm schon läuft gibt es viele Möglichkeiten. Die einfachste: ps -aux | grep "programmname" | grep -v
B.Brodesser@t-online.de (Bernd Brodesser):
Kann man noch einfacher mache: ps -aux | grep [p]rogrammname
nein, aber ich hatte auch eine Fehler, richtig müsste es heissen: ps -aux | grep "programmname" | grep -v "grep" Grund: ps findet auch den grep "programmname", den will man aber nicht sehen, deshalb den grep wieder 'raus nehemen.
Schon klar. Aber wenn Du [p]rogrammname sagst, so wird programmname gefunden, aber nicht grep [p]rogrammname, da da ja die [ ] sind. Bernd -- Alle meine Signaturen sind rein zufällig und haben nichts mit dem Text oder dem Schreiber zu tun, dem ich antworte. Falls irgendwelche Unrichtigkeiten dabei sein sollten, so bedauere ich das. Es wäre nett, wenn Du mich benachrichtigen würdest. |Zufallssignatur 0
Hallo Jürgen, Am Freitag, 10. Januar 2003, 15:15:01, schrubtest Du:
Um zu testen ob ein Programm schon läuft gibt es viele Möglichkeiten. Die einfachste: ps -aux | grep "programmname" | grep -v wenn da nix angezeigt wird, dann läuft das Programm nicht, wird was angezeigt, dann läuft es. Es gibt natürlich ausgefeiltere Techniken mit Lock-files etc, höngt vom Programm ab. Danke für die Script-Beispiele (auch an Bernd), nur habe ich damit immer noch das Problem, daß es nicht _automatisch_ neu startet, sondern erst wenn ich das Script starte.
Sollte ich also das Programm einmal automatisch starten (z.B. aus dem KDE-Autostart) und gleichzeitig ein Script, daß nie endet und dauerhaft testet, ob das Programm noch läuft? Und wie geht das dann wieder? Noch eine andere Frage dazu: Wenn das Programm abstürzt, ohne sich zu beenden, also sich "nur" aufhängt, kann ich das auch abfangen? Sollte das nicht irgendwann zum Zombie werden? Mit freundlichem Gruß / Best regards, Jens -- embesso - embedded software solutions (http://www.embesso.com) Hinter der Bahn 1 a | D 31162 Bad Salzdetfurth Tel:(+49)5064 9504-33 | Fax:(+49)5064 9504-59
Hallo, On Fri, 10 Jan 2003, Jürgen Vollmer wrote:
ps -aux | grep "programmname" | grep -v ^^^^^^^ was soll das denn? Das gibt nur ein das grep-Usage! also sowas wie (ungetestet): while true; do sleep 10 if [ `ps -aux | grep programmname | grep -v| wc -l` -eq 0 ]
Wozu hier nochmal ein Programm bemuehen? Mach dir mal _explizit_ klar, dass das [] keine bash-Syntax, sondern ein bash-builtin bzw. ein externes Programm ist! Ich schreibe sowieso immer 'if test ...; then ... fi' statt 'if [ ... ] ; then ... fi'. Du verwendest also: if test `ps -aux | grep name | grep -v | wc -l` -eq 0; then (und das gibt immer noch den Fehler von grep, du muesstst if test `ps -aux | grep name | grep -v grep | wc -l` -eq 0; then verwenden). Besser aber, du bemuehst kein externes Programm fuer irgendwelche tests, sondern du nimmst direkt den Exitstatus von grep: if ps -ax | grep -q 'n[a]me'; then Zum "Trick" mit dem grep '[]' hat Bernd ja schon geschrieben, es kann uebrigens ein bel. Buchstabe sein. Das ganze macht man aber wohl evtl. besser mittels startproc/checkproc/killproc, z.B.: ,----[ /tmp/runner.sh ] | #! /bin/bash | DAEMON="/tmp/test_daemon.sh" | function do_exit { | echo "runner killed: killing $DAEMON" | /sbin/killproc -v "$DAEMON" | exit -42 | } | trap "do_exit" 1 2 3 4 5 6 7 8 10 11 12 13 14 15 17 | echo "Runner started with pid $$" | while true | do | if ! /sbin/checkproc -v "$DAEMON" | then | echo "starting $DAEMON" | /sbin/startproc -v "$DAEMON" | fi | sleep 10; | done `---- ,----[ /tmp/test_daemon.sh ] | #!/bin/sh | echo "test_daemon running: $$" | trap "echo 'test_daemon killed'; exit 42" 1 2 3 15 | while true; do echo -n "."; sleep 1; done `---- ==== dh@slarty[0]:~ (0)$ /tmp/runner.sh Runner started with pid 5566 starting /tmp/test_daemon.sh test_daemon running: 5569 .5569 ..........5569 ......test_daemon killed #### hier gab's ein 'kill 5569' starting /tmp/test_daemon.sh test_daemon running: 5592 .5592 .........5592 #### und gleich 'kill 5566' ..........runner exiting: killing /tmp/test_daemon.sh SIGTERM test_daemon.sh(5592)test_daemon killed dh@slarty[0]:~ (214)$ ==== CAVEAT: es kann (in dieser Variante) nur eine Instanz des daemons laufen. Das jew. zuerst checkproc aufrufende "runner.sh" startet ggfs. einen neuen daemon, das jew. andere meldet (checkproc -v!) die PID des momentan laufenden daemons... Startet man 2 "runner" im Abstand von 5s hat das die Wirkung von einem "sleep 5" statt dem "sleep 10" im runner... Loesung (falls obiges Verhalten unerwuenscht ist): evtl. '-f PIDFILE' fuer start-/check-/killproc. -dnh -- 7: DOS Denial Of Service (Kristian Köhntopp)
David Haller
Mach dir mal _explizit_ klar, dass das [] keine bash-Syntax, sondern ein bash-builtin bzw. ein externes Programm ist! das weiss ich, ja und? Was soll mir dabei klar werden???
Ich schreibe sowieso immer 'if test ...; then ... fi' statt 'if [ ... ] ; then ... fi'. toll, und ich mach's eben anders. Das ist doch kein Grund ein Posting zu schreiben.
Jürgen -- Dr.rer.nat. Juergen Vollmer, Viktoriastrasse 15, D-76133 Karlsruhe Tel: +49(721) 9204871 Fax: +49(721) 24874 juergen@informatik-vollmer.de,vollmer@cocolab.de,Juergen.Vollmer@acm.org www.informatik-vollmer.de
On Fri, 10 Jan 2003, Jürgen Vollmer wrote:
David Haller
Mach dir mal _explizit_ klar, dass das [] keine bash-Syntax, sondern ein bash-builtin bzw. ein externes Programm ist! das weiss ich, ja und? Was soll mir dabei klar werden???
Das was du eigentlich dabei machst! Naemlich den Exit-Status eines Programmes/Builtins mittels 'if' auf 0 (bzw. != 0) zu testen... Und wenn du dann noch die bash (bzgl. 'if foo | bar') und grep kennst, merkst du, dass dein Umweg via test (bzw. [ .. ]) schlicht ueberfluessig bzw. sogar irritierend ist. Ein gutes Beispiel ist z.B. das in vorangegangenen Mail folgende if ! /sbin/checkproc ... Das zeigt die Semantik des 'if' (hier eben mit der Negation durch das '!')... Sorry, wenn ich das im ersten Versuch nicht so gut rueberbringen konnte, hab' diese Nacht leider kaum geschlafen...
Ich schreibe sowieso immer 'if test ...; then ... fi' statt 'if [ ... ] ; then ... fi'. toll, und ich mach's eben anders.
Mach das mit dem '[ .. ]' statt dem 'test ...', wegen mir... Wegen mir darfst du auch ein 'rm -rf /' als root machen, dir eine Frikadelle ans Knie nageln oder dir auch in den Fuss schiessen, das ist mir alles egal... Ich werde das '[ .. ]' statt 'test ...' aber weiterhin nicht fuer "guten Stil" halten (und ggfs. fuer die/im Sinne der Allgemeinheit kritisieren), da das u.a. das oben angesprochene, also die eigentliche "Semantik" des 'if' der bash, eben verdeckt, das ist halt (auch, aber eben nicht nur) eine Stilfrage[1]...
Das ist doch kein Grund ein Posting zu schreiben.
Wie meinen??? -dnh [1] Apropos: dass SuSE das '.' fuer 'source' in diversen config-dateien und init-scripten verwendet halte ich fuer noch schlimmer, ein Grund ist z.B. dass man nicht folgendes sinnvoll machen kann: grep 'source' <DATEI> oder aehnliches... Ach, das Argument zieht uebrigens auch bei '[' vs. 'test' ;) -- Wir leben in der Unterhaltungsbranche. Wuerde sonst jemand ernsthaft ueber "NT" als Server - OS nachdenken ? [Hans Bonfigt]
On Fre, 10 Jan 2003 at 23:40 (+0100), David Haller wrote: He, beruhigt Euch beide mal wieder ;-)
On Fri, 10 Jan 2003, Jürgen Vollmer wrote:
David Haller
Mach dir mal _explizit_ klar, dass das [] keine bash-Syntax, sondern ein bash-builtin bzw. ein externes Programm ist! das weiss ich, ja und? Was soll mir dabei klar werden???
Das was du eigentlich dabei machst! Naemlich den Exit-Status eines Programmes/Builtins mittels 'if' auf 0 (bzw. != 0) zu testen... Und wenn du dann noch die bash (bzgl. 'if foo | bar') und grep kennst, merkst du, dass dein Umweg via test (bzw. [ .. ]) schlicht ueberfluessig bzw. sogar irritierend ist.
ACK. [...]
Ich werde das '[ .. ]' statt 'test ...' aber weiterhin nicht fuer "guten Stil" halten (und ggfs. fuer die/im Sinne der Allgemeinheit kritisieren), da das u.a. das oben angesprochene, also die eigentliche "Semantik" des 'if' der bash, eben verdeckt, das ist halt (auch, aber eben nicht nur) eine Stilfrage[1]...
Das ist IMHO _ausschließlich_ eine Stilfrage. Beide Varianten haben Vor- und Nachteile, beide Varianten sind funktional identisch. Ich sehe es zum Beispiel als Vorteil der [] an, dass Anfang und Ende des zu prüfenden Ausdrucks besser zu sehen sind (bei mehrzeiligen Ausdrücken etwa), und dass Editoren (z. B. der vi) diese Klammerung erkennen und beim Editieren auch anzeigen.
Das ist doch kein Grund ein Posting zu schreiben.
Warum nicht? Davids Posting diente der Klarstellung des o. g. Sachverhalts (test programm wertet den Exit-Status aus), der bei Deinem Posting nicht klar wurde. [...]
[1] Apropos: dass SuSE das '.' fuer 'source' in diversen config-dateien und init-scripten verwendet halte ich fuer noch schlimmer, ein Grund ist z.B. dass man nicht folgendes sinnvoll machen kann: grep 'source' <DATEI> oder aehnliches... Ach, das Argument zieht uebrigens auch bei '[' vs. 'test' ;)
Ähm - David, jetzt enttäuschst Du mich aber :-) Gerade von _Dir_ dieses Argument zu lesen ... *tststs* jan@k500:~/tmp> cat test.sh if test ls datei; then echo "datei lebt" source datei fi if [ ls datei ]; then echo "datei lebt" . datei fi jan@k500:~/tmp> grep source test.sh source datei jan@k500:~/tmp> grep "\. " test.sh . datei jan@k500:~/tmp> grep "test" test.sh if test ls datei; then jan@k500:~/tmp> grep " \[ " test.sh if [ ls datei ]; then jan@k500:~/tmp> Es ist mir schon klar, dass diese Suchmuster nicht perfekt sind, aber das ist Dein Beispiel auch nicht (Bsp. sourceDir=/home/jan). Und man kann für alle Formen ein halbwegs sicheres Muster aufbauen (denn auch der . und die [] müssen ja gewissen syntaktischen Regeln gehorchen). Jan
Hallo, On Sat, 11 Jan 2003, Jan Trippler wrote:
On Fre, 10 Jan 2003 at 23:40 (+0100), David Haller wrote:
[...]
[1] Apropos: dass SuSE das '.' fuer 'source' in diversen config-dateien und init-scripten verwendet halte ich fuer noch schlimmer, ein Grund ist z.B. dass man nicht folgendes sinnvoll machen kann: grep 'source' <DATEI> oder aehnliches... Ach, das Argument zieht uebrigens auch bei '[' vs. 'test' ;)
Ähm - David, jetzt enttäuschst Du mich aber :-) Gerade von _Dir_ dieses Argument zu lesen ... *tststs*
Aehm, grep '\(^\|[ ]\)\.[ ]' ist a) nicht ideal/einfach und b) nicht sonderlich eindeutig. Jan, hast du schon mal versucht das aequivalent von grep '#[ ]include' auf bash-scripten auszufuehren? Womoeglich rekursiv? -dnh -- 92: Emacs Esc Meta Alt Control Shift
* David Haller schrieb am 10.Jan.2003:
[1] Apropos: dass SuSE das '.' fuer 'source' in diversen config-dateien und init-scripten verwendet halte ich fuer noch schlimmer, ein Grund ist z.B. dass man nicht folgendes sinnvoll machen kann: grep 'source' <DATEI> oder aehnliches... Ach, das Argument zieht uebrigens auch bei '[' vs. 'test' ;)
Allerdings ist der . ursprünglicher als source. . gibt es auch in der Bourneshell, source kam erst später hinzu. Bei test ist es umgekehrt, hier ist test der ältere Befehl. Damals aber noch kein Builtin. Bernd -- Bitte die Etikette beachten: http://www.suse-etikette.de.vu/etikette.html Bitte Realnamen angeben, kein Vollquoting, kein Html, PGP oder Visitenkarten benutzen. Signatur mit "-- " abtrennen, bei Antworten "Re: " voranstellen, sonst nichts. |Zufallssignatur 4
Hallo, On Sat, 11 Jan 2003, Bernd Brodesser wrote:
* David Haller schrieb am 10.Jan.2003:
[1] Apropos: dass SuSE das '.' fuer 'source' in diversen config-dateien und init-scripten verwendet halte ich fuer noch schlimmer, ein Grund ist z.B. dass man nicht folgendes sinnvoll machen kann: grep 'source' <DATEI> oder aehnliches... Ach, das Argument zieht uebrigens auch bei '[' vs. 'test' ;)
Allerdings ist der . ursprünglicher als source. . gibt es auch in der Bourneshell,
Oh. Naja, dann geht der Hieb gleich weiter in die Richtung der damaligen bourne-shell-Entwickler *eg*. Sowas wie '.' oder '[' sind ja als alias (der sogar symlink) ok, aber generell? *hrmpf*
source kam erst später hinzu. Bei test ist es umgekehrt, hier ist test der ältere Befehl. Damals aber noch kein Builtin.
Auch bei SuSE 6.2 (und wohl auch noch heute) ist /usr/bin/test (auch!) ein externes C-Proggie ;) # rpm -qf /usr/bin/test sh_utils-1.16-74 -dnh -- 'Tell me, what is happiness?' 'Happiness? Happiness... is to wake up, on a bright spring morning, after an exhausting first night spent with a beautiful... passionate... multi-murderess.' -- Use of Weapons, Prologue, by Iain M. Banks
* David Haller schrieb am 11.Jan.2003:
On Sat, 11 Jan 2003, Bernd Brodesser wrote:
Allerdings ist der . ursprünglicher als source. . gibt es auch in der Bourneshell,
Oh. Naja, dann geht der Hieb gleich weiter in die Richtung der damaligen bourne-shell-Entwickler *eg*.
Wie hieß der gleich noch mal? Ich glaube Bourne, oder so. ;)
Sowas wie '.' oder '[' sind ja als alias (der sogar symlink) ok, aber generell? *hrmpf*
Man muß aber auch sehen, wo es angewendet wird. Während test fast ausschließlich in Skripten zur Anwendung kommt, wird . doch häufig, wenn nicht häufiger von der Kommandozeile aus aufgerufen. Da ist es schlichtweg einfacher zu sagen: . .profile, als source .profile.
source kam erst später hinzu. Bei test ist es umgekehrt, hier ist test der ältere Befehl. Damals aber noch kein Builtin.
Auch bei SuSE 6.2 (und wohl auch noch heute) ist /usr/bin/test (auch!) ein externes C-Proggie ;)
Schon klar, nur wird es vom builtin überdeckt. Wenn man nicht explizit /usr/bin/test sagt, wird das builtin genommen. Bernd -- Bitte die Etikette beachten: http://www.suse-etikette.de.vu/etikette.html Bitte Realnamen angeben, kein Vollquoting, kein Html, PGP oder Visitenkarten benutzen. Signatur mit "-- " abtrennen, bei Antworten "Re: " voranstellen, sonst nichts. |Zufallssignatur 4
David Haller
[1] Apropos: dass SuSE das '.' fuer 'source' in diversen config-dateien und init-scripten verwendet halte ich fuer noch schlimmer, ein Grund ist z.B. dass man nicht folgendes sinnvoll machen kann: grep 'source' <DATEI> oder aehnliches... Ach, das Argument zieht uebrigens auch bei '[' vs. 'test' ;)
source ist eine Bash-Spezialität, während '.' von *jeder* bourne kompatiblen shell unterstützt wird. Aus den gleichen Kompatibilitätsgründen sollte man auch auf if [...] verzichten und explizit 'test' aufrufen. Philipp -- Philipp Thomas Arbeit: pthomas@suse.de Entwicklung, SuSE Linux AG Privat: pth@t-link.de
On Sam, 11 Jan 2003 at 03:05 (+0100), Philipp Thomas wrote: [...]
source ist eine Bash-Spezialität, während '.' von *jeder* bourne kompatiblen shell unterstützt wird. Aus den gleichen Kompatibilitätsgründen sollte man auch auf if [...] verzichten und explizit 'test' aufrufen.
[] ist aber nicht bash-spezifisch. Das hat bei mir bisher noch bei jedem *nix in einer Bourne- oder Korn-Shell funktioniert. Es gibt vielleicht Ausnahmen, die sind mir aber noch nicht begegnet. Jan
* On Fri, 10 Jan 2003 at 14:39 +0100, Jens Nixdorf wrote:
Am Freitag, 10. Januar 2003, 13:27:53, schrubtest Du:
while true ; do befehl1 ; befehl2 ; befehl3 ; done
Das heißt, wenn es in meinem script so aussieht:
---------------------------------------- while true; do sleep 10; programmaufruf; done
----------------------------------------
dann wird durch das While true schon überprüft, ob das Programm läuft? Dann ist das respawn bei der Konsolen-Version quasi doppelt gemoppelt?
Ich gehe mal davon aus, daß Dein Programm nicht als Daemon läuft, d.h. daß es erst zum Aufrufer zurückkehrt, wenn es feritg oder abgestürzt ist - dann ist das respawn überflüssig. Wenn es als Daemon läuft, würde es so im 10-sekunden Abstand neu gestartet. -- Adalbert GPG welcome, request public key: mailto:adalbert+key@lopez.at
participants (7)
-
Adalbert Michelic -
B.Brodesser＠t-online.de -
David Haller -
Jan.Trippler＠t-online.de -
Jens Nixdorf -
Jürgen Vollmer -
Philipp Thomas