Cronjob

Guten Morgen,

Ich habe einige Probleme mit einem Cronjob.

Folgendermaßen sieht der Cronjob in Plesk aus:

32B91BE9-AD04-4A7E-8D55-926F0AAE43F4.jpeg

Läuft also alle 15 Minuten und ruft eine externe URL auf (liegt auf einem anderen Server, wo ich leider keine Cronjobs anlegen kann).

Er soll mich dabei jedesmal benachrichtigen, solange die Ausgabe nicht leer ist.

Das passiert allerdings nicht, stattdessen kriege ich nur einmal stündlich eine Mail:

Quote

curl: (7) Failed to connect to domain.de port 443: Connection refused

Unable to fetch URL: https://domain.de/admin.php?cron

Wenn ich aber in die Logs des anderen Servers schaue, sehe ich dort kein "Connection refused", stattdessen nur überall "Access". Habe die IP vom netcup-Server auch nochmal extra whitelisted (obwohl derzeit keine blacklisted sind), scheint aber nichts zu ändern.

Ich bekomme also nicht die gewünschte Mail mit der Ausgabe (die ich im Moment provoziere, zu Testzwecken) und ich bekomme oben genannte Mail.

Vielleicht kann mir hier jemand weiterhelfen?

Grüße,

Twisterado

Hey gunnarh

Vielen Dank erstmal für deine Hilfe!

Ich habe jetzt mal zwei weitere Cronjobs eingetragen, einmal auf eine Domain auf demselben netcup-Server wie der Cronjob ausgeführt wird und einmal auf einem ganz anderen Server, mal sehen wie es sich da verhält.

Quote

Hast Du die Möglichkeit es direkt in der Konsole dieses Servers manuell zu versuchen?

Ich hab SSH-Zugriff auf den Server, bin mir aber unsicher, was du genau meinst... Soll ich es mit cURL per SSH versuchen?

In der Zwischenzeit hatte ich das Interval kurz auf alle 10 Minuten und dann wieder zurück auf alle 15 Minuten geändert, jetzt kam die Meldung nur noch um 14:15 und wieder um 16:15.

Quote

Eventuell wird der Domainname auf eine falsche (veraltete?) IP-Adresse aufgelöst, oder irgend eine Firewall oder SELinux-Konfiguration hindert Dich daran die Verbindung aufzubauen.

Aber die IP ändert sich eigentlich nie, wieso würde sie dann gelegentlich nicht aufgelöst werden, wenn es sonst immer klappt? Vielleicht ist die Frage etwas doof, aber ich bin in der Materie nicht so zu 100% drin.

Ich habe bei UptimeRobot u.a. auch die hier aufgerufene Domain drin und dort wird alle 5 Minuten überprüft, ob diese erreichbar ist, wenn die Domain so häufig nicht aufgelöst werden könnte, würde das dort als Downtime verzeichnet werden, die letzte ist allerdings einige Wochen her...

Das mit der Firewall könnte ich mir theoretisch vorstellen, darauf hab ich bei dem anderen Hoster aber leider keinen Zugriff und zudem werden die entsprechenden Zugriffe des netcup-Servers im Apache-Log des anderen Servers korrekt und unauffällig verzeichnet, wie gesagt, immer mit "Access" eingetragen.

Also ich habe inzwischen festgestellt, dass der Fehler nur bei diesem Host auftritt, bei anderen Domains auf anderen Servern scheint das nicht zu passieren.

Auffällig ist, dass es immer um viertel nach passiert.

Ich habe zum testen das Script mal in ein eigenes file ausgelagert.

Um punkt 00:15:00 habe ich angefangen immer wieder den curl-Befehl via ssh auszuführen, aber für etwa 10s bekam ich immer eine Fehlermeldung.

Die allererste war der von dir angesprochene Returncode 35 (diesmal sogar auch in der Mail vom Cron Daemon), danach etliche male die exakt selbe Meldung wie bisher.

Hier einmal rauskopiert:

