Gelöst! Problem beim Skript ausführen mit ExecStartPost

[Nastra]

Hallo zusammen,

ich habe folgendes Problem mit einem Service der zwei Skripte ausführen soll. Beide Skripte liegen im Verzeichnis /usr/local/bin das erste Skript unter ExecStart wird ausgeführt und läuft. Das zweite Skript unter ExecStartPost welches anschließend ausgeführt werden soll wir leider nicht ausgeführt. Über das Terminal funktioniert das zweite Skript aber ohne Probleme.

Ich befürchte das ggf. was mit dem Pfad nicht stimmt. Habe einige Sachen ausprobiert, so viele das ich diese garnicht mehr alle aufzählen kann. Leider ohne Erfolg bisher. Als Rückmeldung habe ich verschiedene Nachrichten im Status gehabt von (code=exited, status=203/EXEC) bis (code=exited, status=127) etc.

Da ich ungern zwei Timer und zwei Service hierfür anlegen möchte "was funktioniert hat" hoffe ich das mir einer von euch weiterhelfen kann und mir sagt wo mein Fehler ist?

Hier meine Unit für den Service:

Code: Alles auswählen

Description=xxxxxx.service
Wants=network.target

[Service]
Type=oneshot


ExecStart=/bin/bash test1.sh
ExecStartPost=/usr/local/bin/test2.pl


[Install]
WantedBy=multi-user.target 

Vielen Dank im voraus!

Gruß Nastra

[NAB]

Da ich ungern zwei Timer und zwei Service hierfür anlegen möchte "was funktioniert hat"

Du meinst, wenn du zwei Units anlegst, eine mit:
ExecStart=/bin/bash test1.sh
und die andere mit:
ExecStart=/usr/local/bin/test2.pl
Dann funktioniert jede für sich? Das ist ja kurios ...

Für Type=oneshot darfst du ExecStart mehrmals angeben. Es müsste also so funktionieren:

ExecStart=/bin/bash test1.sh
ExecStart=/usr/local/bin/test2.pl

Aber ob das dieses merkwürdige Problem löst, weiß ich auch nicht.

[Nastra]

Hey NAB,

danke für die Antwort
Wenn ich ExecStart zweimal in der Unit angebe starten diese parallel oder nacheinander? Habe es oben vielleicht nicht richtig zum Ausdruck gebracht, mir wäre wichtig das die beiden Service hintereinander ablaufen daher hatte ich die ExecStartPost Funktion gewählt.

Du meinst, wenn du zwei Units anlegst, eine mit:
ExecStart=/bin/bash test1.sh
und die andere mit:
ExecStart=/usr/local/bin/test2.pl
Dann funktioniert jede für sich? Das ist ja kurios ...

Warum sollte das nicht funktionieren? Zwei getrennte Timer und zwei getrennte Service. Der eine hat die Start Zeit 20:00 Uhr mit Skript 1 der andere 20:05 Uhr mit Skript 2.

Ist halt primitiv gelöst

[NAB]

Wenn ich ExecStart zweimal in der Unit angebe starten diese parallel oder nacheinander? Habe es oben vielleicht nicht richtig zum Ausdruck gebracht, mir wäre wichtig das die beiden Service hintereinander ablaufen daher hatte ich die ExecStartPost Funktion gewählt.

Keine Ahnung, das sagt die Gebrauchsanleitung nicht so klar:
https://www.freedesktop.org/software/sy ... rvice.html
Ausprobieren?

Funktionieren die Scripte denn sonst, wenn du sie direkt nacheinander ausführst?

Code: Alles auswählen

sudo su
cd /
/bin/bash test1.sh; /usr/local/bin/test2.pl
exit

Warum sollte das nicht funktionieren?

Ich meinte das anders herum - es ist kurios, dass es nicht funktioniert, wenn du beide Scripte in eine Unit packst.

Nebenbei, /bin/bash test1.sh dürfte so oder so nicht funktionieren, weil bash keine Ahnung hat, wo es "test1.sh" findet, aber ich vermute, das ist nicht der wirkliche Befehl, den du ausführst.

[TomL]

Bei Type=oneshot muss '/bin/bash test1.sh' binnen 90 Sekunden nach dem Start der Unit durch systemd mit exit-Code 0 beendet werden. Wenn der Job länger läuft, muss er also geforkt werden. Ansonsten beendet/entfernt systemd diesen Job als "failed" und in diesem Fall wird die Post-Direktive natürlich nicht ausgeführt.

[Nastra]

Nebenbei, /bin/bash test1.sh dürfte so oder so nicht funktionieren, weil bash keine Ahnung hat, wo es "test1.sh" findet, aber ich vermute, das ist nicht der wirkliche Befehl, den du ausführst.

