Also sieht ganz so aus, also hätte vmk recht.
Offizielle Antwort des Hosters:
ZitatBezü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!
Ja, so kenne ich es auch, dass der Slot wieder frei wird, war bei meinem bisherigen Budget-Hoster so, der sich wie ne Farbe anhört und das Ein-Mal-Eins beherrscht...
Ist das denn offiziell so, oder sind das nur Vermutungen eurerseits, dass der Slot belegt bleibt?
Nein, selbst nach einem Jahr bliebe die Inklusivdomain in deinem Webhosting registriert. Das ist an die Laufzeit des Webhostings gekoppelt und verlängert sich wohl automatisch, solange das Webhosting existiert. Loswerden kann man die also nur durch Kündigung des Webhostings
oder durch Umzug zu einem anderen Registrar. Oder man nimmt halt einmalig die paar Euro in die Hand, die der Umzug durch den Support kostet.
Wenn ich beispiel.de als Inklusiv registriere, kann ich die Domain nicht extra kündigen, ohne was drauf zu zahlen? Ich kann nicht sagen "verlängert die Domain einfach nicht und gebt mir meine Inklusiv-Domain zurück"?
Doch, stimmt, es wird ja kein Registrar gewechselt...
Aber die Inklusivdomain wäre ja nur so lange nicht nutzbar, bis die Laufzeit davon vorbei wäre, also ein Jahr lang 
Das wird gehen, ist aber dann auch gebührenpflichtig. Ich würde ihn eher erst einmal mit einer Subdomain einer deiner eigenen Domains rumspielen lassen- Die kostet ja auch nichts und man hat später nicht das Problem, die Domain in das andere Paket transferieren (lassen) zu müssen.
Edit: Die Daten wird man wohl so oder so selbst transferieren müssen, das ist aber auch kein großes Ding.
Würde das nicht auch per regulärem Domain-Transfer gehen? Der wäre doch dann nicht kostenpflichtig, oder?
Was für einen Router benutzt du denn?
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...
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.
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.
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 intactAnmerkung: 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.
Hat es inzwischen geklappt? Wenn du noch irgendwie Hilfe brauchst, schrieb mir gerne eine PN 
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.
ZitatHast 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.
ZitatEventuell 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.
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:
Zitatcurl: (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
Ich schließe mich gauluises an!
