Crontabs

T

thor68

bekommt Übersicht
Hallöchen!

Ich habe cron, wget und cURL auf meinem Ubuntu installiert.

Folgendes funktioniert:

Code: 
putty: wget --spider https://**********.de/crontest.php  // --spider sei dasselbe wie: -O /dev/null

Das auch:

Code: 
1. Aufruf von: crontab -e

2. Hinzufügung von: */1 * * * * wget --spider https://**********.de/crontest.php


Der Inhalt von crontest.php schreibt die Uhrzeit minütlich in ein Textfile, was klar aufzeigt, dass das soweit funktioniert:


PHP: 
file_put_contents(__DIR__ . '/crontest.txt', date("H:i:s")."\n", FILE_APPEND);


Jetzt kommt das Problem:

Die Webseite, die ich real nutze, prüft bei jedem Seitenaufruf, ob zwei PHP-Jobs laufen. Falls nicht, werden sie aktiviert und verrichten ihren Dienst.

Falls die Jobs ausfallen und sie niemand zwischenzeitlich mit dem Besuch der Seite neu startet, findet am Ende des Tags kein Bericht statt.

Dies ruft Crontabs auf den Plan. Mein Gedankengang war, die Website einfach per Crontab aufzurufen. Was über den Browser funktioniert, versagt jedoch auch per Putty, obwohl darüber angezeigt wird, dass die Seite tatsächlich geladen worden ist. Das ist etwas verwirrend. Mein zweiter Ansatz bestand darin, jene Klasse aufzurufen, die die Jobs startet. Das funktioniert via Putty weder mittels wget noch mit cURL, obwohl zweifelsfrei die Verarbeitung der Website bzw. des aufgerufenen Scripts durch Status 200 signalisiert wird.

Das erschließt sich mir nicht.


Code: 
root@Ubuntu21-64Bit:~# wget https://**********.de/
--2022-07-08 14:33:58--  https://**********.de/
Resolving **********.de (**********.de)... **.***.***.***
Connecting to **********.de (**********.de)|**.***.***.***|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html.1’


Ein Blick in die Datenbank verrät, dass weder die zwei Jobs gestartet worden sind, noch dass die Seite aufgerufen worden sei. Natürlich wurde sie aufgerufen, was ja durch den Status 200 repräsentiert wird.

Da steht der Thor nun etwas auf dem Schlauch!

Jemand die perfekte Idee?

Wenn ich so recht überlege, ist das eigentlich gar kein Problem von Cron, weil es ja nicht einmal via Putty funktioniert. Was denkst du darüber?
 
Okay, einen Punkt habe ich schon lösen können. Meine zwei Testserver besitzen kein SSL-Zertifikat. Darum lässt sich wget nicht einfach so nutzen.
Die Lösung ist:

Code: 
wget --no-check-certificate --spider ***.***.***.***/v1/server/cron.php // Aufruf via IP funktioniert einwandfrei

Nun besteht aber noch das Problem, dass der Aufruf der Website nicht dafür sorgt, dass die Jobs gestartet werden. Wie bereits erwähnt, funktioniert der Aufruf der Website über den Browser. Ruft man die Seite aber mittels wget auf, werden die Jobs nicht gestartet.
 
Lass doch mal den --spider weg und schau dir mal an, was der Server auf einen wget- Request schickt.
 
Mhm! Duffguy, jetzt starten die Jobs beim Aufruf mit wget. Allerdings mit und ohne "--spider". Aber eins bleibt mir immer noch unerklärlich. Wenn ich die Seite über den Browser aufrufe, speichert sich der Aufruf in der Datenbank. Beispiel: test.de/impressum. Rufe ich die Seite mittels wget auf, starten zwar die Jobs, aber die aufgerufene Seite wird nicht in die Datebank geschrieben. Hast du eine Erklärung dafür?
 
Wget ist ja ein Downloadprgramm, kein Browser. Er kann die Webseite also nicht ausführen. Versuch es doch mal mit w3m, lynx oder so? Je nach dem, wie die Seite genau programmiert wurde, könnte das helfen. Wie genau sind die Scripte denn eingebunden, was triggert sie?
 
Zuletzt bearbeitet:
Du fragst, wie das getriggert wird.

Es gibt eine Kundenseite (client) auf dem mein Skript läuft und meine Gegenstelle (server) worauf die Daten des Clients ausgewertet werden.

Rufst du den Client auf, wird mittels AJAX ein Verbindung zum Server aufgebaut, um die übermittelte URL zu analysieren.

Damit das geschehen kann, müssen zwei Jobs laufen. Einer, der die Analyse erstellt und ein weiterer, der zu einer bestimmten Uhrzeit einen Bericht dazu anfertigt und versendet.

Beim Aufruf des Clients reagiert der Server, prüft, ob die Jobs laufen, startet sie ggf. neu und speichert in diesem Zuge auch die vom Client übermittelte URL in der Datenbank des Servers.

Ruft man den Client klassisch über den Browser auf, funktioniert der gesamte Prozess.

Zu Testzwecken hatte ich mittels Wget die Clientseite aufgerufen, wobei aber keine URL beim Server gespeichert wird.

Womöglich liegt das daran, dass die Seite - die ja nur runtergeladen wird - kein Rendering erfährt.

Aber dann frage ich mich, warum die zwei Jobs über diesen Weg gestartet werden.

Trigger 1: Der Aufruf des Clients löst beim Server eine Klasse via require aus.

Trigger 2: Mittels Wget startet ich die Klasse direkt.

Nun probiere ich noch deine Vorschläge. Bis hierhin erstmal vielen Dank!
 
Soviel ich weiss, wird JavaScript nur im Browser ausgeführt. Oder man installiert Node.js als Runtime.

Wenn ich dich recht verstanden habe, willst du auf dem Server zu einer bestimmten Zeit ein PHP-Script laufen lassen.
Da würde ich auf dem Server einen Cronjob machen , der PHP mit der entspr. Datei aufruft...

hth
 
Cronjob geht natürlich nur, wenn er auch auf der Clientseite Systemzugriff hat.

Wenn er das nicht hat, muss man mit solchen Workarround arbeiten.
Ist halt die Frage, ob und wie tief man selber am Quelltext schrauben will. Gibt ja auch solche Plugins: Cron | Plugin Developer Handbook | WordPress Developer Resources

Dieses Script startet die Jobs auch ohne Javascript mit einem Wget Aufruf: Hooking WP-Cron Into the System Task Scheduler | Plugin Developer Handbook | WordPress Developer Resources

Kommt also offensichtlich mit PHP ohne Ajax aus.
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben