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

Vom einfachen Programm zum fertigen Debian-Paket, Fragen rund um Programmiersprachen, Scripting und Lizenzierung.
Nastra
Beiträge: 94
Registriert: 13.02.2018 05:12:27

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

Beitrag von Nastra » 25.03.2018 16:47:36

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
Zuletzt geändert von Nastra am 03.04.2018 07:55:37, insgesamt 3-mal geändert.

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: Problem beim Skript ausführen mit ExecStartPost

Beitrag von NAB » 25.03.2018 17:37:07

Nastra hat geschrieben: ↑ zum Beitrag ↑
25.03.2018 16:47:36
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.
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

Nastra
Beiträge: 94
Registriert: 13.02.2018 05:12:27

Re: Problem beim Skript ausführen mit ExecStartPost

Beitrag von Nastra » 25.03.2018 17:55:34

Hey NAB,

danke für die Antwort :D
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 :mrgreen:

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: Problem beim Skript ausführen mit ExecStartPost

Beitrag von NAB » 25.03.2018 18:32:51

Nastra hat geschrieben: ↑ zum Beitrag ↑
25.03.2018 17:55:34
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
Nastra hat geschrieben: ↑ zum Beitrag ↑
25.03.2018 17:55:34
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.
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

TomL

Re: Problem beim Skript ausführen mit ExecStartPost

Beitrag von TomL » 25.03.2018 19:23:16

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
Beiträge: 94
Registriert: 13.02.2018 05:12:27

Re: Problem beim Skript ausführen mit ExecStartPost

Beitrag von Nastra » 25.03.2018 19:52:16

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 :wink: ,
dir auch erstmal wieder ein Danke für deine Teinahme an meinem Problemchen :D

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 :mrgreen:

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
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: Problem beim Skript ausführen mit ExecStartPost

Beitrag von NAB » 26.03.2018 01:32:19

*seufz* ...
TomL hat geschrieben: ↑ zum Beitrag ↑
25.03.2018 19:23:16
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.
Nastra hat geschrieben: ↑ zum Beitrag ↑
25.03.2018 19:52:16
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
Nastra hat geschrieben: ↑ zum Beitrag ↑
25.03.2018 19:52:16
, 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.
Nastra hat geschrieben: ↑ zum Beitrag ↑
25.03.2018 19:52:16
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 ...
Nastra hat geschrieben: ↑ zum Beitrag ↑
25.03.2018 19:52:16
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.
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

Nastra
Beiträge: 94
Registriert: 13.02.2018 05:12:27

Re: Problem beim Skript ausführen mit ExecStartPost

Beitrag von Nastra » 26.03.2018 06:45:11

Guten Morgen zusammen,
dass du ja sämtliche Scripte brav unter
Will es mir ja nicht schwerer machen als nötig :wink:

Mönsch ... Nastra ... du haust manchmal Sachen raus ...
Du weißt doch bei völliger Ahnungslosigkeit zumindest sicheres Auftreten oder wie war das :mrgreen:
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 :facepalm:
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 :mrgreen:

@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 {} \;
Zuletzt geändert von Nastra am 26.03.2018 09:49:52, insgesamt 2-mal geändert.

TomL

Re: Problem beim Skript ausführen mit ExecStartPost

Beitrag von TomL » 26.03.2018 09:26:53

NAB hat geschrieben: ↑ zum Beitrag ↑
26.03.2018 01:32:19
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
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: Problem beim Skript ausführen mit ExecStartPost

Beitrag von NAB » 26.03.2018 17:02:27

Nastra hat geschrieben: ↑ zum Beitrag ↑
26.03.2018 06:45:11
Hey ho, so funktioniert auch das ExecStartPost. Hatte ich mir doch gedacht das ich bei Pfad was falsch gemacht habe :facepalm:
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.
Nastra hat geschrieben: ↑ zum Beitrag ↑
26.03.2018 06:45:11
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 :mrgreen:
Nastra hat geschrieben: ↑ zum Beitrag ↑
26.03.2018 06:45:11
@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.)
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

Nastra
Beiträge: 94
Registriert: 13.02.2018 05:12:27

Re: Problem beim Skript ausführen mit ExecStartPost

