per crontab ausgeführte Scripts in Terminal anzeigen

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo Leute,

    einer meiner Raspberrys soll auf einem Modellflugplatz solarbetrieben Webcambilder hochladen und eine USB-Wetterstation auslesen und deren Daten hochladen. Alles per UMTS/GPRS.

    Das klappt auch alles schon einigermaßen gut. Aber ich bin noch am debuggen - daher auch meine Frage:

    Kann ich - und wenn ja, wie - im Terminal anzeigen lassen welche Aktivitäten grade im Hintergrund laufen?

    Ich führe per Crontab einige (6) Scripte per Bash aus. Zu unterschiedlichen Zeiten/ Intervallen.
    Nun kann ich aber nicht sehen ob alles gut geht oder nicht. Daher würde ich gerne sehen was da los ist.
    Wenn ich die Scripte manuell per Terminal starte sehe ich dass, was ich gerne sehen möchte.
    Oh mann, ist meine Frage verständlich?

    Per top und htop sehe ich ja was grade läuft - aber nur den Prozess, nicht was der Prozess grade macht.

    Danke für eure Hilfe!

    Gruß
    David

  • per crontab ausgeführte Scripts in Terminal anzeigen? Schau mal ob du hier fündig wirst!

  • Danke!
    Ja, so habe ich mir momentan auch geholfen.
    Ich schreibe was das script macht und die returnwerte in ein log.txt
    Aber eine "echtzeit-Ausgabe" auf einem 128x64 pix Display wäre das Ziel der Übung.

    Gruß

    David

  • Ah, da komme ich der Sache schon näher :) Danke!

    Siehst du eine Möglichkeit nach einem Reboot automatisiert ein offenes Terminalfenster mit >tail -f log.txt< zu starten?

    Danke Nochmals,

    David


  • Kann ich - und wenn ja, wie - im Terminal anzeigen lassen welche Aktivitäten grade im Hintergrund laufen?

    Ich führe per Crontab einige (6) Scripte per Bash aus. Zu unterschiedlichen Zeiten/ Intervallen.
    Nun kann ich aber nicht sehen ob alles gut geht oder nicht. Daher würde ich gerne sehen was da los ist.
    Wenn ich die Scripte manuell per Terminal starte sehe ich dass, was ich gerne sehen möchte.

    Ich weiss nicht genau ob die bisherigen Antworten für deine Frage passend sind oder ob ich deine Frage falsch verstehe, deshalb mal ein paar Fragen:

    1) Möchtest du nachträglich sehen was die Scripts ausgeben (also ein Logfile betrachten)
    2) Oder möchtest du überprüfen ob die Scripts ausgeführt wurden, wenn ja wann zuletzt
    3) Oder möchtest du prüfen 'ob' ein Script aktuell ausgeführt wird?

    Um was für Scripts handelt es sich überhaupt? Also was machen die genau? Werfen die irgendwas aus? Jedes etwas anderes?

  • Ich noch keine Zeit gefunden auf "screen" einen Blick zu werfen, vielleicht ist es schon genau das was ich suche.

    Um die Fragen von meigrafd zu beantworten:
    Eines der Scripte speichert einen Frame vom Video0, versieht diesen mit einem Overlay und läd das Bild per FTP auf einen Server.
    Ein weiteres Script liest daten einer USB-Wetterstation aus (mit pywws) verwurstet die zu einem txt mit dem mein PHP auf dem externen Server umgehen kann und läg es auf selbigen hoch.
    Ein weiteres Script überwacht die Internetverbindung. Die ist am Aufstellort mehr als schlecht und immer mal wieder unterbrochen. Ich pinge also alle 10min googles -DNS-Server an. Bekomme ich keine Antwort versucht das script einen reconnect per wvdial. Scheitert dies schalte ich die USB-Spannung vom UMTS-Stick weg (Per PiFace Digital-Ausgang/ Ralais) und versuche einen weiteren reconnect. Scheiter dies auch - reboot.
    Dann noch ein script um das Logfile ab und an auf einen FTP zu laden. Und eines um die Temperatur vom Pi zu lesen und ggf per PiFace einen Lüfter ein zu schalten. (Wird im sommer sehr warm in der Hütte)

    So, nun hätte ich gerne Informationen welche scripts grade aktiv sind und wo die Verarbeitung grade ist.
    Möglichst "live". In das Logfile schreibe ich schon Sätze wie "$Timestamp Captureing Picture" Oder "$Timestamp Temperatur >50°C starte Lüfter" Oder "Network unreachable - reconnect".
    Diese Informationen möchte ich dann im nächsten Schritt auf einem 128x64pix Display ausgeben. Damit wäre meine kleine Box dann komplett. Ach ja - die Eingangspannung wird später noch mittels A/D-Wandler gemessen und geloggt.

    Ich hoffe mein Vorhaben ist nun etwas klarer geworden.

    Danke!

    David

  • Also ich verstehe unter dem was du erst beschreibst etwas anderes als dem was du am Ende beschreibst :D

    1. Aussage:

    So, nun hätte ich gerne Informationen welche scripts grade aktiv sind und wo die Verarbeitung grade ist.

    2. Aussage:

    Möglichst "live". In das Logfile schreibe ich schon Sätze wie "$Timestamp Captureing Picture" Oder "$Timestamp Temperatur >50°C starte Lüfter" Oder "Network unreachable - reconnect".
    Diese Informationen möchte ich dann im nächsten Schritt auf einem 128x64pix Display ausgeben.

    screen ist denk ich nicht wirklich das wonach du suchst - das wäre nur fürs Anzeigen der Logs nützlich... Also im Prinzip erzeugt "screen" eine Shell die im Hintergrund weiter läuft auch wenn du die Verbindung trennst - verbindest du dich erneut kannst du mit "screen -x" in eine zuvor gestartete Session wieder einsteigen und siehst dann ein Befehl oder Programm was zuvor gestartet wurde...

    Da du aber 6 Scripts über crontab laufen hast die eben Zeitgesteuert Dinge erledigen, ist halt die Frage ob du einfach nur die Logs von den Scripts sehen möchtest oder tatsächlich beobachten ob ein Script gerade läuft oder wann es zuletzt gelaufen is usw...

    Schreiben die Scripts denn alle in das selbe Logfile oder hat jedes Script sein eigenes Logfile?
    Wenn letzteres könntest du zB folgendes machen um über einen einzigen Befehl verschiedene Logfiles in (beinahe) Echtzeit auszugeben:

    Code
    tail -f {/var/log/syslog,/var/log/apache2/access.log}

    Oder du schreibst ein weiteres Script welches sich im Kreis dreht und die Prozess-Liste ( ps aux ) regelmässig überprüft ob ein bestimmtes Script/Programm ausgeführt wird und gibt das dann aus - sowas könnte man auch mithilfe AJAX in Form einer Webseite realisieren


    ..Aber wie gesagt - ich bin jetzt leicht verwirrt was du eigentlich genau haben möchtest :huh:

  • Sorry aber die Aussagen "mit screen geht das" reicht wie ich finde nicht

    screen alleine zeigt aber nicht einfach so irgendwelche Sachen an die von crontab (cronjob) ausgeführt werden - dazu muss man auch einen Befehl eingeben und genau da fängt es an ob 1) oder 2) ... Also entweder Logfile beobachten (zB was CRON macht) oder Prozessliste beobachten ... Oder die/das Logfile der Scripts beobachten

  • Zitat


    [font="Tahoma, Verdana, Arial, sans-serif"]PS: Dein Cronjob müsste dann aber so aussehen: sudo su pi -c "screen -S main -X stuff $'ls -l\n'"[/font]

    Der Befehl schickt den ein ls -l an die Screen-Session main.

    Wenn man sich zum Debuggen ebenfalls in main eingeloggt hat. Sieht man nun das ls-l ausgeführt wird und auch die Ausgabe. Man kann so den cronjob qusi beim ausführen zuschauen.

  • Ob "less" oder "tail -f" ist denk ich beinahe wurscht ;)

    "tail -f {/var/log/syslog,/var/log/apache2/access.log}" zeigt eben auch jedes mal an aus welchem Logfile die nachfolgenden Zeilen stammen..
    Ich persönlich fände unterschiedliche Logs gut - oder eben in jedes Script ein Prefix einbauen damit man am Zeilenanfang erkennen kann um welches Script es sich bei der Ausgabe handelt (einfach nur "Error: bla" reicht dann nämlich nicht um zu wissen um welches Script es sich dabei handelt)


    Aber wie gesagt - man kann auch ein Script nutzen um sich eine inviduelle "ps aux" Liste zu erstellen, das ginge auch mit "top" oder "htop", um nur Sachen aus einem bestimmten Verzeichnis anzuzeigen usw dann sähe man auch ob ein Script gerade läuft usw


    Bjoern: Ein "ls -l" Zeigt keine Ausführungen von CRON an sondern Listet nur die Dateien/Verzeichnisse des aktuellen pwd's (also verzeichnis in dem man sich befindet) ...


  • Ob "less" oder "tail -f" ist denk ich beinahe wurscht ;)


    Jein, Less ist fuer interaktive Untersuchungen besser geeignet als tail (mal eben zurueckspringen im Log und was suchen etc). Im konkreten Fall ist tail aber wohl besser um einfach die Logs zu beobachten.

    Ich denke es liegen zwei Ansaetze vor:

    1) Der mit Screen erlaubt gezielt einzelne Screens in denen die cron Taks laufen zu beobachten.
    2) Der mit tail erlaubt alles zusammen zu beobachten.

    Die Frage ist was der TE sich vorstellt.

  • Moin Leute, und ein frohes neues Jahr wünsche ich!

    Ich denke ich bin dank euch nun auf dem richtigen Weg.
    Sorry, es ist nicht so ganz einfach für mich klar meine Vorstellungen zu formulieren da ich noch sehr frisch im Umgang mit Linux bin und daher auch nicht recht weiß was überhaupt möglich ist.

    Also die Sache mit dem Ausgeben des logfiles ist schon OK. Mir schwebte anfangs vor alle Rückgaben die ich so von einem Script erhalte wenn ich es manuell starte aus zu geben. Um es zu verdeutlichen:
    Ich starte also in der Konsole per bash mein script zum Verbinden per UMTS. Dieses führt un einen Befehl an wvdial mit einigen Übergabeparametern aus.
    Ich sehe in der Konsole diverse Informationen vom wvdial wie:
    --->Sending ATDT*99***1#
    --->Waiting for carrier.
    etc.
    DIESE Ausgaben habe ich gehofft auch irgendwo sehen zu können wenn wvdial nun per Cronjob angestoßen ist.
    Die "Hilfskrücke" mit dem Logfile (habe übrigens ein einziges Logfile für alle Scripts die ich zeilenweise mit Präfix unterscheide) erlaubt mir eben nicht besonders detailiert zu debuggen. Ich werde so beispielsweise nur sehen ob eine Verbindung zu Stande kam oder nicht. Den Grund fürs Scheitern sehe ich nicht. (Beispiel).

    Nun ist natürlich noch abzuwägen ob ich das Log so detailiert haben muss. Ich denke nicht zwingend.
    Also - bleiben wir beim Logfile. Ich zeige es nun an indem ich mir im LX-Terminal (Muss noch dazu sagen, dass ich auf den Desktop starte) per tail -f das log "live" an.

    Kann ich diesen Schritt noch automatisieren? Z.B. als Cronjob: @reboot starte offene Terminalbox mit tail -f logfile.txt

    Ich kann auch gut und gerne auf den Desktop verzichten und in der Konsole starten (wäre neu für mich aber damit komme ich klar).

    An dieser Stelle schon mal ein Dankeschön! Bin schon ein Stück weiter. Ich habe nicht mit so reger Beteiligung gerechnet und bin positiv überrascht von dem Forum hier.

    Danke!

    David

  • Das liegt dann aber daran das du das Scheitern im Script nicht echo'st, du also keine Überprüfung eingebaut hast die dann auch etwas ins Logfile schreiben würde...

    Einfacher wäre es denk ich - anstatt nun überall entsprechende Überprüfungen sowie Ausgaben ins Log einzubauen - allgemein deine seperat eingebaute Ausgabe in ein Logfile zu deaktivieren und beim Starten des Script einfach festzulegen das sowohl stdout als auch stderr in eine Datei umgeleitet werden soll.. Dann würden sowohl normale Ausgaben des Scripts als auch Fehler (zB weil ein Befehl nicht funktionieren wollte oder weil das Script nicht mit "exit 0" beendet wurde) beides in einem Logfile landen..

    Allerdings hätte diese Lösung auch ein paar Nachteile:

    • Du kannst Fehler nicht mehr zB anhand eines Prefix's unterschieden. Es wäre dann also besser wenn du für jedes Script ein eigenes Logfile anlegst und dann besagten tail -f Befehl zum ausgeben mehrere LogDateien verwendest, Aber:

      • Das hätte ebenfalls einen Nachteil und zwar die möglicherweise rasant steigende Dateigröße sowie die steigende Belastung des Mediums (ständiges schreiben). Man müsste also ggf in den Scripts auch eine Überprüfung der Dateigrösse von der Umleitung einbauen sodass das Logfile ab einer bestimmten Größe (am Ende des Scripts) gelöscht wird.. Ausserdem sollte man den Speicherort der Logfiles in ein tmpfs legen damit diese im RAM lägen und keine Schreibzugriffe auf der SD erzeugen da diese nicht unendlich viele verträgt (schont also das Systemlaufwerk)

    Eine solche Umleitung sähe dann zum Beispiel so aus:

    Code
    /path/to/script.sh >/path/to/logfile.log 2>&1

    1 = stdout
    2 = stderr

    Es wird also stderr auf den selben Kanal wie stdout umgeleitet und der standard Kanal stdout wird nach /path/to/logfile.log umgeleitet

    Mehr zum Thema Umleitung kannst du hier nachlesen: http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-3.html


    Oder du machst dir eben die Mühe in deine Scripts entsprechende Überprüfungen einzubauen - das wäre auch machbar und nicht soooo schwer (ich kenne aber deine Scripts aber nicht von daher kA. Wenn du vor hast die Scripte zu posten dann bitte in Kode, so wie ich es nachfolgenden auch aufzeige). Dazu kann ich dir ein Beispiel geben wie das aussehen könnte:


    Oder du machst eine Kombination von beidem - also du machst eine Umleitung von stderr in die selbe Datei wohin du auch deine normalen Log Geschichten hin echo'st Und anschliesend öffnest du eine screen Session und betrachtest dort deine Logfiles


    Die Lösung von Björn finde ich weiterhin nicht so gut da man dann vorher eine screen Session namens "main" gestartet haben muss ansonsten wird der Befehl (bzw das Script) nicht ausgeführt... Man müsste also ein Script bauen welches beim booten vor allen anderen ausgeführt wird und in dem eine Überprüfung stattfindet, ob bereits eine screen Session namens "main" läuft und falls nicht eine zu erzeugen - erst danach dürften die 6 anderen Script ausgeführt werden...
    Davon abgesehen ist "sh" älter als "bash" aber sh kann nicht so viel wie bash, also auch hier eine Fehlerquelle entstehen könnte wenn man auf sowas nicht achtet



    Nun ist natürlich noch abzuwägen ob ich das Log so detailiert haben muss. Ich denke nicht zwingend.
    Also - bleiben wir beim Logfile. Ich zeige es nun an indem ich mir im LX-Terminal (Muss noch dazu sagen, dass ich auf den Desktop starte) per tail -f das log "live" an.

    Kann ich diesen Schritt noch automatisieren? Z.B. als Cronjob: @reboot starte offene Terminalbox mit tail -f logfile.txt

    Du kannst automatisch beim booten eine Screensession starten, dann brauchst du später nur in diese Session hinein attachen.. Also zum Beispiel so:

    Code
    @reboot    /usr/bin/screen -dmS main /usr/bin/tail -f /path/to/logfile.txt

    Und in diese Session reattach'st du dann wie folgt:

    Code
    screen -x

    Beachten musst du hierbei aber das du nicht STRG+C in der Session drückst sonst wird die Session beendet - melde dich einfach ab oder schlies das Terminal, die Session läuft dann weiter..

    Ich kann auch gut und gerne auf den Desktop verzichten und in der Konsole starten (wäre neu für mich aber damit komme ich klar).

    Das wäre vermutlich besser da das dann auch wesendlich weniger CPU + RAM Last erzeugen würde ;)

  • Ich möchte lediglich diese Information einwerfen, wenn kmpec hat mehrfach nach einer Optopn gefragt bei anmelden direkt eine Aktion zu starten, das geht wahnsinnig ainfach ohne screen und ähnliches, indem man den auszuführenden Befehl in die ~/.bashrc schreibt. ALLES was in der .bashrc steht wird beim öffnen einer Shell (auch über ssh) ausgeführt. Normalerweiße kommt da daher nichts rein was ausgaben erzeugt oder sogar nicht automatisch beendet, aber in diesem Fall ist genau das ja gewünscht. Ein "less +F logfile" oder ein "tail --wie --von --meigraphd" Würde nach anmeldem am Pi automatisch ausgeführt und angezeigt werden.
    Ansonsten möchte ich auch darauf hinweißen, dass es nicht nur screen gibt, das ist für weiterlaufende Sessions, ich glaube eher hier ist ein nohup sinnvoll, das lässt das damit gestartete Programm weiterlaufen und lenkt die Ausgabe in ein eventuell angegebenes Logfile um. (Infos dazu mit "man nohup")
    Screen ist an vielen Stellen absolut oversized.
    Ansonsten wurden hier eine Menge sehr gute Informationen gegeben, die wie es aussieht auch schon gut geholfen haben.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!