Bash Script und CronJob - sehr merkwürdiges Verhalten

[meph!sto]

Hi,
ich habe auf meinem RPi 3B+ ein Script laufen, das einen Speedtest durchführt und die Ergebnisse (Ping, DL, UL) in eine DB schreibt sowie eine CSV auf Google Drive befüllt.
Führe ich das Script manuell aus: funktioniert einwandfrei
Natürlich will ich das nicht immer manuell ausführen müssen, daher Cronjob.
Stündliches ausführen: geht nicht, es werden keine Ergebnisse ermittelt (DB und CSV sind zu den Zeiten leer).
Jetzt aber das merkwürdige: lasse ich das Script z.B. alle 5minuten ausführen, klappts.
Kann mir das jmd. erklären ?
Bis zum 08.03. lief das alle 4 Stunden durch. Mir fiel nur auf dass etwas nicht stimmte, da Grafana keine aktuellen Werte mehr anzeigte.
Leider weiß ich nicht mehr ob bzw. was ich am 08.03. geändert habe.
Am Cronjob Damon liegt es ja offenbar nicht, denn andere Skripte laufen problemlos.
Ein Reboot hat auch nichts geändert.

#!/bin/bash
DATE=$(date +%F)
TIME=$(date +%T)
TMP=/home/pi/speedtest.log
cd /home/pi/SpeedTest
./SpeedTest --output text > $TMP
DOWNLOAD=$(cat $TMP | grep DOWNLOAD_SPEED | cut -d '=' -f2)
UPLOAD=$(cat $TMP | grep UPLOAD_SPEED | cut -d '=' -f2)
PING=$(cat $TMP | grep LATENCY | cut -d '=' -f2)
#read -p "Press enter to continue"

#DUMP RESULTS TO GOOGLE DRIVE
echo $DATE,$TIME,$PING,$DOWNLOAD,$UPLOAD >> /home/pi/speedtest-log/speedtest.csv
/home/pi/gdrive sync upload /home/pi/speedtest-log <key>

#DUMP RESULTS IN DB
#PARAMETERS
SQLSERVER="192.168.1.6"
PORT="3307"
DB_USER="<user>"
DB_PW="<pw>"
DB="SPEEDTEST"
#CREATE SQL QRY
QRY="INSERT INTO Data (Date,Time,Ping,Download,Upload) VALUES('$DATE','$TIME','$PING','$DOWNLOAD','$UPLOAD');"
#CONNECT TO DB AND DUMP DATA
mysql -u $DB_USER -p$DB_PW -h $SQLSERVER -P $PORT $DB -e "$QRY"

#rm $TMP

Cronjob:

*/5 * * * * /home/pi/scripts/speedtest.sh #speedtest

PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

Linux openhab 5.10.20-v7+ #1404 SMP Thu Mar 4 19:40:23 GMT 2021 armv7l

 

[Raijin]

Stündliches ausführen: geht nicht, es werden keine Ergebnisse ermittelt (DB und CSV sind zu den Zeiten leer).

Jetzt aber das merkwürdige: lasse ich das Script z.B. alle 5minuten ausführen, klappts.
Kann mir das jmd. erklären ?

Wenn du uns zeigst wie du denn den stündlichen Cronjob eingestellt hast, kann man dazu vielleicht auch etwas sagen, sonst wird es leider schwierig.

 

[meph!sto]

0 */4 * * * /home/pi/scripts/speedtest.sh #speedtest

Hat mich etwas ungenau ausgedrückt.
Das script wird per Cronjob getriggert, aber es werden keine Ergebnisse geliefert.
Was ja dann bedeutet dass das Programm "SpeedTest" keine Ergebnisse liefert.
Bei einem Cronjob (egal ob 1std, 2std oder mehr), bleibt das Programm "SpeedTest" hier stehen.

IP=XX.XX.XX.XX
IP_LAT=49.995
IP_LON=8.237
PROVIDER=Deutsche Telekom AG

Zum Vergleich (so sieht ein korrekter Durchgang aus):

IP=XX.XX.XX.XX
IP_LAT=49.995
IP_LON=8.237
PROVIDER=Deutsche Telekom AG
TEST_SERVER_HOST=speedtestde.pvdatanet.com:8080
TEST_SERVER_DISTANCE=34.2921
LATENCY=5
JITTER=0
DOWNLOAD_SPEED=196.08
UPLOAD_SPEED=42.25

