Hallo liebe Community, ich schlage mich mit der Einstellung der Cron Syntax rum. Ich habe meine Standalone version 6.17.1 auf 6.17.2 gehoben. Dann musste ich feststellen das CRON nicht mehr läuft. Alle Versuche schlugen bisher fehl. Gibt es hier eine Hilfe? Ist der Fehler bekannt oder hat sich was in den notwendigen Einstellungen geändert. Ich habe dazu nichts gefunden.
Moin Werner,
soweit ich das gesehen habe, ist nichts über eine Anpassung bekannt, die dazu führen sollten, dass dein Cron nicht mehr geht. Effektiv war das letzte Update nur ein Security-Update, was eigentlich keine Implikationen auf diesen Bereich haben sollte. Habe ich auch bei von mir verwalteten Systemen nicht gehabt.
Ich hatte aber auch Mal ein eigenes System, wo es lange CRON-Probleme gab. Ich hab den dann einfach manuell selbst neu hinzugefügt.
Ich habe folgendes in meinem Crontab für den www-data Webserver User stehen:
*/5 * * * * cv api Job.execute --user=www-data > /dev/null 2>&1
Hallo Lucas, ich habe bei der Version 6.17.1 folgenden Crontab in CPANEL eingerichtet der funktioniert:
*/5 * * * * /usr/local/bin/php /home/dielinke/civi.die-linke-muc.de/core/bin/cli.php -s civi.die-linke-muc.de -u Admin -p 05XXXXXX2026 -e Job -a execute
Diesen Crontab verwende ich in der Version 6.17.2 und da funktioniert er nicht mehr.
Das Problem was ich habe ist, das ich auf den Shared-Server kein CV-Modul einrichten kann.
Was kann ich tun? Ich lese dauernd das der Cron über cron.php oder cli.php nicht mehr gehen soll. Ich habe schon sehr viel ausprobiert aber nichts klappt. Gibt es eine Möglichkeit das CV zu umgehen oder anders zu aktivieren? Momentan habe ich wieder alles auf 6.17.1 zurückgesetzt.
Schau dir doch den Error log an.
Ja, ich denke auch, dass Du wohl logging brauchen wirst, um das Problem zu finden.
Kannst Du Befehle auf einem SSH Terminal ausführen und prüfen, ob der Cron-Befehl per Direkteingabe funktioniert?
An der technischen Grundlage dürfte sich zwischen 6.7.1 und 6.7.2 nichts geändert haben. Deinen User hast Du vermutlich auch nicht verändert (z.B. neues PW)?
Die CLI-Methode ist zwar nicht der bevorzugte Weg, sollte aber auch weiterhin voll unterstützt werden. Hier ist die Dokumentation zu allen Möglichkeiten: Scheduled jobs - System Administrator Guide - CiviCRM Documentation
Ich würde ansonsten versuchen mich mit Unterstützung einer KI da durchzuhangeln. Ein Prompt könnte so aussehen:
„Ein User hat seit dem Update von CiviCRM 6.7.1 auf 6.7.2 Probleme mit dem Cronjob, dieser funktioniert nicht mehr. Er kann keinen Cron über CV einrichten, weil er einen Managed Server hat. Stattdessen steht ein cPanel zur Verfügung, wo Cron eingerichtet werden kann und bislang erfolgreich läuft. Der bisherige Cron-Job sieht beispielhaft so aus: */5 * * * * /usr/local/bin/php /home/diefirma/civi.die-firma.de/core/bin/cli.php -s civi.die-firma.de -u Admin -p 11XXXXXX2026 -e Job -a execute“
Dein Cron-Job ist anonymisiert, bei Lösungen, die der Agent vorschlägt, entsprechend berücksichtigen und auf deine richtigen Daten anpassen.
hallo Lukas, vielen Dank für deine Antwort. Ich habe verschiedenes versucht und habe festgestellt, das bei der Vorgehensweise wie ich update evtl. ein Fehler passiert. Bin mir aber nicht sicher.
ich gehe so vor das ich das bestehende Corevereichnis lösche und dann das neue Coreverzeichnis aufspiele. Nach dem Start werde ich dann gebeten die Datenbank zu aktualisieren. Das alles klappt wunderbar. Die Daten sind alle da und sonst funktioniert auch alles soweit. Bloß wie schon gesagt der Cron funktioniert nicht mehr. Ich habe keine große Kenntnis wie ich Fehler in der Webkonsole anzeigen lassen kann. Aber mir ist es gelungen festzustellen das die Datei civicrm.congig.php nicht mehr vorhanden ist. Darf ich das Verzeichnis Core nicht löschen? und muss ich einfach die neuen Dateien hineinkopieren und die alten überschreiben? VG Werner
Nachklapp: Habe es geschafft, Corn läuft wieder! Es war tatsächlich mein Fehler, Ich darf das Verzeichnis Core nicht einfach löschen, sondern muss beim Update die Dateien überschreiben. Vielen Dank für die Unterstützung. Wieder was gelernt. VG Werner
„Core löschen“ kommt mir auch merkwürdig vor als Update Procedure. Ich würde mir ein Update Script bereit legen. Bei uns läuft Civicrm im Docker - für das Update habe ich mir ein Scriupt gemacht, was ich dann einfach blind laufen lassen kann.
Ich wurde für mich damals da fündig:
https://civicrm.stackexchange.com/questions/49182/how-to-update-standalone-version
Daher habe ich tatsächlich immer core gelöscht und das neue core übertragen, was wohl nicht die beste Idee war/ist, zumal ich das CRON-Problem leider auch habe?!?
Ich bin bei Netcup → wie kann ich da den Cron anlegen, damit es passt?
Es gibt im Übrigen dazu auch einen Issue wie mir scheint:
Hylli
Bei einem containerisierten Workflow (bspw. docker) wäre der sauberste Ansatz vermutlich einfach das Image auszutauschen. Mein Setup ist docker-compose basiert und läuft – stark verkürzt – so:
# Updating compose files
sudo sed -E -i 's|^([[:space:]]*image:[[:space:]]*)(civicrm[^:]+):[^[:space:]]+|\1\2:'"$VERSION"'|' "${INSTANCE_DIR}/docker-compose.yml"
# Upgrading Container and CiviDB
echo "updating via docker-compose"
sudo docker compose -f "${INSTANCE_DIR}/docker-compose.yml" up -d
sudo docker exec -t "${INSTANCE}-app-1" cv updb
Ich habe für Standalone einen skriptbasierten Workflow, das Skript fragt im Updateprozess die gewünschte Version ab, macht auch noch Backups etc.
Für Civi auf Wordpress hab ich manuelle Schritte, wäre aber natürlich auch per Skript möglich. Hier ist wichtig, dass das Upload Verzeichnis gesichert und wieder zurück kopiert wird, ansonsten ist Core komplett löschen schon richtig. Alles, was nicht Ordner mit individuellem Inhalt sind, wird beim Update getauscht.
Kann ich beides bei Bedarf hier teilen.
Cron kann eigentlich nur „kaputt gehen“, wenn Du was an deinem Civi Verzeichnis geändert hast und dieses im Cron-Pfad vorkam. Außerdem, falls geplante Jobs aus irgendwelchen Gründen direkt in Civi deaktiviert wurden.
Ich nutze auch Netcup für meinen eigenen Server und setze den Cron dort per SSH.