Genau so führe ich ihn in der Unit aus und es klappt, wenn ich denn vollständigen Pfad angebe funktioniert es nicht also usr/local/bin/bash Skript X
Wie sollte es ansonsten aussehen?

Für Type=oneshot darfst du ExecStart mehrmals angeben. Es müsste also so funktionieren:

ExecStart=/bin/bash test1.sh
ExecStart=/usr/local/bin/test2.pl

Habe ich gerade 3 mal ausprobiert, das funktioniert sogar so wie es aussieht führt er auch die einzelnen ExecStart nacheinander aus. Bei allen drei Test wurde mit dem ersten ExecStart eine Datei erzeugt und mit dem zweiten ExecStart diese versendet. Ich hoffe das es kein Zufall gewesen ist

Bei Type=oneshot muss '/bin/bash test1.sh' binnen 90 Sekunden nach dem Start der Unit durch systemd mit exit-Code 0 beendet werden. Wenn der Job länger läuft, muss er also geforkt werden. Ansonsten beendet/entfernt systemd diesen Job als "failed" und in diesem Fall wird die Post-Direktive natürlich nicht ausgeführt.

Hallo Tom sei gegrüßt ,
dir auch erstmal wieder ein Danke für deine Teinahme an meinem Problemchen

So wie ich bis jetzt verstanden habe ist meine Unit soweit in Ordnung da keiner was anderes behauptet hat. Wenn ich die Unit so verwende wie oben abgebildet wird das Skript bei ExecStart erfolgreich abgeschlossen bei ExecStartPost läuft er anschließend auf einen Fehler. Also dürfte das Problem nicht die Laufzeit sein oder doch?




Die Frage die ich mir jetzt stelle ob die Lösung mit der doppelten ExecStart Zeile so klar geht oder ob hier noch was zu beachten ist? Dachte eigentlich bzw. habe ich es so verstanden das die ExecStartPost genau für so einen Zweck gedacht ist?

Aber es vermutlich wie immer, mehrere Wege führen nach Rom

Noch eine zusätzliche Frage in die Runde, ist es eigentlich möglich einen Befehl den man im Terminal eingibt z.B. sudo xxxxxx auch direkt durch eine Unit auszuführen ohne Skript? Konnte da bisher nicht wirklich was zu finden

[NAB]

*seufz* ...

Bei Type=oneshot muss '/bin/bash test1.sh' binnen 90 Sekunden nach dem Start der Unit durch systemd mit exit-Code 0 beendet werden. Wenn der Job länger läuft, muss er also geforkt werden. Ansonsten beendet/entfernt systemd diesen Job als "failed"

Das ist mal wieder falsch.

Genau so führe ich ihn in der Unit aus und es klappt

Upps, stimmt, mir ist gerade wieder eingefallen, dass du ja sämtliche Scripte brav unter /usr/local/bin/ ablegst. Das liegt im Suchpfad, wo Bash nachguckt, wenn es einen Befehl nicht findet. Den Suchpfad kannst du dir übrigens angucken, mit:
echo $PATH

, wenn ich denn vollständigen Pfad angebe funktioniert es nicht also usr/local/bin/bash Skript X
Wie sollte es ansonsten aussehen?

Mönsch ... Nastra ... du haust manchmal Sachen raus ...
Natürlich funktioniert es so nicht. Auch du bewahrst deine Bash unter /bin/bash auf und nicht unter usr/local/bin/bash. Und ohne "/" am Anfang wäre das eh ein lokaler Pfad von "hier" aus.
Ich meinte sowas:
/bin/bash /usr/local/bin/test1.sh
(Den Pfad zu test1.sh habe ich eben geraten). Wie eben erklärt, klappt es auch ohne Pfad zum Script, aber mit wäre es eindeutig. Da gibt es nämlich ein kleines Problem: Nimm an, du nennst das Script wirklich /usr/local/bin/bash, was wird dann wohl ausgeführt, wenn du "bash" aufrufst?

Wenn du jetzt sagst "So nen Scheiß mach ich nicht!" ... mag sein. Aber ich habe immer noch im Hinterkopf, dass du deine Ergebnisse vielleicht veröffentlichen willst, und dann sollten sie einigermaßen idiotensicher sein.

Abgesehen davon ist $PATH veränderbar (recht leicht sogar). Den verändert man zwar nur, wenn man auf Ärger aus ist, aber manche Leute machen das, du hast also keine Garantie, dass /usr/local/bin/ auf allen Systemen im Suchpfad ist.