Da sieht man gut dass
1-stündige Ausführung: keine Ergebnisse liefert
5-minütige Ausführung; klappt
3-minütige Ausführung: klappt

(Habe immer mal wieder den Cronjob angepasst um zu schauen wann es klappt).

Edit: Brauch' man nicht verstehen, aber ein stündlicher Cronjob mit Offset funktioniert

 

[MrFromEurope]

Wäre aber schon interessant zu wissen was da genau das Problem ist. Gibt es keine logs dazu?

 

[meph!sto]

Hi,
ja, das wäre wirklich interessant aber ich finde keine spannenden Einträge irgendwo.
Weder in /var/log/syslog, noch /var/log/messages.

 

[Wochenende]

Ich habe den Verdacht, dass einfach zu viele Leute zur vollen Stunde den Test machen wollen und der Server dann versagt. Mach doch mal ein paar Minuten später und überprüfe mit einem Ping ob der Server antwortet vorher.

Außerdem empfehle ich eine Systemd Timer-Unit dafür zu nehmen. Schon alleine weil die Fehlersuche dann viel einfacher ist.

 

[meph!sto]

Die Idee bzw. den Verdacht habe ich auch.
Der Speedtest ermittelt eigenständig einen Server, der ist also nicht fix.
Genau diesen dann immer anzupingen wäre möglich, aber mir den Aufwand nicht wert, da es ja nun wieder funktioniert.

 

[Raijin]

Ungewöhnlich ist das aber schon. Bei der 5-minütigen Ausführung wird der cronjob ja auch stündlich ausgeführt. Wenn, dann müsste also der 5-Minuten-Job zur vollen Stunde auch regelmäßig fehlschlagen. Wirklich nachvollziehbar ist das also nicht.

 

[meph!sto]

Hab die 5-minütige Ausführung aber nicht so lange laufen lassen dass sie zur vollen Stunde getriggert wurde.
Könnte ich mal prüfen, aber so wirklich wichtig ist das ja nicht.
Ist doch sowieso alles nur Spielerei

 

[Raijin]

Da das Programm/Skript speedtest ja mittendrin bzw. genau vor dem eigentlichen Test fehlzuschlagen scheint, könnte man vielleicht parallel dazu via tcpdump schauen ob es eventuell Verbindungsprobleme gibt, timeouts, o.ä.

Ist doch sowieso alles nur Spielerei

Sorry, aber DAS IST KEIN ARGUMENT !!! Spielereien sind doch das Salz in der Suppe, oder nicht?

 

[lokon]

wenn das skript von speedtest fehlschlägt, weil die API evtl. einen Timeout hat (das skript bzw. ein link dazu wurde hier noch nicht gepostet d.h. potentielle probleme damit sehen wir nicht) - dann nehm doch ein einfaches wrapping skript für wget mit den "normalen" Dateien per wget / curl von belwue, hetzner, tele2, ovh ...

 

[meph!sto]

https://github.com/taganaka/SpeedTest

Das bequeme ist daran, dass mir alles bereitgestellt wird und ich mir die Ergebnisse nicht selbst zusammen-greppen muss

 

[lokon]

könnte sein das speedtest etwas an ihren servern eingestellt hat und da etwas blockt (zb requests die bei "gerader zeit" geschickt werden wg cronjobs)

• der Speedtest nutzt nicht die offizielle API von speedtest sondern einen hack (referrer von .swf, fester "API" Key)
• der User-Agent kann verändert werden lt. source

also mal den User-Agent durch etwas unverdächtigeres ersetzen

 

[meph!sto]

Ich habe auch das offizielle speedtest-cli ausprobiert.
Da ging es im stündlichen Cronjob auch nicht.

 

[Iapetos]

Hast du alternativ mal direkt einen Timer per systemd ausprobiert? Nach allem, was ich bisher gelesen habe, wird crond als chronisch (har har) unzuverlässig eingestuft.

 

[0x7c9aa894]

Es gibt cron und es gibt anacron.
Wenn Du /etc/crontab oder /etc/cron.d/xx verwendest ist alles OK.
/etc/cron.hourly ist aber anacron, das sind nur scripte, d.h. keine crontabs.

Das ist hoffentlich klar.