bash-4.3$ curl -v -H 'Cache-Control: no-cache' "https://domain.de/cron.php?a=$(date +%s)"
* Hostname was NOT found in DNS cache
*   Trying 1.1.1.1...
* Connected to domain.de (1.1.1.1) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to domain.de:443 
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to domain.de:443 
bash-4.3$ curl -v -H 'Cache-Control: no-cache' "https://domain.de/cron.php?a=$(date +%s)"
* Hostname was NOT found in DNS cache
*   Trying 1.1.1.1...
* connect to 1.1.1.1 port 443 failed: Connection refused
* Failed to connect to domain.de port 443: Connection refused
* Closing connection 0
curl: (7) Failed to connect to domain.de port 443: Connection refused
bash-4.3$ curl -v -H 'Cache-Control: no-cache' "https://domain.de/cron.php?a=$(date +%s)"
* Hostname was NOT found in DNS cache
*   Trying 1.1.1.1...
* connect to 1.1.1.1 port 443 failed: Connection refused
* Failed to connect to domain.de port 443: Connection refused
* Closing connection 0
curl: (7) Failed to connect to domain.de port 443: Connection refused
bash-4.3$ curl -v -H 'Cache-Control: no-cache' "https://domain.de/cron.php?a=$(date +%s)"
* Hostname was NOT found in DNS cache
*   Trying 1.1.1.1...
* Connected to domain.de (1.1.1.1) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* Server certificate:
*      subject: CN=domain.de
*      start date: 2019-08-09 23:16:45 GMT
*      expire date: 2019-11-07 23:16:45 GMT
*      subjectAltName: domain.de matched
*      issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*      SSL certificate verify ok.
> GET /cron.php?a=1566166525 HTTP/1.1
> User-Agent: curl/7.38.0
> Host: domain.de
> Accept: */*
> Cache-Control: no-cache
> 
< HTTP/1.1 200 OK
* Server nginx is not blacklisted
< Server: nginx
< Date: Sun, 18 Aug 2019 22:15:25 GMT
< Content-Type: text/html; charset=UTF-8
< Content-Length: 0
< Connection: keep-alive
< X-Powered-By: PleskLin
< 
* Connection #0 to host domain.de left intact

Anmerkung: die meisten fehlgeschlagenen Versuche habe ich rausgekürzt, da redundant. IP und Domain waren im Original natürlich korrekt, hier ausgetauscht. Außerdem ist der Body absichtlich leer, sofern kein Fehler auftritt.

Nach den paar Sekunden läuft die Abfrage wieder problemlos, für eine ganze Stunde... Ich werde mal einen Cronjob auf meinem Pi daheim einrichten und sehen, wie sich das dort verhält. Wenn der selbe Fehler auftritt, liegt es am anderen Hoster, wenn nicht, an netcup.

Mich wundert es nur, bevor ich angefangen habe, daran zu testen, trat der Fehler immer um :45 auf, jetzt immer um :15, ob das was zu sagen hat? Keine Ahnung.

Wie auch immer, ich werde berichten.

Ja, sorry, daran hab ich nicht gedacht.

Alle 1.1.1.1 im Log sind von mir, da steht eigentlich die korrekte IP, es kam kein anderes mal eine andere IP vor.

Ok, also Entwarnung für meinen netcup Cronjob, der scheint alles korrekt zu machen, wenn der Cronjob zu genau der Zeit auf dem Pi läuft, bekomme ich den selben Fehler für die paar Sekunden.

Jetzt bleiben natürlich zwei Fragen:

1. Woran könnte das beim anderen Hoster liegen? Hast du da zufällig eine Idee? Ich werde wohl auch mal den Support kontaktieren und nachhaken.

2. Falls sich beim anderen Hoster nichts machen lässt (oder als Übergangslösung bis dahin), wäre 1-59/15 * * * * doch eine Möglichkeit, den Cronjob mit einem offset von einer Minute laufen zu lassen, wenn ich das richtig verstehe.

Ist ein reines Webhosting-Paket ohne Zugriff auf SSH oder ähnliche Möglichkeiten, in der Vergangenheit war der Support aber idR sehr kooperativ, also werde ich mal abwarten, was die grundsätzlich zu der Sache sagen.

Ich hatte in der Nacht auch zwei mal curl: (52) Empty reply from server und auch manchmal curl: (35) Unknown SSL protocol error in connection to domain.de:443

Ein Muster kann ich da allerdings nicht ausmachen.

Gäbe es irgendeinen logischen Grund, die Verbindungsaufnahme immer zur gleichen Zeit für wenige Sekunden zu verweigern? Denn schon 10s später läuft wieder alles, es ist immer nur von *:15:00 bis ca. *:15:10...

Also sieht ganz so aus, also hätte vmk recht.

Offizielle Antwort des Hosters:

Quote

Bezüglich der Curl anfragen, sollte das nicht vorkommen aber es ist durchaus möglich das Firewall Updates / Webserver Neustarts miniatur Aussetzer verursachen.

Mit dem offset, das ich eingetragen habe, läuft jetzt aber auch alles wie gewünscht.

Danke euch!