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

  • Grenze mal ein, ob es am Verbindungsziel oder an Deiner lokalen Konfiguration liegt.


    Returncode 7 bedeutet, CURL konnte zwar den Domainnamen auflösen (sonst hättest Du einen Returncode 6 erhalten) aber keine TCP-Verbindung zum Ziel herstellen. Wäre es ein SSL/TLS-Handshake Fehler würde Returncode 35 auftreten - soweit kommt Du also noch gar nicht.


    Hast Du die Möglichkeit es direkt in der Konsole dieses Servers manuell zu versuchen?
    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.


    Würde beim Eingrenzen damit beginnen es in der Konsole manuell zu versuchen sowie testweise ein anderes Verbindungsziel zu wählen.

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

    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.

  • Code
    1. Hostname was NOT found in DNS cache
    2. * Trying 1.1.1.1...
    3. * Connected to domain.de (1.1.1.1) port 443 (#0)


    Sofern Du versucht hast den Output durch Verwendung der IP-Adresse "1.1.1.1" zu anonymisieren ist dies etwas suboptimal. Dot-1 (1.1.1.1) ist ein gängiger Cloudflare-Resolver, und im Kontext "not found in DNS Cache" würde ich daher nun annehmen es wird versucht die Domain über den Dot-1 Resolver aufzulösen.


    Ist das so, oder hast Du nur ziemlich ungeschickt anonymisiert?

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

  • Der "andere Hoster" ist eine WebHosting-Infrastruktur, oder ein Server auf dem Du per SSH einsteigen und debuggen kannst?

    Wenn Du dort einsteigen kannst, würde ich dort mal die WebServer-Logs sichten. Eventuell gehen dem WebServer einfach die verfügbaren Worker-Agents aus, weil da zeitgleich zu viele Requests stattfinden.


    Deine Detail-Fehlermeldung zum Fehlercode 7 von curl lautet "Connection Refused". Das heißt da wird eine TCP-Verbindungsaufnahme explizit verweigert (TCP-Reset, kein silent Drop). Würde der Verbindungsaufnahmeversuch einfach nur outtimen weil z.B. eine Firewall oder ein Router auf der Strecke die Pakete dropped, dann würde die curl Fehlermeldung nicht "Connection Refused" sondern "Connection timed out" lauten.

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

  • */15 oder */10 klingt sehr nach einem cronjob von z.B. Plesk wo am Hosting Updates gemacht werden. Eventuell werden da Zertifikate erneuert bzw. ein ACME-Request wird nach 24h Grace-Period erneut versucht. Da wird wohl der Webserver neu gestartet.

  • 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!