Habe ich gerade 3 mal ausprobiert, das funktioniert sogar so wie es aussieht führt er auch die einzelnen ExecStart nacheinander aus. Bei allen drei Test wurde mit dem ersten ExecStart eine Datei erzeugt und mit dem zweiten ExecStart diese versendet. Ich hoffe das es kein Zufall gewesen ist

Ach so, die beiden Scripte sind voneinander abhängig? Dann wäre ExecStartPost eigentlich genau richtig gewesen (wie du ja selber sagst). Hmm ... eventuell meldet das erste Script "fertig", aber die Datei ist noch nicht so ganz fertig geschrieben, sondern braucht noch ein paar Millisekunden ... das kann auf einer SD-Karte mal vorkommen. Aber das würde auch nicht erklären, warum es mit ExecStart geht und mit ExecStartPost nicht.

Ach, grad noch zu ExecStart gefunden:

If more than one command is specified, the commands are invoked sequentially in the order they appear in the unit file. If one of the commands fails [...], other lines are not executed, and the unit is considered failed.

Das ist zwar nicht so ganz eindeutig, kann aber eigentlich nur funktionieren, wenn Systemd mit dem nächsten ExecStart wartet, bis das erste sich (erfolgreich) beendet hat. Ich kann bisher für Type=oneshot keinen Unterschied zwischen ExecStart und ExecStartPost ausmachen.

Also so richtig trauen würde ich der Sache noch nicht ...

Noch eine zusätzliche Frage in die Runde, ist es eigentlich möglich einen Befehl den man im Terminal eingibt z.B. sudo xxxxxx auch direkt durch eine Unit auszuführen ohne Skript? Konnte da bisher nicht wirklich was zu finden

Kommt drauf an, wie das xxxxxx aussieht. Wenn das wirklich ein Befehl ist, dann ja - genau dazu wurde Systemd gemacht: ExecStart=/usr/bin/xxxxxx
Das sudo wäre dann überflüssig - Systemd startet den Befehl eh als root solange du nichts anderes angibst.

[Nastra]

Guten Morgen zusammen,

dass du ja sämtliche Scripte brav unter

Will es mir ja nicht schwerer machen als nötig

Mönsch ... Nastra ... du haust manchmal Sachen raus ...

Du weißt doch bei völliger Ahnungslosigkeit zumindest sicheres Auftreten oder wie war das

Wenn du jetzt sagst "So nen Scheiß mach ich nicht!" ... mag sein.

Hey ho, so funktioniert auch das ExecStartPost. Hatte ich mir doch gedacht das ich bei Pfad was falsch gemacht habe
ExecStart=/bin/bash /usr/local/bin/skript1.sh
ExecStartPost=/bin/bash /usr/local/bin/skript2.pl

Also so richtig trauen würde ich der Sache noch nicht ...

Jetzt kommt das beste, brauche denn zweiten Service glaube ich garnicht mehr, habe mich vorhin mal hingesetzt und probiert alles in ein Skript zu basteln was ich bisher an schnippeln aus dem netz gezogen habe, die ich für mein Vorhaben brauche.
Und tada das ding läuft sogar und macht was es soll! Amazing

@NAB Vielleicht kannst du ja nochmal drüber schauen ob es noch verbesserungsfähig ist oder ob ich es so lassen kann?

Hier eine kurze Beschreibung, was es machen soll:

1. Eine Zusammenfassung der LogDateien über die Software Logwatch
2. Log über Telegram versenden (Hier konnte ich leider ntfy nicht mehr nutzen da es dort keine Möglichkeit gibt eine Datei zu versenden, habe aber einen Weg gefunden direkt die Telegram API anzusprechen)
3. Logs die älter als x Tage sind löschen

Code: Alles auswählen

#!/bin/bash

#Log Zusammenfassung erstellen
sudo logwatch --detail high --range yesterday --format text --filename /home/pi/logwatch/`date`.txt

#Log Zusammenfassung versenden (Telegram Config)
day=$(date +%Y-%m-%d)
filename=/home/pi/logwatch/$day-logwatch.txt
token=<>
chat_id=<>

/usr/sbin/logwatch --output file --filename $filename
chmod 644 $filename
curl -F chat_id="$chat_id" -F document=@"/home/pi/logwatch/$day-logwatch.txt" https://api.telegram.org/bot$token/sendDocument >/dev/null 2>&1

