Beiträge von Holo

Das Problem wurde behoben.

Die Ursache war, dass ich die Standard-Domain zwischenzeitlich deaktiviert, aber auch bereits wieder re-aktiviert hatte, nachdem ich im Forum von Problemen diesbezüglich gelesen hatte. Ich dächte, dass ich die Cronjobs erst nach der Re-Aktivierung eingetragen hatte, aber anscheinend doch nicht, denn als ich sie (als Vorschlag vom Support) nochmal komplett gelöscht und neu eingetragen hatte, sind sie jetzt aktiv.Es lag also wirklich an der (zwischenzeitlich) deaktivierten Standard-Domain.

Habe alle möglichen Varianten durchprobiert: "Übernehmen", "OK", direkt beim Anlegen schon aktivieren, alles mit dem gleichen Ergebnis: Erfolgsmeldung, aber der Job war weiterhin inaktiv.

Ich werde mich an den Support wenden, immerhin habe ich jetzt einen Thread, wo das Problem schon beschrieben ist

Danke für deine Hilfe

Die netcup.net-Domain ist aktiv, habe ich gerade nochmal geprüft.

Die aktiven Aufgaben werden korrekt automatisiert ausgeführt.

Hallo,

ich habe das Problem, dass ich im WCP die Cronjobs nicht aktivieren kann. Klicke ich in der Liste zum Aktivieren auf das Kreuz, kommt zwar die Meldung, dass die Aufgabe aktiviert worden wäre, sie ist aber weiterhin inaktiv:

Geplante Aufgaben.jpg
(Screenshot zeigt Versuch, die unterste Aufgabe zu aktivieren.)

In die Einstellungen der Aufgabe gehen und den Haken setzen führt zur gleichen Meldung, ohne dass die Aufgabe aktiviert ist. Lege ich eine neue Aufgabe an und setze dabei den Haken bei "aktiviert", so ist die Aufgabe anschließend trotzdem deaktiviert. Es betrifft beide Aufgaben im Screenshot (vermutlich alle, will die aktiven lieber nicht deaktivieren ).

Habe ich etwas übersehen, oder mag das WCP nicht mit mir kooperieren?

(Zusätzliche Infos: Die Befehle sind korrekt, "Jetzt ausführen" führt die Aufgaben erfolgreich aus. Paket ist Webhosting 2000.)

Zitat von killerbees19

Generell ist es eine schlechte Idee, absolute Pfade in Cachedateien zu verwenden. Allerdings eine weit verbreitete, weil es halt vieles vereinfacht…

Ich werde mal schauen, ob ich alle absoluten Pfade aus den gecachten Dateien rausbekomme. Falls das nicht funktioniert, kann ich auf php_sapi_name() zurückgreifen und die Dateien doppelt cachen lassen.

Zitat von LanOpa

bei PHP nehm ich in der Regel getcwd()

getcwd() hat das gleiche Verhalten wie __DIR__: Unter CLI ist es ein anderer Pfad als mit HTTP. Insofern ändert das nix am Problem.

Zitat von mfnalex

Als ganz dreckige Lösung könntest du einfach für die CLI einen Symlink anlegen

Wohl eher nicht (Auch weil es ja nur die eine Hälfte des Problems lösen würde, aber sobald CLI mal den Cache neu erstellt, funktioniert es wieder nicht richtig). Trotzdem Danke für den Vorschlag

Ich habe festgestellt, dass die Konstanten __DIR__, __FILE__ und ähnliche verschiedene Werte haben, je nachdem ob man die Datei via URL aufruft (HTTP), oder sie per SSH direkt auf dem Server ausführt (CLI).

Über HTTP ist __DIR__ beispielsweise "/var/www/vhosts/hosting123456.abcde.netcup.net/httpdocs", wenn ich die Datei per CLI ausführe, ist __DIR__ nur "/httpdocs".

Das Problem ist, dass bei mir die Config gecacht wird. In der Config wird für einige Werte __DIR__ genutzt, beim Cachen wird die Konstante aufgelöst. Wenn ich den Cache über HTTP erstellen lasse, steht der lange Pfad drin, und der Cache funktioniert für HTTP, CLI kann den Pfad aber nicht mehr auflösen. Andersrum das gleiche: Mit CLI den Cache erstellt landet der kurze Pfad drin, und HTTP kann den nicht mehr auflösen.

Die Frage: Wieso bekomme ich verschiedene Pfade, obwohl es sich um dieselbe Datei handelt? Und kann ich das irgendwie (über eine Einstellung etc.) anpassen?

(Falls es wichtig ist: Ich habe Webhosting2000.)