Beitrag von Nastra » 26.03.2018 17:52:35

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 :mrgreen:
Selbst ist der Nastra :mrgreen:
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 :lol: :lol: :lol:
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 :THX:

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 :mrgreen:

Hier das fertige Skript :wink:

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
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Problem beim Skript ausführen mit ExecStartPost

Beitrag von scientific » 26.03.2018 19:28:40

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...

;-)
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: Problem beim Skript ausführen mit ExecStartPost

Beitrag von NAB » 26.03.2018 19:42:22

Nastra hat geschrieben: ↑ zum Beitrag ↑
26.03.2018 17:52:35
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 ...
Nastra hat geschrieben: ↑ zum Beitrag ↑
26.03.2018 17:52:35
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.
Nastra hat geschrieben: ↑ zum Beitrag ↑
26.03.2018 17:52:35
Dadurch ist das Skript auch etwas schneller, da er die Datei jetzt nicht erzeugt und nochmal anschließend überschreibt also doppelt gemoppelt :THX:
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.
Nastra hat geschrieben: ↑ zum Beitrag ↑
26.03.2018 17:52:35
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.
Nastra hat geschrieben: ↑ zum Beitrag ↑
26.03.2018 17:52:35
Hier das fertige Skript :wink:
Hach, die Scripte werden mal kürzer statt länger ... find ich gut :mrgreen:

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"?
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

Nastra
Beiträge: 94
Registriert: 13.02.2018 05:12:27

Re: Problem beim Skript ausführen mit ExecStartPost

Beitrag von Nastra » 27.03.2018 08:13:30

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 :mrgreen:
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 :THX:
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 :lol:
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 :mrgreen:
Nicht nur du :THX: :hail: :THX:


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

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
Beiträge: 94
Registriert: 13.02.2018 05:12:27

Re: Problem beim Skript ausführen mit ExecStartPost

Beitrag von Nastra » 27.03.2018 12:02:23

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
Beiträge: 507
Registriert: 30.12.2016 23:48:51

Re: Problem beim Skript ausführen mit ExecStartPost

Beitrag von breakthewall » 27.03.2018 13:06:59

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
Beiträge: 94
Registriert: 13.02.2018 05:12:27

Re: Problem beim Skript ausführen mit ExecStartPost

Beitrag von Nastra » 27.03.2018 13:16:51

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

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 :roll:

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
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Problem beim Skript ausführen mit ExecStartPost

Beitrag von scientific » 27.03.2018 13:40:44

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)"
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

Nastra
Beiträge: 94
Registriert: 13.02.2018 05:12:27

Re: Problem beim Skript ausführen mit ExecStartPost

Beitrag von Nastra » 27.03.2018 13:46:31

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

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Problem beim Skript ausführen mit ExecStartPost

Beitrag von scientific » 27.03.2018 13:53:25

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.
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: Problem beim Skript ausführen mit ExecStartPost

Beitrag von NAB » 27.03.2018 16:52:33

Nastra hat geschrieben: ↑ zum Beitrag ↑
27.03.2018 08:13:30
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 :D
Nastra hat geschrieben: ↑ zum Beitrag ↑
27.03.2018 08:13:30
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.
Nastra hat geschrieben: ↑ zum Beitrag ↑
27.03.2018 13:16:51
statt dessen das Ergebnis einfügt. Wenn es so überhaupt geht :roll:

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.
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

Nastra
Beiträge: 94
Registriert: 13.02.2018 05:12:27

Re: Problem beim Skript ausführen mit ExecStartPost

Beitrag von Nastra » 27.03.2018 17:29:16

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
Beiträge: 94
Registriert: 13.02.2018 05:12:27

Re: Problem beim Skript ausführen mit ExecStartPost

Beitrag von Nastra » 27.03.2018 17:47:56

-
Zuletzt geändert von Nastra am 27.03.2018 21:45:58, insgesamt 1-mal geändert.

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Problem beim Skript ausführen mit ExecStartPost

Beitrag von scientific » 27.03.2018 18:48:00

Nastra hat geschrieben: ↑ zum Beitrag ↑
27.03.2018 17:29:16
@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
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

Nastra
Beiträge: 94
Registriert: 13.02.2018 05:12:27

Re: Problem beim Skript ausführen mit ExecStartPost

Beitrag von Nastra » 27.03.2018 20:42:10

@scientific

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

Antworten