#Log löschen die älter als +X Tage sind
find /home/pi/logwatch/* -mtime +1 -exec rm {} \;

[TomL]

Das ist mal wieder falsch.

Kann man so einen Blödsinn ernst nehmen, wenn eine Aussage als falsch bezeichnet wird, ohne auch nur den Versuch einer Richtigstellung zu unternehmen? Nein, kann man nicht!

Die Beschreibung zu oneshot zeigt, dass systemd nicht zulässt, die bootphase zu blockieren. Nach 90 Sekunden ist Schluss.

"Behavior of oneshot is similar to simple; however, it is expected that the process has to exit before systemd starts follow-up units. "

[NAB]

Hey ho, so funktioniert auch das ExecStartPost. Hatte ich mir doch gedacht das ich bei Pfad was falsch gemacht habe
ExecStart=/bin/bash /usr/local/bin/skript1.sh
ExecStartPost=/bin/bash /usr/local/bin/skript2.pl

Ja, huch? Das hätte ich nun nicht erwartet. Deine Script-Endung .pl ist auch sehr verwirrend, so nennt man eigentlich Perl-Scripte, und für die wäre /usr/bin/perl zuständig. Ich ging davon aus, dass dieses vermeintliche Perl-Script schon weiß, wie es gestartet wird ...

Das erklärt auch immer noch nicht, warum es mit zwei einzelnen Units ging.

Jetzt kommt das beste, brauche denn zweiten Service glaube ich garnicht mehr, habe mich vorhin mal hingesetzt und probiert alles in ein Skript zu basteln was ich bisher an schnippeln aus dem netz gezogen habe, die ich für mein Vorhaben brauche.

Na, das ist doch das beste ... wenn du selber anfängst rumzubasteln und zu experimentieren

@NAB Vielleicht kannst du ja nochmal drüber schauen ob es noch verbesserungsfähig ist oder ob ich es so lassen kann?

Gute Frage ... ich bin ja mal wieder erstaunt, was man mit Telegram so alles machen kann. Und "logwatch" kannte ich vorher auch nicht.

Ich verstehe nicht so ganz, was du da mit logwatch machst. Zumal die man page mir weder --output noch --format erklärt.

Der zweite Aufruf von /usr/sbin/logwatch erzeugt die Datei, die du nachher versendest. Aber was macht der erste mit sudo logwatch? Ist der nicht überflüssig? Die dabei erzeugte Datei verwendest du doch gar nicht - zumindest nicht im Script.

(Eine Macke von logwatch ist übrigens, dass logwatch Log-Dateien im Klartext braucht, während Systemd uns allen binäre Logdateien andrehen möchte, die sich nur noch mit journalctl lesen lassen. Um Logdateien im Klartext zu schreiben, braucht Systemd dann ein Zusatzprogramm, das installiert sein kann, aber nicht muss. Bei dir ist es offensichtlich installiert, aber das können andere Leute anders machen. Wenn du eine Lösung findest, die journalctl statt logwatch verwendet, wäre das universeller.)

[Nastra]

Deine Script-Endung .pl ist auch sehr verwirrend

Jo das stimmt, hatte das ursprünglich Skript was ich erweitert habe als Pearl gefunden. Habe es jetzt als Shell umbenannt und es läuft noch.

Na, das ist doch das beste ... wenn du selber anfängst rumzubasteln und zu experimentieren

Selbst ist der Nastra

ich bin ja mal wieder erstaunt, was man mit Telegram so alles machen kann

Bin auch total begeistert, habe ntfy jetzt komplett gelöscht da ich alles direkt über die API mache eine Fehlerquelle weniger.

Ich verstehe nicht so ganz, was du da mit logwatch machst. Zumal die man page mir weder --output noch --format erklärt.

Logwatch habe ich durch Zufall entdeckt und bin relativ begeistert davon, er macht dir je nach dem was du ihm in der Config für eine Auswertungstiefe angibst eine Zusammenfassung deiner LogDateien mit allen möglichen Sachen vom Kernel Error, über SSH Login bis hin zur Speicherplatzbelegung fast er alles mögliche zusammen was in dem angegeben Zeitraum in deinem System so passiert ist. Also genau das was ich noch neben dem reporter.sh gesucht habe. Und das wichtigste ist das das Programm nicht zu kompliziert ist.

Code: Alles auswählen

Der zweite Aufruf von /usr/sbin/logwatch erzeugt die Datei, die du nachher versendest. Aber was macht der erste mit sudo logwatch? Ist der nicht überflüssig? Die dabei erzeugte Datei verwendest du doch gar nicht - zumindest nicht im Script.

Ich wollte dich nur testen ob du auch aufpasst
Ne Spass danke für denn Hinweis, habe diese jetzt entfernt, jetzt wo du es angesprochen hast war es auch für mich direkt ersichtlich. Dadurch ist das Skript auch etwas schneller, da er die Datei jetzt nicht erzeugt und nochmal anschließend überschreibt also doppelt gemoppelt

Code: Alles auswählen

braucht Systemd dann ein Zusatzprogramm, das installiert sein kann, aber nicht muss

Außer Logwatch selber habe ich nichts bewusst Installiert. Ich vermute mal das Logwatch dieses Zusatzprogramm mit installiert hat oder das es auf meinem OS schon dabei gewesen ist.

Wenn du eine Lösung findest, die journalctl statt logwatch verwendet, wäre das universeller.)

Gut möglich aber die Sache ist jetzt schon sehr Zeitaufwendig daher gebe ich mit der Lösung die habe, funktioniert und das macht was ich möchte einfach mal Zufrieden da meine Frau mir schon etwas auf die Füße tritt und langsam fragt was ich die ganze Zeit da mache

Hier das fertige Skript

Code: Alles auswählen

#!/bin/bash

############### Vorgaben Skript ###############
day=$(date +%Y-%m-%d)
filename=/home/pi/logwatch/$day-logwatch.txt

############### Telegram Config ##############
######## Token und Chat ID ausfüllen #########
token=<TOKEN>
chat_id=<CHAT ID>

############### Logdatei erstellen ###############
/usr/sbin/logwatch --output file --filename $filename
chmod 644 $filename

############### Logdatei versenden ###############
curl -F chat_id="$chat_id" -F document=@"/home/pi/logwatch/$day-logwatch.txt" https://api.telegram.org/bot$token/sendDocument >/dev/null 2>&1

############### Logdatei löschen die älter als +X Tage sind ###############
find /home/pi/logwatch/* -mtime +1 -exec rm {} \;

[scientific]

Hmmm...

Ich verstehe deine Begeisterung über die Möglichkeiten, einen Linuxrechner beim Leben zuzusehen, wirklich gut. Ich hatte selbst mal logwatch im Einsatz, um einen Server beim Arbeiten per Mail mitverfolgen zu können.

Als es dann endlich lief, störten mich die ständigen Benachrichtigungen über neue Mails...

Aber bist du dir wirklich sicher, dass nicht doch eine Einarbeitung in ein Monitoringsystem wie Zabbix, oder wie ich selber unlängst kennenlernte, Prometheus und Grafana nicht eher dem entspricht, was du willst?
Ein System, welches die Daten deiner Services aufzeichnet und dem du Schwellwerte und Trigger definierst, wann du wie Benachrichtigt wirst...

Sowas zahlt sich schon aus. Ubd es erspart dir dauergebimmel am Handy mit einhergehender grantigwerdender besserer Lebenshälfte... Die wird entweder grantig, weil dein Handy dauernd bimmelt oder eifersüchtig, weil sie denkt, du hast eine mitteilungsbedürftige andere...

[NAB]

Bin auch total begeistert, habe ntfy jetzt komplett gelöscht da ich alles direkt über die API mache eine Fehlerquelle weniger.

Und ein fremdes komisches Programm weniger auf der Platte, um dessen Updates man sich kümmern müsste ...

Logwatch habe ich durch Zufall entdeckt und bin relativ begeistert davon, er macht dir je nach dem was du ihm in der Config für eine Auswertungstiefe angibst eine Zusammenfassung deiner LogDateien mit allen möglichen Sachen vom Kernel Error, über SSH Login bis hin zur Speicherplatzbelegung fast er alles mögliche zusammen was in dem angegeben Zeitraum in deinem System so passiert ist.

Ah, dann steckt die andere Hälfte des Geheimnisses wohl in den Konfigurationsdateien .. die habe ich mir nicht genauer angeguckt.

Dadurch ist das Skript auch etwas schneller, da er die Datei jetzt nicht erzeugt und nochmal anschließend überschreibt also doppelt gemoppelt

Nein, die hat er nicht überschrieben, die erste Datei hatte ein anderes Datumsformat im Namen. Er hat zwei Dateien erzeugt ... und zumindest jetzt, wo du das gesamte Script als root laufen lässt, löscht er per "find" auch beide wieder. Eh ... oder auch nicht ... die Dateinamen müssten Leerzeichen enthalten, die dein "find" durcheinanderbringen. Schau mal nach, was in /home/pi/logwatch noch an altem Müll rumliegt.

Außer Logwatch selber habe ich nichts bewusst Installiert. Ich vermute mal das Logwatch dieses Zusatzprogramm mit installiert hat oder das es auf meinem OS schon dabei gewesen ist.

Ja, das dürfte schon dabei gewesen sein, vermutlich "rsyslog". Das dockt an Systemd an und schreibt dann die Logs im Klartext.

Hier das fertige Skript

Hach, die Scripte werden mal kürzer statt länger ... find ich gut

Noch ein paar Kleinigkeiten:
1) Du definierst eigentlich schon den "filename", schreibst die Definition aber noch mal in die curl-Zeile. Ich weiß nicht, ob curl da irgendwie durcheinanderkommt, aber eigentlich müsste es auch so gehen:

Code: Alles auswählen

curl -F chat_id="$chat_id" -F document=@"$filename" https://api.telegram.org/bot$token/sendDocument >/dev/null 2>&1

2) Das Script läuft jetzt eh als "root". Die chmod-Zeile brauchst du nicht mehr, die kann raus.

3) Gerade wenn Scripte als root laufen, ist es guter Stil, bei Befehlen den vollen Pfad anzugeben, also
/bin/date, /usr/bin/curl, /usr/bin/find, /bin/rm
(Wo so ein Befehl rumlungert, kriegst du mit z.B. "whereis curl" raus)

4) Ich fänd's ja schöner, wenn das Script als "pi" laufen würde, aber dann bräuchten wir sudo, und ich vermute, das fragt bei dir nach einem Passwort? (Was gut so ist)
Eventuell war das auch der Trick bei deinen zwei Units? Die eine lief als root mit logwatch, die andere zum Versenden als "pi"?

[Nastra]

Moin moin,


@scientific
Danke für deinen Hinweis . Wie du schon selber sagst hast du auch mit Logwatch begonnen, ich denke für die jetzigen Ansprüche die ich habe reicht es mir. Sollten sich in Zukunft noch Bedürfnisse nach mehr Überwachung bei mir entwickeln werde ich die von dir genannte Software genauer anschauen. Momentan bin ich einfach nur froh wenn alles mal läuft wie es mir anfangs vorgestellt habe.

Ps. Die bessere Hälfte ist schon grantig weil ich soviel am basteln bin

Du definierst eigentlich schon den "filename", schreibst die Definition aber noch mal in die curl-Zeile. Ich weiß nicht, ob curl da irgendwie durcheinanderkommt, aber eigentlich müsste es auch so gehen:

Funktioniert, Klasse!

hat zwei Dateien erzeugt ... und zumindest jetzt, wo du das gesamte Script als root laufen lässt, löscht er per "find" auch beide wieder. Eh ... oder auch nicht ... die Dateinamen müssten Leerzeichen enthalten, die dein "find" durcheinanderbringen.

Also der Dateiname von der erzeugten Datei sieht so aus und enthält keine Leerzeichen:

Code: Alles auswählen

2018-03-26-logwatch.txt

Das Script läuft jetzt eh als "root". Die chmod-Zeile brauchst du nicht mehr, die kann raus.

Erledigt

Gerade wenn Scripte als root laufen, ist es guter Stil, bei Befehlen den vollen Pfad anzugeben, also
/bin/date, /usr/bin/curl, /usr/bin/find, /bin/rm

Erledigt, da sieht man direkt wo ich selber rumgefuscht habe

Ich fänd's ja schöner, wenn das Script als "pi" laufen würde, aber dann bräuchten wir sudo, und ich vermute, das fragt bei dir nach einem Passwort?

Wie meinst du das genau, also wenn ich als User Pi einen Befehl eingebe mit sudo xxxxx geht es ohne Pw. Wenn ich denn Benutzer Wechsel zu root mit sudo su dann fragt er nach dem root Pw.

Hach, die Scripte werden mal kürzer statt länger ... find ich gut

Nicht nur du


Hier die (ich schreib bewusst nicht mehr fertig ) aktuelle Version

Code: Alles auswählen

#!/bin/bash

############### Vorgaben Skript ###############
day=$(date +%Y-%m-%d)
filename=/home/pi/logwatch/$day-logwatch.txt


############### Telegram Config ##############
######## Token und Chat ID ausfüllen #########
token=<TOKEN>
chat_id=-<CHATID>


############### Logdatei erstellen ###############
/usr/sbin/logwatch --output file --filename $filename


############### Logdatei versenden ###############
/usr/bin/curl -F chat_id="$chat_id" -F document=@"$filename" https://api.telegram.org/bot$token/sendDocument >/dev/null 2>&1


############### Logdatei löschen die älter als +1 Tage sind ###############
/usr/bin/find /home/pi/logwatch/* -mtime +1 -exec /bin/rm {} \;

[Nastra]

Habe da noch eine Frage die nicht ganz zum Thema gehört. Eventuell kann mir ja einer einen kleinen Denkanstoß geben. Ist es möglich einen Befehl der verfügbare Updates anzeigt irgendwie einmal täglich auszuführen und das Ergebnis an Telegram zu senden?

Code: Alles auswählen

sudo npm outdated -g

Hatte überlegt diesen mit einem Timer und einem Service auszuführen und über das reporter.sh auszuwerten leider wird das Ergebnis von dem Befehl nicht im Journalctl angezeigt. Kann ich die Ausgabe irgendwie Abfangen?

[breakthewall]

Leider? Zum Glück steht der Output diverser Befehle nicht in den System-Logs.

Einfach in eine Datei umleiten:

Code: Alles auswählen

sudo npm outdated -g > DATEI

Wobei es ziemlich egal ist, ob man den Output nun in ein Array, eine Datei, oder in eine Variable umleitet. Eben je nachdem wie das weiterverarbeiten willst.

[Nastra]

Hey Danke für die Antwort,
das gleiche habe ich auch gerade schon getestet, bin durch Zufall auf Weiterleitungen im UBUNTU Wiki gestoßen

Wäre auf jeden Fall eine Option, die Datei kann ich ja mit dem Skript auf der ersten Seite etwas angepasst auch verarbeiten und Telegram übermitteln.

Noch besser wäre diesem Curl Befehl irgendwie mitzuteilen das er die Ausgabe direkt sendet. Habe was von Pipe gelesen |
wo ein Befehl die Ausgabe direkt an den nächsten weitergibt das könnte ja fast das sein was ich benötige. Habe aber noch nicht wirklich kapiert wie das funktionieren soll das er im Feld

text="Hello World"

statt dessen das Ergebnis einfügt. Wenn es so überhaupt geht

Code: Alles auswählen

sudo npm outdated -g | curl -s -X POST https://api.telegram.org/bot<TOKEN>/sendMessage -d chat_id=<CHAT_ID> -d text="Hello World"

[scientific]

Probiers mal damit:

Code: Alles auswählen

curl -s -X POST https://api.telegram.org/bot<TOKEN>/sendMessage -d chat_id=<CHAT_ID> -d text="$(sudo npm outdated -g)"

[Nastra]

Hammer, das funktioniert besten Dank!!! das eröffnet ganz neue Möglichkeiten

[scientific]

Du wirst vielfach auf Backticks

Code: Alles auswählen

echo `/bin/ls`

stoßen. Backticks führen den darin eingeschlossenen Befehl in einer Subshell aus. Damit sind aber keine Verschachtelungen möglich.
$(/bin/ls) mach das gleiche. Es führt den eingeschlossenen Befehl in einer Subshell aus. Jedoch sind Verschachtelungen möglich:

Code: Alles auswählen

echo $(cat $(find /home/scientific/ -type f)) 

Die Beispiele sind natürlich sinnfrei... aber zeigen, was mit Subshells mit $() geht.

[NAB]

Also der Dateiname von der erzeugten Datei sieht so aus und enthält keine Leerzeichen:

Ja, stimmt. Aber die alte logwatch-Zeile, die du entfernt hast, die hat Leerzeichen erzeugt. Aber gut, die alten Dateien scheinen weg zu sein

Wie meinst du das genau, also wenn ich als User Pi einen Befehl eingebe mit sudo xxxxx geht es ohne Pw.

Ja, genau das meinte ich.
hmm ... dann könnten wir es ja doch noch mal mit einfachen Benutzerrechten versuchen.
Dazu müsstest du erst mal ein:
User=pi
in die Systemd-Unit schreiben. Und zweitens müssen zwei Zeilen geändert werden:

Code: Alles auswählen

/usr/bin/sudo /usr/sbin/logwatch --output file --filename $filename

Da kommt ein sudo davor, denn pi darf logwatch nicht ausführen. Und:

Code: Alles auswählen

/usr/bin/find /home/pi/logwatch/* -mtime +1 -exec /bin/rm -f {} \;

Hier ist das -f neu. Das verhindert, dass rm nervige Rückfragen stellt, ob es wirklich Dateien löschen soll, die root gehören.

Das klappt nur, wenn das Verzeichnis /home/pi/logwatch auch wirklich "pi" gehört (sonst darf pi die Dateien von root darin nicht löschen).
Du könntest noch ein:

Code: Alles auswählen

/bin/mkdir -p ~/logwatch

oben in die "Vorgaben Skript" schreiben, dann wird das Verzeichnis automatisch erzeugt, wenn es nicht existiert.

statt dessen das Ergebnis einfügt. Wenn es so überhaupt geht

Code: Alles auswählen

sudo npm outdated -g | curl -s -X POST https://api.telegram.org/bot<TOKEN>/sendMessage -d chat_id=<CHAT_ID> -d text="Hello World"

Himmel, ist die man page von curl lang ...
Das scheint tatsächlich auch mit einer Weiterleitung zu klappen, und zwar mit dieser komischen Notation:

Code: Alles auswählen

sudo npm outdated -g | curl -s -X POST https://api.telegram.org/bot<TOKEN>/sendMessage -d chat_id=<CHAT_ID> -d @-

Das ist aber eine Spezialität von curl. Die Lösung von scientific ist universeller.

[Nastra]

Hey NAB, habe es gerade getestet. Klappt leider nicht. Er sendet mir die Nachricht die ich eingebaut habe aber nicht mehr die Datei.

Edit: sudo bash logwatch.sh funktioniert aus dem Terminal Nachricht und Datei kommen an.

Hier der Log aus dem Terminal vom Service:

Code: Alles auswählen

Mär 27 17:19:06 HomeBridgeServer systemd[1]: Starting logwatch.service...
Mär 27 17:19:06 HomeBridgeServer sudo[18646]:       pi : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/sbin/logwatch --output file --filename /home/pi/logwatch/2018-03-27-logwatch.txt
Mär 27 17:19:06 HomeBridgeServer sudo[18646]: pam_unix(sudo:session): session opened for user root by (uid=0)
Mär 27 17:19:24 HomeBridgeServer sudo[19000]:       pi : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/bin/npm outdated -g
Mär 27 17:19:24 HomeBridgeServer sudo[19000]: pam_unix(sudo:session): session opened for user root by (uid=0)
Mär 27 17:19:36 HomeBridgeServer systemd[1]: Started logwatch.service.

Und so sieht die Service Datei aus:

Code: Alles auswählen

[Unit]
Description=logwatch.service
Wants=network.target

[Service]
User=pi
Type=oneshot
ExecStart=/bin/bash /usr/local/bin/logwatch.sh

[Install]
WantedBy=multi-user.target

Hier das Skript:

Code: Alles auswählen

#!/bin/bash

############### Vorgaben Skript ###############
/bin/mkdir -p ~/logwatch
day=$(date +%Y-%m-%d)
filename=/home/pi/logwatch/$day-logwatch.txt


############### Telegram Config ##############
######## Token und Chat ID ausfüllen #########
token=
chat_id=


############### Logdatei erstellen ###############
/usr/bin/sudo /usr/sbin/logwatch --output file --filename $filename


############### Logdatei versenden ###############
/usr/bin/curl -F chat_id="$chat_id" -F document=@"$filename" https://api.telegram.org/bot$token/sendDocument >/dev/null 2>&1


############### Logdatei löschen die älter als +1 Tage sind ###############
/usr/bin/find /home/pi/logwatch/* -mtime +1 -exec /bin/rm -f {} \;


############### Plugin Update Check ###############
/usr/bin/curl -s -X POST https://api.telegram.org/bot$token/sendMessage -d chat_id="$chat_id" -d text="Verfuegbare Updates: $(sudo npm outdated -g)"

Noch eine Frage zu dem Befehl der das Dokument Versendet, ich würde gerne hier noch eine Beschreibung zu dem Dokument also einen Text in die gleiche Nachricht einfügen. Habe im Netz das hier gefunden und ausprobiert, funktioniert aber nicht die Lösung. Hat da noch einer eine Idee wie man das umbauen müsste?

https://stackoverflow.com/questions/395 ... legram-bot

@scientific
Danke für die Erklärung, was sind Backticks und was meinst du mit verschachtelungen genau.

[Nastra]

-

[scientific]

@scientific
Danke für die Erklärung, was sind Backticks und was meinst du mit verschachtelungen genau.

Ich hab dir eh Beispiele aufgeschrieben. Backtick lässt sich googlen.... Aber ich mach es für dich:
Backtick = nach links geneigte einfache Anführungszeichen. Bekommst du mit <Shift>+<´> = <`>

Eine Verschachtelung hab ich dir auch im Beispiel gezeigt.
$() entspricht ``
$($()) ist eine Verschachtelung. Probier das einmal mit ````
Also in einer Subshell führst du eine Subsubshell aus.

Das hat alle Vor- und auch Nachteile einer Subshell. Nachteil z.B. ist, dass eine Variable in der Subshell nicht in der Shell verfügbar ist. Eine Variable in der Subsubshell ist auch nicht in der Subshell und auch nicht in der Shell verfügbar. Umgekehrt aber schon!

lg scientific

[Nastra]

@scientific

Das ist ja wie bei denn Paketdienste Sub sub sub sub
Danke für die Erklärung mal schauen ob ich es auch bedienen kann. Werde morgen mal ein, zwei Sachen ausprobieren bzw. rumzuspielen damit.