Programm per Cronjob gestartet, läuft, nur wo ist es ?
Hallo Listige Ich habe ein absturzfreudiges Programm in den Griff bekommen in dem ich es alle 5 Minuten per Cronjob kontrollieren und wenn nötig neu starten lasse. <schnipp> #!/bin/bash if pidof programm > /dev/null ; then exit else "/usr/bin/programm" -g & fi <schnapp> Das klappt soweit auch echt klasse. Mein Problem ist jetzt, wenn ich es nun kontrolliert beenden möchte (nicht per kill), könnte ich das nur in einer Konsole. Doch da taucht das Teil nicht auf. Jobs bringt keine Ausgabe. Gibt es eine Möglichkeit zum Beispiel an Hand der PID (die kriege ich per Top) die Ausgabe des Programmes irgendwie in (m)eine Konsole zu bekommen. Oder sollte ich mein Script abändern das ich die Ausgabe des Programmes (und dadurch den Zugriff) in der Konsole haben kann. Wenn ja, dann wie ? Gegoogelt habe ich auch, glaube aber nicht die richtigen Worte gefunden zu haben. Gruss Thomas (der versucht seine mickrigen Scriptingkenntnisse aufzubessern)
Thomas Janssen wrote:
Mein Problem ist jetzt, wenn ich es nun kontrolliert beenden möchte (nicht per kill), könnte ich das nur in einer Konsole.
Was spricht den gegen kill? Das macht ohne Parameter (also mit implizierten -15) nix anderes, als jede andere Beenden-Anforderung auch: es teilt dem Programm mit, daß es sich doch bitte beenden möge. Wie Du die PID herausbekommst, steht in Deinem Skript. Martin
Am Freitag, 11. Februar 2005 19:07 schrieb Martin Schmitz:
Thomas Janssen wrote:
Mein Problem ist jetzt, wenn ich es nun kontrolliert beenden möchte (nicht per kill), könnte ich das nur in einer Konsole.
Was spricht den gegen kill? Das macht ohne Parameter (also mit implizierten -15) nix anderes, als jede andere Beenden-Anforderung auch: es teilt dem Programm mit, daß es sich doch bitte beenden möge. Wie Du die PID herausbekommst, steht in Deinem Skript.
Gut, mit dem Beenden durch Kill könnte ich wohl noch leben. Doch ich habe so im Moment auch keinen Einfluss auf das Programm, kann keine Parameter ändern nichts. Kann ich dem Teil beim starten nicht mitteilen (per Script) das es zum Beispiel in eine laufende (wartende) Konsole soll ? Ich weiß nicht ob so etwas geht. Oder irgendwie in eine Konsole holen. Gruss Thomas
Am Freitag, 11. Februar 2005 19:07 schrieb Martin Schmitz:
Thomas Janssen wrote:
Mein Problem ist jetzt, wenn ich es nun kontrolliert beenden möchte (nicht per kill), könnte ich das nur in einer Konsole.
Was spricht den gegen kill? Das macht ohne Parameter (also mit implizierten -15) nix anderes, als jede andere Beenden-Anforderung auch: es teilt dem Programm mit, daß es sich doch bitte beenden möge. Wie Du die PID herausbekommst, steht in Deinem Skript.
Aber Signal 15 kann wie alle andere Signale, außer Signal 9, abgefangen werden. Mithin kann Signal 15 was anderes machen als Signal 2. Signal 2 ist das Signal, was Du mit einem CTRL-C an alle von einer Konsole kontrollierte Prozesse weitergibst. Signal 3 das gleiche mit CTRL-/ Signal 1 wird bei einem Hangup gegeben, also beim Beenden einer Konsole. Signal 14 gibt die Alarmuhr aus Signal 15 wenn man ein kill ohne Argument angibt. Signal 9 kann nur durch ein kill -9 oder entsprechendes gegeben werden. Das kann nicht abgefangen werden und ist der befürchtete unkontrollierte Abbruch. Sollte nach Möglichkeit nicht verwendet werden, nur wenn es nicht anders geht, weil ein Dämel von Programmierer alles andere abfängt. Bernd
On Fri, Feb 11, 2005 at 06:51:59PM +0100, Thomas Janssen wrote:
Gibt es eine Möglichkeit zum Beispiel an Hand der PID (die kriege ich per Top) die Ausgabe des Programmes irgendwie in (m)eine Konsole zu bekommen.
meines Wissens geht das nicht, weshalb ich mir "screen" zu Diensten mache. -- Peter
Am Freitag, 11. Februar 2005 18:51 schrieb Thomas Janssen:
Mein Problem ist jetzt, wenn ich es nun kontrolliert beenden möchte (nicht per kill),
Was spricht gegen kill?
könnte ich das nur in einer Konsole. Doch da taucht das Teil nicht auf. Jobs bringt keine Ausgabe. Gibt es eine Möglichkeit zum Beispiel an Hand der PID (die kriege ich per Top) die Ausgabe des Programmes irgendwie in (m)eine Konsole zu bekommen. Oder sollte ich mein Script abändern das ich die Ausgabe des Programmes (und dadurch den Zugriff) in der Konsole haben kann.
Wie kommst Du auf die merkwürdige Idee, daß Du mit der Ausgabe auch einen Zugriff auf das Programm hast? Wenn schon, dann durch die Eingabe, was was völlig anders ist. Aber die Frage bleibt, was Du unter Zugriff meinst. Die Ausgabe kannst Du einfach durch ein > umlenken und die Eingabe durch ein < programm > /dev/tty1 schreibt auf die erste virtuelle Konsole programm < /dev/tty2 liest von der zweiten virtuellen Konsole programm 2> /dev/tty3 hat die Fehlerausgabe auf die dritte virtuelle Konsole. programm < /dev/tty2 > /dev/tty1 2>/dev/tty3 schreibt auf die erste virtuelle Konsole, liest von der zweiten virtuellen Konsole und hat seine Fehlerausgabe auf die dritte virtuelle Konsole. Allerdings schreibt das Programm wild auf die Konsole, egal ob da einer eingeloggt ist, oder nicht. Das kann ganz schön verwirrend sein, wenn man da was eingibt und ein Programm schreibt irgendwas dazwischen. Da wo man eingibt liest nur das, was man eingegeben hat, von den Geschreibsel des Programms weiß es nichts. Wenn Du zum Beispiel irgend einen Befehl auf der Konsole eingibst und da schreibt dann ein Programm irgendwas anderes auf der Konsole, dann muß Du ganz genau so eingeben was Du auch ohne das Geschreibsel eingegeben hättest. Vor allem darfst Du kein Leerzeichen hinmachen wo keins hingehört. Das ist sehr verwirrend. Also das mit der Ausgabe auf der Konsole ist eine Schnapsidee, es sei Du willst eine Ausgabe verfolgen und willst da ganz bestimmt nicht einloggen, so wie auf /dev/tty10 wo bei SuSE eine Ausgabe des Kernels steht. Aber auch mit der Eingabe ist Essig. Denn entweder das Programm erwartet eine Eingabe, dann muß Du sie auch machen, oder es erwartet keine, dann nützt es nichts, wenn Du eine machst, sie wird nie gelesen. Wenn Du sowas wie CTRL-C meinst, das ist komplizierter, da es da nach Prozeßgruppe und zugeordnete Konsole geht. Viel einfacher ist doch ein kill -2, das macht das gleiche wie ein CTRL-C
Thomas (der versucht seine mickrigen Scriptingkenntnisse aufzubessern)
Hat weniger was mit Scriptkenntnissen zu tun, als mit Kenntnisse von Prozeßabläufe. Vor allem Umlenkung von Ein- und Ausgabe, sowie den Signalmechanismus solltest Du Dich befassen. < > und 2> gehört zwar zur Syntax der Shell, aber dem liegen Systemaufrufe zugrunde, genau wie dem Befehl kill. Bernd Bernd
Am Freitag, 11. Februar 2005 21:49 schrieb Bernd Brodeßer:
Am Freitag, 11. Februar 2005 18:51 schrieb Thomas Janssen:
Mein Problem ist jetzt, wenn ich es nun kontrolliert beenden möchte (nicht per kill),
Was spricht gegen kill?
Ist ein Quit in einem Programm und ein Kill das selbe ? Ich denke nicht. Mit dem Quit werden zuerst noch alle offenen Dinge(tm) beendet und gespeichert. Mit kill auch ?
könnte ich das nur in einer Konsole. Doch da taucht das Teil nicht auf. Jobs bringt keine Ausgabe. Gibt es eine Möglichkeit zum Beispiel an Hand der PID (die kriege ich per Top) die Ausgabe des Programmes irgendwie in (m)eine Konsole zu bekommen. Oder sollte ich mein Script abändern das ich die Ausgabe des Programmes (und dadurch den Zugriff) in der Konsole haben kann.
Wie kommst Du auf die merkwürdige Idee, daß Du mit der Ausgabe auch einen Zugriff auf das Programm hast? Wenn schon, dann durch die Eingabe, was was völlig anders ist. Aber die Frage bleibt, was Du unter Zugriff meinst.
Was für einen Zugriff hast Du auf Mutt ? Es ist ein Konsolenprogramm, das bedeutet ich kann damit in der Konsole arbeiten. Vorraussetzung ist allerdings das es auch in der Konsole läuft. Wenn ich es aber mit meinem Watchdog starte habe ich keinen Zugriff darauf, kann nicht damit arbeiten. Kann ihm keine Befehle übermitteln und sehe nicht was abläuft. Kein Zugriff. Ausser kill. Ganz davon ab ist das ganze soweit ja gelöst, bis auf das Quoting (wenn man es denn so nennt). Es läuft jetzt in einer Konsole nur fehlt noch die "Programmoption -g" die ich nicht gebacken bekomme. Siehe die Beispiele in meinem anderen Posting. Gruss Thomas
Am Freitag, 11. Februar 2005 22:08 schrieb Thomas Janssen:
Am Freitag, 11. Februar 2005 21:49 schrieb Bernd Brodeßer:
Am Freitag, 11. Februar 2005 18:51 schrieb Thomas Janssen:
Mein Problem ist jetzt, wenn ich es nun kontrolliert beenden möchte (nicht per kill),
Was spricht gegen kill?
Ist ein Quit in einem Programm und ein Kill das selbe ? Ich denke nicht. Mit dem Quit werden zuerst noch alle offenen Dinge(tm) beendet und gespeichert. Mit kill auch ?
Was ist Quit? Das Programm kenne ich nicht.
könnte ich das nur in einer Konsole. Doch da taucht das Teil nicht auf. Jobs bringt keine Ausgabe. Gibt es eine Möglichkeit zum Beispiel an Hand der PID (die kriege ich per Top) die Ausgabe des Programmes irgendwie in (m)eine Konsole zu bekommen. Oder sollte ich mein Script abändern das ich die Ausgabe des Programmes (und dadurch den Zugriff) in der Konsole haben kann.
Wie kommst Du auf die merkwürdige Idee, daß Du mit der Ausgabe auch einen Zugriff auf das Programm hast? Wenn schon, dann durch die Eingabe, was was völlig anders ist. Aber die Frage bleibt, was Du unter Zugriff meinst.
Was für einen Zugriff hast Du auf Mutt ?
Du meinst Standardeingabe, Standardausgabe und Standardfehlerausgabe? Wenn man es nicht umlenkt, dann auf der Konsole von der man es aus startet. Ganz normales verhalten.
Es ist ein Konsolenprogramm, das bedeutet ich kann damit in der Konsole arbeiten.
Jedes Programm ist dann ein Konsolenprogramm, denn jeder Prozeß hat eine Standardeingabe, eine Standardausgabe und eine Standardfehlerausgabe. Es kann natürlich sein, daß das Programm ein Teil davon oder alles nicht nutzt.
Vorraussetzung ist allerdings das es auch in der Konsole läuft. Wenn ich es aber mit meinem Watchdog starte habe ich keinen Zugriff darauf, kann nicht damit arbeiten.
Ja, dann muß Du Standardeingabe, Standardausgabe und Standardfehlerausgabe umlenken, da dem Prozeß keinen Bildschirm zugeordnet wird
Kann ihm keine Befehle übermitteln und sehe nicht was abläuft. Kein Zugriff. Ausser kill.
Habe ich geschrieben, Du muß Standardausgabe, -eingabe und auch -fehlerausgabe auf einen Bildschirm umlenken. Bei Unix/Linux verhält sich ein Bildschirm nicht anders als eine Datei. Mit programm > datei schreibst Du die Ausgabe in die Datei datei und mit programm > /dev/tty4 schreibst Du die Ausgabe auf die virtuelle Konsole 4
Ganz davon ab ist das ganze soweit ja gelöst, bis auf das Quoting (wenn man es denn so nennt). Es läuft jetzt in einer Konsole nur fehlt noch die "Programmoption -g" die ich nicht gebacken bekomme. Siehe die Beispiele in meinem anderen Posting.
Mich interessiert hier nicht so sehr darum, daß Dein konkretes Problem gelöst wird, sondern mehr darum, daß Du und andere Mitleser verstehen, wie Linux und besonders die Prozesse darin funktionieren. Wenn Du da Ahnung von bekommst, dann bringt Dich das wesentlich weiter im Verständnis von Linux, als wenn nur irgend ein Programm läuft und Du weißt nicht warum. Bernd
Am Freitag, 11. Februar 2005 23:23 schrieb Bernd Brodeßer:
Am Freitag, 11. Februar 2005 22:08 schrieb Thomas Janssen:
Am Freitag, 11. Februar 2005 21:49 schrieb Bernd Brodeßer:
Am Freitag, 11. Februar 2005 18:51 schrieb Thomas Janssen:
Mein Problem ist jetzt, wenn ich es nun kontrolliert beenden möchte (nicht per kill),
Was spricht gegen kill?
Ist ein Quit in einem Programm und ein Kill das selbe ? Ich denke nicht. Mit dem Quit werden zuerst noch alle offenen Dinge(tm) beendet und gespeichert. Mit kill auch ?
Was ist Quit? Das Programm kenne ich nicht.
Die Funktion "Quit" - "Beenden" eines Programmes. Ich denke das kennst Du sehr wohl. Da ich kein Programmierer bin, kann ich nicht sagen ob das ein kill auslöst.
könnte ich das nur in einer Konsole. Doch da taucht das Teil nicht auf. Jobs bringt keine Ausgabe. Gibt es eine Möglichkeit zum Beispiel an Hand der PID (die kriege ich per Top) die Ausgabe des Programmes irgendwie in (m)eine Konsole zu bekommen. Oder sollte ich mein Script abändern das ich die Ausgabe des Programmes (und dadurch den Zugriff) in der Konsole haben kann.
Wie kommst Du auf die merkwürdige Idee, daß Du mit der Ausgabe auch einen Zugriff auf das Programm hast? Wenn schon, dann durch die Eingabe, was was völlig anders ist. Aber die Frage bleibt, was Du unter Zugriff meinst.
Was für einen Zugriff hast Du auf Mutt ?
Du meinst Standardeingabe, Standardausgabe und Standardfehlerausgabe? Wenn man es nicht umlenkt, dann auf der Konsole von der man es aus startet. Ganz normales verhalten.
Das meine ich, das normale Verhalten.
Es ist ein Konsolenprogramm, das bedeutet ich kann damit in der Konsole arbeiten.
Jedes Programm ist dann ein Konsolenprogramm, denn jeder Prozeß hat eine Standardeingabe, eine Standardausgabe und eine Standardfehlerausgabe. Es kann natürlich sein, daß das Programm ein Teil davon oder alles nicht nutzt.
Ok, Du willst mich nicht verstehen, sondern mir etwas über stdin, stdout und stderr beibringen. Ich möchte aber kein Script basteln das über 40 Zeilen geht und alles mögliche umlenken muss.
Vorraussetzung ist allerdings das es auch in der Konsole läuft. Wenn ich es aber mit meinem Watchdog starte habe ich keinen Zugriff darauf, kann nicht damit arbeiten.
Ja, dann muß Du Standardeingabe, Standardausgabe und Standardfehlerausgabe umlenken, da dem Prozeß keinen Bildschirm zugeordnet wird
Kann ihm keine Befehle übermitteln und sehe nicht was abläuft. Kein Zugriff. Ausser kill.
Habe ich geschrieben, Du muß Standardausgabe, -eingabe und auch -fehlerausgabe auf einen Bildschirm umlenken. Bei Unix/Linux verhält sich ein Bildschirm nicht anders als eine Datei. Mit programm > datei schreibst Du die Ausgabe in die Datei datei und mit programm > /dev/tty4 schreibst Du die Ausgabe auf die virtuelle Konsole 4
Das ganze muss ich doch nicht extra umlenken, wenn das Programm sofort in einer Konsole startet. konsole -e "/usr/bin/edonkeyclc" -g würde das ja eigentlich machen. Nur kommt da eine aufpoppende Konsole die sich nach 1 Sekunde mit Signal 1 wieder verabschiedet. Also denke ich mir das die letzte Option -g daran schuld ist, da die Konsole sich vermutlich mit der Option angesprochen fühlt. Oder dann die andere Frage, warum verabschiedet sich die Konsole nach 1 Sekunde wieder mit Signal 1 ?
Ganz davon ab ist das ganze soweit ja gelöst, bis auf das Quoting (wenn man es denn so nennt). Es läuft jetzt in einer Konsole nur fehlt noch die "Programmoption -g" die ich nicht gebacken bekomme. Siehe die Beispiele in meinem anderen Posting.
Mich interessiert hier nicht so sehr darum, daß Dein konkretes Problem gelöst wird, sondern mehr darum, daß Du und andere Mitleser verstehen, wie Linux und besonders die Prozesse darin funktionieren. Wenn Du da Ahnung von bekommst, dann bringt Dich das wesentlich weiter im Verständnis von Linux, als wenn nur irgend ein Programm läuft und Du weißt nicht warum.
Vielen Dank Bernd das Du versucht hast das Problem zu verstehen. Gruss Thomas
Am Samstag, 12. Februar 2005 10:34 schrieb Thomas Janssen:
Am Freitag, 11. Februar 2005 23:23 schrieb Bernd Brodeßer:
Am Freitag, 11. Februar 2005 22:08 schrieb Thomas Janssen:
Am Freitag, 11. Februar 2005 21:49 schrieb Bernd Brodeßer:
Am Freitag, 11. Februar 2005 18:51 schrieb Thomas Janssen:
Was ist Quit? Das Programm kenne ich nicht.
Die Funktion "Quit" - "Beenden" eines Programmes. Ich denke das kennst Du sehr wohl. Da ich kein Programmierer bin, kann ich nicht sagen ob das ein kill auslöst.
Du meinst einfach das Ende eines Programms. Ok, was soll da gemacht werden? Gar nichts wird da gemacht. Natürlich kann es sein, daß da noch irgendwas aufgeräumt ist, aber das ist Teil des Programms. Wenn man ein kill eingibt, dann wird normalerweise ein Programm ab diesen Punkt einfach beendet. Wenn es aber nochwas aufzuräumen gibt, so wäre es ein schlechter Programmierstil, wenn ein normales kill oder auch ein kill -2 usw. nicht abgefangen würde. Üblich ist, daß z.B ein kill -2 was exakt das Gleiche ist wie ein CTRL-C, abgefangen wird, dann noch was aufgeräumt und dann sich das Programm beendet. Aber wenn der Programmierer das nicht programmiert hat, dann passiert natürlich nichts.
Du meinst Standardeingabe, Standardausgabe und Standardfehlerausgabe? Wenn man es nicht umlenkt, dann auf der Konsole von der man es aus startet. Ganz normales verhalten.
Das meine ich, das normale Verhalten.
Ja, und? Wenn Du das so machst, wie Du beschrieben hast, dann ist aber den Prozessen kein Bildschirm zugeordnet. welcher den auch?
Jedes Programm ist dann ein Konsolenprogramm, denn jeder Prozeß hat eine Standardeingabe, eine Standardausgabe und eine Standardfehlerausgabe. Es kann natürlich sein, daß das Programm ein Teil davon oder alles nicht nutzt.
Ok, Du willst mich nicht verstehen,
Ich verstehe es wirklich nicht.
sondern mir etwas über stdin, stdout und stderr beibringen. Ich möchte aber kein Script basteln das über 40 Zeilen geht und alles mögliche umlenken muss.
Ich verstehe nicht, was Du willst. Du hast geschrieben, Du willst die Ausgabe umlenken. Aber das hat wirklich nichts damit zu tun, wie ein Programm beendet wird. Wenn Du z.B die Ausgabe von mutt umlenkst, dann hast Du noch lange nicht die Eingabe umgelenkt. Und um etwas umzulenken brauchst Du keine 40 Zeilen, das macht man in einer.
Habe ich geschrieben, Du muß Standardausgabe, -eingabe und auch -fehlerausgabe auf einen Bildschirm umlenken. Bei Unix/Linux verhält sich ein Bildschirm nicht anders als eine Datei. Mit programm > datei schreibst Du die Ausgabe in die Datei datei und mit programm > /dev/tty4 schreibst Du die Ausgabe auf die virtuelle Konsole 4
Das ganze muss ich doch nicht extra umlenken, wenn das Programm sofort in einer Konsole startet.
Wenn Du eine interaktive shell hast, dann ist schon ein stdin, stdout und stderr definiert, der Prozeß, der durch Aufruf eines Programms ausgelöst wird, übernimmt dieser Prozeß diese Teile. Wenn Du aber nicht von einer shell aus aufrufst, dann kann der Prozeß ja auch dies nicht übernehmen, weil sie nicht definiert sind.
konsole -e "/usr/bin/edonkeyclc" -g
Moment, ich ging davon aus, daß Du mit Konsole die virtuellen Konsolen meinst, das sind die Teile, die Du mit ALT-CTRL-F1 bis ALT-CTRL-F6 erreichst. Aber im Prinzip ist es egal. Auch bei diesen x-terminals ist es eigentlich genauso.
würde das ja eigentlich machen. Nur kommt da eine aufpoppende Konsole die sich nach 1 Sekunde mit Signal 1 wieder verabschiedet.
Weil die Konsole geschlossen wurde, dann verschickt sie an alle Prozesse wo sie die kontrollierende Konsole ist, das Signal 1. Warum die Konsole geschlossen wurde, weiß ich nicht, ich kenne mich mit den Dinger nicht aus.
Also denke ich mir das die letzte Option -g daran schuld ist, da die Konsole sich vermutlich mit der Option angesprochen fühlt. Oder dann die andere Frage, warum verabschiedet sich die Konsole nach 1 Sekunde wieder mit Signal 1 ?
Keine Ahnung. Wenn ich sowas brauche, verwende ich xterm. Ansonsten benutze ich die virtuellen Konsolen. Bernd
Am Samstag, 12. Februar 2005 10:58 schrieb Bernd Brodeßer:
Am Samstag, 12. Februar 2005 10:34 schrieb Thomas Janssen:
Am Freitag, 11. Februar 2005 23:23 schrieb Bernd Brodeßer:
Am Freitag, 11. Februar 2005 22:08 schrieb Thomas Janssen:
Am Freitag, 11. Februar 2005 21:49 schrieb Bernd Brodeßer:
Am Freitag, 11. Februar 2005 18:51 schrieb Thomas Janssen:
Was ist Quit? Das Programm kenne ich nicht.
Die Funktion "Quit" - "Beenden" eines Programmes. Ich denke das kennst Du sehr wohl. Da ich kein Programmierer bin, kann ich nicht sagen ob das ein kill auslöst.
Du meinst einfach das Ende eines Programms. Ok, was soll da gemacht werden? Gar nichts wird da gemacht. Natürlich kann es sein, daß da noch irgendwas aufgeräumt ist, aber das ist Teil des Programms. Wenn man ein kill eingibt, dann wird normalerweise ein Programm ab diesen Punkt einfach beendet. Wenn es aber nochwas aufzuräumen gibt, so wäre es ein schlechter Programmierstil, wenn ein normales kill oder auch ein kill -2 usw. nicht abgefangen würde. Üblich ist, daß z.B ein kill -2 was exakt das Gleiche ist wie ein CTRL-C, abgefangen wird, dann noch was aufgeräumt und dann sich das Programm beendet. Aber wenn der Programmierer das nicht programmiert hat, dann passiert natürlich nichts.
Der Programmierer hat leider nichts implementiert. Das bedeutet das Programm macht per kill (egal welche Zahl) die Grätsche und ist beim nächsten Start erstmal 15 Minuten damit beschäftigt die MD5-Summen erneut zu berechnen.
Du meinst Standardeingabe, Standardausgabe und Standardfehlerausgabe? Wenn man es nicht umlenkt, dann auf der Konsole von der man es aus startet. Ganz normales verhalten.
Das meine ich, das normale Verhalten.
Ja, und? Wenn Du das so machst, wie Du beschrieben hast, dann ist aber den Prozessen kein Bildschirm zugeordnet. welcher den auch?
Das habe ich inzwischen auch begriffen, deshalb versuche ich es ja mit dem Befehl weiter unten.
Jedes Programm ist dann ein Konsolenprogramm, denn jeder Prozeß hat eine Standardeingabe, eine Standardausgabe und eine Standardfehlerausgabe. Es kann natürlich sein, daß das Programm ein Teil davon oder alles nicht nutzt.
Ok, Du willst mich nicht verstehen,
Ich verstehe es wirklich nicht.
Doch inzwischen hast Du es weiter unten gelesen ;-)
sondern mir etwas über stdin, stdout und stderr beibringen. Ich möchte aber kein Script basteln das über 40 Zeilen geht und alles mögliche umlenken muss.
Ich verstehe nicht, was Du willst. Du hast geschrieben, Du willst die Ausgabe umlenken. Aber das hat wirklich nichts damit zu tun, wie ein Programm beendet wird. Wenn Du z.B die Ausgabe von mutt umlenkst, dann hast Du noch lange nicht die Eingabe umgelenkt. Und um etwas umzulenken brauchst Du keine 40 Zeilen, das macht man in einer.
Nein, der 1. Ansatz war das Programm in ein laufendes x-terminal zu holen. Das finde ich aber zu umständlich. Ok, wenn der andere Ansatz nicht zu verwirklichen ist dann muss ich wohl stdin, stdout und stderr umlenken. *seufz*
Habe ich geschrieben, Du muß Standardausgabe, -eingabe und auch -fehlerausgabe auf einen Bildschirm umlenken. Bei Unix/Linux verhält sich ein Bildschirm nicht anders als eine Datei. Mit programm > datei schreibst Du die Ausgabe in die Datei datei und mit programm > /dev/tty4 schreibst Du die Ausgabe auf die virtuelle Konsole 4
Hmmm und wie schreibe ich das auf ein laufendes x-terminal ?
Das ganze muss ich doch nicht extra umlenken, wenn das Programm sofort in einer Konsole startet.
Wenn Du eine interaktive shell hast, dann ist schon ein stdin, stdout und stderr definiert, der Prozeß, der durch Aufruf eines Programms ausgelöst wird, übernimmt dieser Prozeß diese Teile. Wenn Du aber nicht von einer shell aus aufrufst, dann kann der Prozeß ja auch dies nicht übernehmen, weil sie nicht definiert sind.
konsole -e "/usr/bin/edonkeyclc" -g
Ist es denn durch diesen Aufruf definiert, oder sollte ich dem "konsole" noch einen Befehl voran stellen ? Es wäre echt cool wenn jemand etwas zum lesen hätte, wo genauso etwas vorkommt. Google bringt zwar ne Menge für Cron und auch für x-terminals aber nichts mit so einem Aufruf.
Moment, ich ging davon aus, daß Du mit Konsole die virtuellen Konsolen meinst, das sind die Teile, die Du mit ALT-CTRL-F1 bis ALT-CTRL-F6 erreichst. Aber im Prinzip ist es egal. Auch bei diesen x-terminals ist es eigentlich genauso.
würde das ja eigentlich machen. Nur kommt da eine aufpoppende Konsole die sich nach 1 Sekunde mit Signal 1 wieder verabschiedet.
Weil die Konsole geschlossen wurde, dann verschickt sie an alle Prozesse wo sie die kontrollierende Konsole ist, das Signal 1. Warum die Konsole geschlossen wurde, weiß ich nicht, ich kenne mich mit den Dinger nicht aus.
Das Warum, wäre im Moment auf jeden Fall das interessanteste.
Also denke ich mir das die letzte Option -g daran schuld ist, da die Konsole sich vermutlich mit der Option angesprochen fühlt. Oder dann die andere Frage, warum verabschiedet sich die Konsole nach 1 Sekunde wieder mit Signal 1 ?
Keine Ahnung. Wenn ich sowas brauche, verwende ich xterm. Ansonsten benutze ich die virtuellen Konsolen.
Du hast mich auf jeden Fall ein Stückchen näher gebracht, danke Bernd. Gruss Thomas
Am Samstag, 12. Februar 2005 11:28 schrieb Thomas Janssen:
Am Samstag, 12. Februar 2005 10:58 schrieb Bernd Brodeßer:
Am Samstag, 12. Februar 2005 10:34 schrieb Thomas Janssen:
Am Freitag, 11. Februar 2005 23:23 schrieb Bernd Brodeßer:
Am Freitag, 11. Februar 2005 22:08 schrieb Thomas Janssen:
Am Freitag, 11. Februar 2005 21:49 schrieb Bernd Brodeßer:
Am Freitag, 11. Februar 2005 18:51 schrieb Thomas Janssen:
Was ist Quit? Das Programm kenne ich nicht.
Die Funktion "Quit" - "Beenden" eines Programmes. Ich denke das kennst Du sehr wohl. Da ich kein Programmierer bin, kann ich nicht sagen ob das ein kill auslöst.
Du meinst einfach das Ende eines Programms. Ok, was soll da gemacht werden? Gar nichts wird da gemacht. Natürlich kann es sein, daß da noch irgendwas aufgeräumt ist, aber das ist Teil des Programms. Wenn man ein kill eingibt, dann wird normalerweise ein Programm ab diesen Punkt einfach beendet. Wenn es aber nochwas aufzuräumen gibt, so wäre es ein schlechter Programmierstil, wenn ein normales kill oder auch ein kill -2 usw. nicht abgefangen würde. Üblich ist, daß z.B ein kill -2 was exakt das Gleiche ist wie ein CTRL-C, abgefangen wird, dann noch was aufgeräumt und dann sich das Programm beendet. Aber wenn der Programmierer das nicht programmiert hat, dann passiert natürlich nichts.
Der Programmierer hat leider nichts implementiert. Das bedeutet das Programm macht per kill (egal welche Zahl) die Grätsche und ist beim nächsten Start erstmal 15 Minuten damit beschäftigt die MD5-Summen erneut zu berechnen.
Du meinst Standardeingabe, Standardausgabe und Standardfehlerausgabe? Wenn man es nicht umlenkt, dann auf der Konsole von der man es aus startet. Ganz normales verhalten.
Das meine ich, das normale Verhalten.
Ja, und? Wenn Du das so machst, wie Du beschrieben hast, dann ist aber den Prozessen kein Bildschirm zugeordnet. welcher den auch?
Das habe ich inzwischen auch begriffen, deshalb versuche ich es ja mit dem Befehl weiter unten.
Jedes Programm ist dann ein Konsolenprogramm, denn jeder Prozeß hat eine Standardeingabe, eine Standardausgabe und eine Standardfehlerausgabe. Es kann natürlich sein, daß das Programm ein Teil davon oder alles nicht nutzt.
Ok, Du willst mich nicht verstehen,
Ich verstehe es wirklich nicht.
Doch inzwischen hast Du es weiter unten gelesen ;-)
sondern mir etwas über stdin, stdout und stderr beibringen. Ich möchte aber kein Script basteln das über 40 Zeilen geht und alles mögliche umlenken muss.
Ich verstehe nicht, was Du willst. Du hast geschrieben, Du willst die Ausgabe umlenken. Aber das hat wirklich nichts damit zu tun, wie ein Programm beendet wird. Wenn Du z.B die Ausgabe von mutt umlenkst, dann hast Du noch lange nicht die Eingabe umgelenkt. Und um etwas umzulenken brauchst Du keine 40 Zeilen, das macht man in einer.
Nein, der 1. Ansatz war das Programm in ein laufendes x-terminal zu holen. Das finde ich aber zu umständlich. Ok, wenn der andere Ansatz nicht zu verwirklichen ist dann muss ich wohl stdin, stdout und stderr umlenken. *seufz*
Habe ich geschrieben, Du muß Standardausgabe, -eingabe und auch -fehlerausgabe auf einen Bildschirm umlenken. Bei Unix/Linux verhält sich ein Bildschirm nicht anders als eine Datei. Mit programm > datei schreibst Du die Ausgabe in die Datei datei und mit programm > /dev/tty4 schreibst Du die Ausgabe auf die virtuelle Konsole 4
Hmmm und wie schreibe ich das auf ein laufendes x-terminal ?
Wenn Du tty eingibst, wird das Gerät ausgegeben. Ich habe hier sowas wie /dev/pts/3, wobei natürlich die letzte Zahl variiert. Bernd
Am Samstag, 12. Februar 2005 13:25 schrieb Bernd Brodeßer:
Am Samstag, 12. Februar 2005 11:28 schrieb Thomas Janssen:
[..........]
Hmmm und wie schreibe ich das auf ein laufendes x-terminal ?
Wenn Du tty eingibst, wird das Gerät ausgegeben. Ich habe hier sowas wie /dev/pts/3, wobei natürlich die letzte Zahl variiert.
Ich habs jetzt soweit am laufen mit folgendem Script: #!/bin/bash if pidof edonkeyclc > /dev/null ; then exit else "/usr/bin/edonkeyclc" -g > /dev/pts/0 fi Einziges Problem ist noch das jetzt laufend zwischen den Ausgaben des Programmes >>>>>>>>>>>>>>>>>>>>>>>>>>> <-- diese Zeichen ausgegeben werden. Wie kommen die denn zustande, oder kann ich dagegen noch etwas machen ? Gruss Thomas
Thomas Janssen wrote:
#!/bin/bash
if pidof edonkeyclc > /dev/null ; then exit else "/usr/bin/edonkeyclc" -g > /dev/pts/0 fi
Was sollen eigentlich in allen Deinen Beispielen die Anführungszeichen um den Pfad herum? In einem Skript sind die schlicht überflüssig und bei einem Aufruf wie xterm -e "/path/to/program" müssen Parameter für program natürlich ebenfalls in den durch "" eingeschlossenen Teil hinein, in Deinem Fall also xterm -e "/usr/bin/edonkeyclc -g". Martin
Am Samstag, 12. Februar 2005 16:54 schrieb Martin Schmitz:
Thomas Janssen wrote:
#!/bin/bash
if pidof edonkeyclc > /dev/null ; then exit else "/usr/bin/edonkeyclc" -g > /dev/pts/0 fi
Was sollen eigentlich in allen Deinen Beispielen die Anführungszeichen um den Pfad herum? In einem Skript sind die schlicht überflüssig und bei einem Aufruf wie xterm -e "/path/to/program" müssen Parameter für program natürlich ebenfalls in den durch "" eingeschlossenen Teil hinein, in Deinem Fall also xterm -e "/usr/bin/edonkeyclc -g".
Und genau so geht es nicht. Wenn die Parameter auch mit hinein müssten, dann dürfte es jetzt wohl nicht funktionieren. Tut es aber. Und wenn der Parameter mit drin ist, funktioniert es nicht. Hast du noch irgendwas zu meiner Frage mit den >>>>>> Zeichen zu sagen ? Gruss Thomas
Hallo, Am Sat, 12 Feb 2005, Thomas Janssen schrieb:
Am Samstag, 12. Februar 2005 13:25 schrieb Bernd Brodeßer: [..]
Wenn Du tty eingibst, wird das Gerät ausgegeben. Ich habe hier sowas wie /dev/pts/3, wobei natürlich die letzte Zahl variiert.
Ich habs jetzt soweit am laufen mit folgendem Script:
#!/bin/bash
if pidof edonkeyclc > /dev/null ; then exit else "/usr/bin/edonkeyclc" -g > /dev/pts/0 fi
Das halte ich fuer keine gute Idee, du solltest schon ein eigenes X Terminal aufmachen. s.u.
Einziges Problem ist noch das jetzt laufend zwischen den Ausgaben des Programmes >>>>>>>>>>>>>>>>>>>>>>>>>>> <-- diese Zeichen ausgegeben werden.
Wie kommen die denn zustande, oder kann ich dagegen noch etwas machen ?
Das macht evtl. das Programm selbst. Liesse sich aber evtl. rausgreppen, was aber die Ausgabe verzoegert. Ich schlage dir folgendes vor: ==== Script start-edonkeyclc [oder so] ==== #!/bin/sh pidof edonkeyclc >/dev/null && exit 0 exec /usr/bin/edonkeyclc -g ==== Mit 'if pidof ...; then exit; else exec ...; fi' geht's auch. Start mit: xterm -T "EDonkey Xterm" -e start-edonkeyclc Auch mit 'konsole' sollte es so klappen: konsole -T "EDonkey Konsole" -e start-edonkeyclc So bekommt das script und damit auch 'edonkeyclc' die Dateideskriptoren vom xterm und du musst die Ein- und Ausgaben nicht per Hand umleiten. HTH, -dnh --
Ich habe das ausprobiert, aber wenn ich das auf yes stelle dann stürzt der PC beim Booten ab. Was Nun? Dann stell es am besten wieder auf "no". -- Betrefflose Frage und Antwort in suse-linux
Hallo Am Samstag, 12. Februar 2005 17:22 schrieb David Haller:
Am Sat, 12 Feb 2005, Thomas Janssen schrieb:
Das halte ich fuer keine gute Idee, du solltest schon ein eigenes X Terminal aufmachen. s.u.
Ok.
Einziges Problem ist noch das jetzt laufend zwischen den Ausgaben des Programmes >>>>>>>>>>>>>>>>>>>>>>>>>>> <-- diese Zeichen ausgegeben werden.
Wie kommen die denn zustande, oder kann ich dagegen noch etwas machen ?
Das macht evtl. das Programm selbst. Liesse sich aber evtl. rausgreppen, was aber die Ausgabe verzoegert.
So wichtig ist es dann auch wieder nicht. Damit kann ich leben.
Ich schlage dir folgendes vor:
==== Script start-edonkeyclc [oder so] ==== #!/bin/sh pidof edonkeyclc >/dev/null && exit 0 exec /usr/bin/edonkeyclc -g ====
Mit 'if pidof ...; then exit; else exec ...; fi' geht's auch.
Start mit:
xterm -T "EDonkey Xterm" -e start-edonkeyclc
Auch mit 'konsole' sollte es so klappen:
konsole -T "EDonkey Konsole" -e start-edonkeyclc
So bekommt das script und damit auch 'edonkeyclc' die Dateideskriptoren vom xterm und du musst die Ein- und Ausgaben nicht per Hand umleiten.
Das Du Ein Fux bist hat man Dir ja schon des öfteren mal mitgeteilt ;-) Hoffentlich wird es jetzt nicht peinlich, aber.. Wenn ich versuche ein Xterm zu öffnen dann klappt das. Versuche ich das selbe mit der Option -e (nur per Script) bekomme ich eine Fehlermeldung die mir über root zugesandt wird: xterm Xt error: Can't open display: Dem entsprechend klappt auch der Cronjob nicht. Der Cronjob läuft als normaler User. <schnipp> crontab -l # DO NOT EDIT THIS FILE - edit the master and reinstall. # (/tmp/kde-thommyus/kcron5RgGzb.tmp installed on Sun Feb 13 08:16:28 2005) # (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $) # Woechentliches Antispam 0 3 * * 7 /home/..../..../..../cron_antispam.sh # Overnet restart -0,5,10,15,20,25,30,35,40,45,50,55 * * * * /home/..../..../..../overnet-restart-david.sh # This file was written by KCron. Copyright (c) 1999, Gary Meyer # Although KCron supports most crontab formats, use care when editing. # Note: Lines beginning with "#\" indicates a disabled task. <schnapp> Ich hab auch schon versucht env=DISPLAY:0 mit auf den Weg zu geben.. Fruchtlos.. Irgendwas übersehe ich wohl noch. Gruß Thomas
Hallo, Am Sun, 13 Feb 2005, Thomas Janssen schrieb: [..]
Hoffentlich wird es jetzt nicht peinlich, aber.. Wenn ich versuche ein Xterm zu öffnen dann klappt das. Versuche ich das selbe mit der Option -e (nur per Script) bekomme ich eine Fehlermeldung die mir über root zugesandt wird:
xterm Xt error: Can't open display:
Dem entsprechend klappt auch der Cronjob nicht. Der Cronjob läuft als normaler User.
Oh, das hatte ich vergessen.
<schnipp> crontab -l [..] # Overnet restart -0,5,10,15,20,25,30,35,40,45,50,55 * * * * /home/..../..../..../overnet-restart-david.sh # This file was written by KCron. Copyright (c) 1999, Gary Meyer # Although KCron supports most crontab formats, use care when editing. # Note: Lines beginning with "#\" indicates a disabled task. <schnapp>
Ich hab auch schon versucht env=DISPLAY:0 mit auf den Weg zu geben.. Fruchtlos..
Folgendes funktioniert bei mir: ==== /home/dh/bin/test_xterm.sh ==== #!/bin/sh export DISPLAY=:0 exec /usr/X11/bin/xterm -e /usr/bin/less "$0" ==== Der crontab Eintrag: */5 * * * * /home/dh/bin/test_xterm.sh HTH, -dnh -- Da Ihre Web-Seite wohl nur den IE akzeptiert, wollte ich anfragen, ob dieses auch mit anderen Browsern irgendwie möglich ist, oder ob Sie mir, wenn nicht, eine WindowsCD kostenlos zukommen lassen können um Ihr Angebot wahrzunehmen. -- Axel Lindlau
Hallo Am Sonntag, 13. Februar 2005 16:59 schrieb David Haller:
Am Sun, 13 Feb 2005, Thomas Janssen schrieb:
Folgendes funktioniert bei mir:
==== /home/dh/bin/test_xterm.sh ==== #!/bin/sh export DISPLAY=:0 exec /usr/X11/bin/xterm -e /usr/bin/less "$0" ====
Der crontab Eintrag:
*/5 * * * * /home/dh/bin/test_xterm.sh
Das Script funktioniert. Danke David. Das es trotzdem nicht klappt liegt scheinbar an dem Programm edonkeyclc. Das xterm geht auf, ich sehe ungefähr für eine halbe Sekunde die ersten Ausgaben des Programmes und schwupp, weg ist das Term. Wenn ich das ganze z. Bsp. mit top starte, statt edonkeyclc, läuft es. Ich werde es mal mit strace aufrufen und sehen ob ich noch irgendwas rausfinde. Danke an alle die geholfen haben. Gruß Thomas
Am Freitag, 11. Februar 2005 22:08 schrieb Thomas Janssen:
Am Freitag, 11. Februar 2005 21:49 schrieb Bernd Brodeßer:
Am Freitag, 11. Februar 2005 18:51 schrieb Thomas Janssen:
Mein Problem ist jetzt, wenn ich es nun kontrolliert beenden möchte (nicht per kill),
Was spricht gegen kill?
Ist ein Quit in einem Programm und ein Kill das selbe ? Ich denke nicht. Mit dem Quit werden zuerst noch alle offenen Dinge(tm) beendet und gespeichert. Mit kill auch ?
Klar. Kill killt auch "softly" kill -3 (-pid) ö.ä. "info kill" Gruß Harald
Hallo Thomas, hallo Liste, Am Fr, 2005-02-11 um 18.51 schrieb Thomas Janssen:
Hallo Listige
...
Mein Problem ist jetzt, wenn ich es nun kontrolliert beenden möchte (nicht per kill), könnte ich das nur in einer Konsole. Doch da taucht das Teil nicht auf. Jobs bringt keine Ausgabe. Gibt es eine
versuche es mal mit der folgenden Zeile: ps -e | grep <Programmname> da bekommst du die Prozesse und die PID's Wenn du nur den Programmnamen kennst, kannst du auch killall <Programmname> eingeben, hierbei wird der Prozess und alle Unterprozesse beendet.
Möglichkeit zum Beispiel an Hand der PID (die kriege ich per Top) die Ausgabe des Programmes irgendwie in (m)eine Konsole zu bekommen. Oder sollte ich mein Script abändern das ich die Ausgabe des Programmes (und dadurch den Zugriff) in der Konsole haben kann. Wenn ja, dann wie ? Gegoogelt habe ich auch, glaube aber nicht die ...
Gruß Jürgen
participants (7)
-
Bernd Brodeßer -
David Haller -
Harald_mail＠t-online.de -
Juergen Stahl -
Martin Schmitz -
Peter Wiersig -
Thomas Janssen