Osmund schrieb:
>
1 | > @reboot /home/pi/sdt.py &
|
2 | > */5 * * * * /home/pi/sensor.py &
|
3 | >
|
Warum versetzt Du die Skripte mit '&' in den Hintergrund? Und was macht
der @reboot-Eintrag -- startet der etwa eine Art Server? Da wäre es
vermutlich sinnvoller, ein SysV-Initskript oder heutzutage besser ein
systemd Unitfile zu verwenden... oder, wenn man ein bisschen lustig
'drauf ist, so etwas wie supervisord, monit oder runit.
Was die Ausgabe der Skripte angeht... IMHO sollten Cron-Skripte nur dann
eine Ausgabe erzeugen, wenn etwas schiefgelaufen ist. Wenn erzeugte
Daten weitergegeben werden müssen, so ist es üblicherweise sinnvoller,
diese in einer Datei oder einer Datenbank (das muß natürlich keine
SQL-Datenbank, sondern kann auch etwas leichtgewichtiges wie Redis oder
etwas Fettes wie Elasticsearch sein) zu sichern -- oder die Mail direkt
aus dem Cron-Skript zu generieren und zu versenden. Letzteres bietet
dann auch den Vorteil, daß auch MIME-Mails mit Anhängen erzeugt werden
können.
So können auch mehrere Dateien zum Beispiel mit Binärdaten,
strukturierten Daten im JSON, YAML- oder CSV-Format, generierten
Grafiken und Ähnliches angehängt und auf einem passenden Mail User Agent
direkt dargestellt bzw. mit der richtigen Anwendung geöffnet werden. Für
bestimmte Zielgruppen können damit auch gleich reine HTML-E-Mails
(igitt) oder eine Kombination aus PlainText- und HTML-Mails erzeugt
werden, die dann (je nach MUA) gleich korrekt dargestellt werden. Für
Python gibt es für diese Aufgabe die Pakete email zum Erzeugen von
E-Mails, sowie smtplib für deren Versand.
Außerdem, wenn man schon mit einer Ausgabeumleitung arbeiten will: warum
dann nicht auf das eigens für solche Zwecke vorgesehene Programm
logger(1)? Das erzeugt dann auch gleich korrekte Zeitstempel im Log, und
es können Metainformationen wie Loglevel, -Facility und Tags und weitere
strukturierte Felder etwa für systemds journald mitgegeben werden. Und
da die Nachrichten im Syslog oder -Journal landen, wird auch ohne
weitere Konfiguration direkt korrekt rotiert...
Darüber hinaus besitzt Python zum Logging über ein sehr leistungsfähiges
Modul, das überraschenderweise auf den Namen "logging" hört. Und das
kann wirklich so ziemlich alles, was das Herz begehrt, natürlich auch
auf die standardmäßigen Logging-Mechanismen des zugrundeliegenden
Systems, also beispielsweise (r)syslog oder systemd loggen, aber auch
Lognachrichten via SMTP, HTTP(S) GET/POST, Sockets oder eine Message
Queue schreiben.
Ganz grundsätzlich ist ein Logging aber nicht für den Transport oder die
Speicherung von Daten gedacht, sondern für Lognachrichten, die die
Aufrufe, Zustände, Fehler und ggf. Performancedaten eines Systems und
der Prozesse dokumentieren. In Lognachrichten können zwar Daten
enthalten sein, sollten es aber nur dann, wenn sie zum Verständnis der
Lognachricht nötig sind. In allen anderen Fällen ist es keine gute Idee,
Daten über Loggingmechanismen zu transportieren und / oder zu speichern.
Schon alleine die Daten am Ende aus den Logdateien zu extrahieren, ...
wärgs! Viele Loggingsysteme sind auch ausgesprochen schlecht, wenn es um
mehrzeilige Nachrichten, binäre Daten und Ähnliches geht, und so
aufgeblasene Logdateien werden spätestens dann zum Problem, wenn ein
Monitoring genutzt werden soll.
Auch vor dem Hintergrund, daß Logdateien üblicherweise rotiert werden,
ist es keine gute Idee, Applikationsdaten darin zu speichern, denn die
werden natürlich am Ende der Rotation einfach verworfen. Wenn sie bis
dahin nicht aus den Lognachrichten extrahiert und anderweitig
gespeichert worden sind, dann sind die Daten... genau, hinfort! Das kann
zwar die Idee sein, muß es aber nicht... ;-)
Zuletzt, nur so als Hinweis: Python selbst bietet einen Scheduler in dem
Builtin-Modul "sched", und es gibt eine externe Bibliothek namens
schedule [1]. Wenn also eh ein langlaufender Serverprozeß gestartet
wird, benötigt man keinen Cron-Daemon, sondern kann eines dieser Module
verwenden und die notwendigen Arbeiten von dem langlaufenden Prozeß
ausführen lassen; das hat den Vorteil, daß man alles an einem Ort hat
und somit keine Abhängigkeiten, Synchronisierungen etc. unter seinen
Cron-Skripten beachten muß...
[1] https://github.com/dbader/schedule