Backend-Suche wie Cronjob anlegen?

[Birden]

Hab jetzt vieles dazu gelesen, aber als Anwender komme ich nicht weiter. Wie richtet man den Cronjob ein, damit Backend-Suche funktioniert.
Meine Installation liegt auf einen gehosteten Webplatz, da habe ich kein Einfluß auf PHP Einstellungen.
Kann aber Cronjobs über die Oberfläche als Pfad (https://) anlegen. Würde das funktionieren, wenn ja welchen Pfad gibt man da ein?

Ich habe es damit versucht, klappt aber nicht:

domain.at/vendor/bin/contao-console contao:cron

[Spooky]

Webcron reicht nicht, du musst einen echten Cronjob anlegen.

[dieselboy]

In der Doku gibt es einen Abschnitt, der die Route

https://www.domain.de/_contao/cron

angibt, siehe https://docs.contao.org/dev/framewor...x.html#web-url

Ich stehe vor einem ähnlichen Problem und versuche das Cronjob Framework über die Admin-Oberfläche von all-inkl zum Laufen zu bekommen. Gibt es dafür keine Lösung?

[Spooky]

Siehe https://community.contao.org/de/show...l=1#post593210

[malle]

Bei all-inkl gibt es leider kein Crontab. Daher muss man den Cronjob per PHP und Shell-Skript anstoßen.

<?php
    exec("/usr/bin/php82 /www/htdocs/DEINE-W-NUMMERR/DEIN-CONTAO-ORDNER/vendor/bin/contao-console contao:cron");
    echo "1"; // das kann nach erfolgreichem Test auch raus
?>

Exec ist schon sehr mächtig, daher habe ich das Skript in einen Unter-Ordner von /public gepackt.
Bei mir sieht das dann so aus: contao/public/cron/contao-cron.php

Diesen Ordner habe ich mit einer htaccess/ Verzeichnisschutz abgesichert.
Benutzer und Passwort der htaccess übergebe ich beim Aufruf des Cronjobs über das all-inkl-Backend.

Man kann die Datei auch anders absichern. Z. B. mit einem GET-Parameter.

Dann legst du im Backend von all-inkl einen Cronjob an und befüllst ihn mit
Protokoll / Pfad: dem Pfad zum Skript
Beschreibung: frei wählbar
Ausführungsintervall
minütlich alle 1 Minuten
HTTP Benutzer: Benutzer des htaccess Schutzes
HTTP Passwort: Passwort des htaccess Schutzes
E-Mail-Adresse: deiner E-Mail-Adresse
Beschreibung als E-Mail-Betreff: ja
Cronjob ist aktiv: ja

Speichern.

Jetzt solltest du eine Minute später das, was bei echo oben im Skript steht, als E-Mail bekommen. Eventuell auch eine Fehlermeldung.
Wenn alles funktioniert, kannnst du das echo aus dem Skript nehmen und im Cronjob deine E-Mailadresse rausnehmen.

[Birden]

Wie verhält es sich mit dem Ausführungsintervall? Auf kleineren Seiten, auf denen nicht ständig im Backend gearbeitet wird, in welchem Abstand empfiehlt es sich, diesen laufen zu lassen? Ich habe bemerkt, dass der Index bei zu langem Intervall wieder verschwindet; allerdings konnte ich noch nicht feststellen, nach welcher Zeit dies geschieht.

Oder gibt es ein Argument, ihn in sehr kurzen Abständen auszuführen?

[Spooky]

Der Cronjob muss minütlich ausgeführt werden.

[toto]

Servus zusammen,

vielen Dank Malle für deine Ausführliche Beschreibung. Ich habe mich bis jetzt noch nie mit cronjobs auseinandergesetzt. Bin auch bei All-Inkl und hab alles gemacht und auch eine E-Mail erhalten. In der Mail steht dann nur eine Zeile mit den ***** wie es auch bei dem Beschreibungs-Link "Contao Cronjob-Framework" steht. Sonst steht bei mir nix in der Mail. Muß ich noch irgendwas anderes machen? Der Button "Suchindex aufbauen" ist bei mir immer noch inaktiv. Zeitintervall ist alle 1 Minute.

Danke für kurze Info.
Gruß Torsten

[Birden]

Deaktiviere und aktiviere den Cronjob, vielleicht stoßt er ihn dann an.

[planepix]

Hallo zusammen,

wollte die Backendsuche auch einmal testen, habe das bei allinkl so wie beschrieben angelegt.
Ich bekomme die Mails jede Minute mit Status 404.

Wo hab ich den Knoten produziert?

[Birden]

Stimmen die Zugangsdaten des pasßwortgeschützen Ordners?

[planepix]

Ich habs bisher ohne Passwortschutz versucht.
Sprich da muss ein Passwortschutz hin?

[Spooky]

wollte die Backendsuche auch einmal testen, habe das bei allinkl so wie beschrieben angelegt.
Ich bekomme die Mails jede Minute mit Status 404.

Beschreibe nochmal genau was du gemacht hast. Zeigt dazu evt. Screenshots.

[Birden]

Kenne mich da nicht aus, aber ich denke die Datei zu Schützen hat Sinn.

Die PHP-Version und den Pfad im Code vielleicht nochmals auf Richtigkeit überprüfen.

Wobei es am Pfad zur Datei selber liegen könnte, wenn es ein 404 ist, der muß sein:

Domain.de/ortner/datei.php

[planepix]

Beschreibe nochmal genau was du gemacht hast. Zeigt dazu evt. Screenshots.

Nach dem Post von Markus die Datei cron.php mit diesem Inhalt angelegt:

<?php
exec("/usr/bin/php83 /www/htdocs/wxxxxxx/rc54.domain.com/vendor/bin/contao-console contao:cron");
echo "1"; // das kann nach erfolgreichem Test auch raus
?>

Diese Datei dann unter „rc54.domain.com/public/cron/cron.php” abgelegt.
Und diesen Pfad auch in den Cron-Settings bei allinkl eingetragen.

allinkl-cronjob.png

[Spooky]

Der Pfad, den du bei All-Inkl. eingetragen hast ist falsch. public/ ist ja vermutlich dein DocumentRoot, oder nicht?

[planepix]

Ja genau.
Das wars. Danke!!

[flensburger-stadtanzeig]

Ich bin zu blöd.

Ich benutze Hetzner als Server und würde gerne meine Suchfunktion aktivieren und brauche dazu anscheinend ein Studium...

Wer kann mir sagen was ich wo eintragen muss? suche.jpg

Ich werde da echt nicht schlau draus.

Vielen lieben Dank.

[Spooky]

Ich bin zu blöd.

Ich benutze Hetzner als Server und würde gerne meine Suchfunktion aktivieren und brauche dazu anscheinend ein Studium...

Wer kann mir sagen was ich wo eintragen muss? suche.jpg

Ich werde da echt nicht schlau draus.

Vielen lieben Dank.

• Interpreter: die PHP Version der Contao Installation
• Skript (absoluter Pfad): der absolute Pfad zur bin/console Datei der Contao Installation am Server + contao:cron, z.B.: /usr/home/foobar/public_html/example.com/bin/contao-console contao:cron
• Ausführungszeiten: Manuell: - oder Freitext mit * * * * *
  
  • Minuten: Jede Minute
  • Stunden: Jede Stunde
  • Tage: Jeden Tag
  • Monate: Jeden Monat
  • Wochentage: N/A
• Exklusive Ausführung: Aktiv
• Zusammenfassung: * * * * * /usr/bin/php83 /usr/home/foobar/public_html/example.com/bin/contao-console contao:cron

In der Übersicht bei E-Mail-Benachrichtigung an: dann noch deine E-Mail Adresse eintragen (oder wer auch immer technisch verantwortlich ist).

[do_while]

Wir haben gestern Abend beim Berliner Stammtisch darüber gesprochen, wie man den minütlichen Cron bei All-Inkl aufsetzen kann.
Ich habe das heute noch einmal in meiner Installation (PHP 8.4, Contao 5.6.4 mit der Demoseite) probiert, aber die Backendsuche ist nicht sichtbar.

Im Cron habe ich einen minütlichen Aufruf einer start.php:

<?php
exec("/bin/bash /www/htdocs/wxxx/test.sh 2>&1", $out, $result);
echo "Returncode: " .$result ."<br>";
echo "Ausgabe des Scripts: " ."<br>";
echo "<pre>"; print_r($out);

Dieses PHP ruft dann ein Shellscript auf test.sh:

#!/bin/bash

cd /www/htdocs/wxxx/contao56/
/bin/php84 /www/htdocs/wxxx/contao56/vendor/bin/contao-console contao:cron

was wiederum den Contao:cron triggert.
Der normale Aufruf des Shell-Scripts liefert ein leeres Array zurück (das kann ja Ok sein).
Ich habe dann in vendor/bin/contao-console eine Textausgabe eingefügt, diese kommt dann auch als Ergebnis zurück.
Dann habe ich diese Ausgabe in vendor/contao/manager-bundle/bin/contao-console eingefügt, auch hier kommt der Text dann als Ergebnis zurück.
Dann habe ich die Übergabeparameter überprüft, die console wird auch mit contao:cron als Parameter aufgerufen.

Ich denke, das ist der Beweis, dass der Aufruf soweit stimmt, er erfolgt auch jede Minute, trotzdem ist keine Spur von der Backensuche zu finden.
Woran kann es noch liegen, dass die Suche fehlt?

[Spooky]

Soweit ich weiß funktioniert bei All-Inkl. die Backend Suche generell nicht, da All-Inkl. die Einsicht der Prozesse mit ps nicht erlaubt. Du könntest dich gemeinsam mit Christian Feneberg bei All-Inkl. diesbezüglich beschweren

[planepix]

Spannend.
Das ging bei einer 5.5 Installation noch bei allinkl, in 5.6 wie beschrieben nicht mehr.
Count me in, um bei allinkl nachzuhaken.

[do_while]

Ok, das ps-Kommando im SSH-Terminal funktiniert hier nicht, das kann ein Grund sein.
Aber in der 5.4 und 5.5 ging es ja wohl, ist die Nutzung des ps jetzt ab 5.6 neu hinzugekommen?

[Spooky]

Nein, es ist etwas weggefallen: https://github.com/Toflar/cronjob-supervisor/pull/6

[do_while]

Ich habe das im Ticket hinzugefügt:
https://github.com/Toflar/cronjob-su...ent-3501839489

[Spooky]

Ich habe das im Ticket hinzugefügt:
https://github.com/Toflar/cronjob-su...ent-3501839489

Du musst dich bei All-Inkl. beschweren (siehe oben).

[do_while]

Ich habe gerade mal nett bei All-Inkl angefragt, ob sie dazu eine Lösung finden können.

[Spooky]

Du kannst ihnen auch gleich die richtige Lösung sagen. /proc mit hidepid=2 mounten, damit jeder User nur die eigenen Prozesse sehen kann (so wie es bspw. bei Hostingwerk und Hetzner bereits gemacht wird). Siehe auch https://github.com/Toflar/cronjob-su...ent-3501915494

[witschi87]

Vielleicht könnt ihr mir auch weiterhelfen. Ich wollte ebenfalls die Backend-Suche aktivieren und habe dafür erfolgreich den Cronjob aktiviert. Der wird ausgeführt und läuft auch durch. Noch bevor ich aber die Backend-Suche in der config.yaml aktiviert habe, erhalte ich folgende Meldungen im Log:

[2025-11-10T11:56:40.019794+00:00] contao.error.ERROR: Message "Contao\CoreBundle\Messenger\Message\BackendSearch\ReindexMessage" failed: "Handling "Contao\CoreBundle\Messenger\Message\BackendSearch\ReindexMessage" failed: An exception occurred while executing a query: Unable to execute statement: database is locked" {"exception":"[object] (Symfony\\Component\\Messenger\\Exception\\HandlerFailedException(code: 0): Handling \"Contao\\CoreBundle\\Messenger\\Message\\BackendSearch\\ReindexMessage\" failed: An exception occurred while executing a query: Unable to execute statement: database is locked at /var/customers/webs/vendor/symfony/messenger/Middleware/HandleMessageMiddleware.php:124)\n[previous exception] [object] (Loupe\\Loupe\\Exception\\IndexException(code: 0): An exception occurred while executing a query: Unable to execute statement: database is locked at /var/customers/webs/vendor/loupe/loupe/src/Internal/Index/Indexer.php:115)\n[previous exception] [object] (Doctrine\\DBAL\\Exception\\LockWaitTimeoutException(code: 5): An exception occurred while executing a query: Unable to execute statement: database is locked at /var/customers/webs/vendor/doctrine/dbal/src/Driver/API/SQLite/ExceptionConverter.php:32)\n[previous exception] [object] (Doctrine\\DBAL\\Driver\\SQLite3\\Exception(code: 5): Unable to execute statement: database is locked at /var/customers/webs/vendor/doctrine/dbal/src/Driver/SQLite3/Exception.php:12)\n[previous exception] [object] (SQLite3Exception(code: 5): Unable to execute statement: database is locked at /var/customers/webs/vendor/doctrine/dbal/src/Driver/SQLite3/Statement.php:113)","contao":{"Contao\\CoreBundle\\Monolog\\ContaoContext":"{\"func\":\"Contao\\\\CoreBundle\\\\Messenger\\\\EventListener\\\\MessageListener::onWorkerMessageFailed\",\"action\":\"ERROR\",\"username\":\"N\\/A\",\"browser\":\"N\\/A\",\"uri\":null,\"pageId\":null}"}} {"contao":{"Contao\\CoreBundle\\Monolog\\ContaoContext":"{\"func\":\"Contao\\\\CoreBundle\\\\Messenger\\\\EventListener\\\\MessageListener::onWorkerMessageFailed\",\"action\":\"ERROR\",\"username\":\"N\\/A\",\"browser\":\"N\\/A\",\"uri\":null,\"pageId\":null}"}}
[2025-11-10T11:56:40.022491+00:00] messenger.INFO: Rejected message Contao\CoreBundle\Messenger\Message\BackendSearch\ReindexMessage will be sent to the failure transport Symfony\Component\Messenger\Bridge\Doctrine\Transport\DoctrineTransport. {"class":"Contao\\CoreBundle\\Messenger\\Message\\BackendSearch\\ReindexMessage","transport":"Symfony\\Component\\Messenger\\Bridge\\Doctrine\\Transport\\DoctrineTransport"} []

Ich hätte erwartet, dass es gar nicht so weit kommt, da die Backend-Suche ja per Default inaktiv ist. Gleichzeitig frage ich mich, welche database locked sein sollte?!
Und das beste ist: die Backend-Suche funktioniert.

Was mache ich hier falsch?

[Spooky]

Die Backend Suche ist in der Contao Managed Edition von Haus as aktiviert.

[witschi87]

Wenn ich

vendor/bin/contao-console config:dump-reference contao

ausführe, erhalte ich:

backend_search:
        enabled:              false

        # The DSN of the search adapter.
        dsn:                  ~

        # The name of the search index
        index_name:           contao_backend

Müsste dort dann nicht true stehen?
Aber auch wenn sie standardmäßig aktiv ist: Wieso erhalte ich die Fehlermeldung? Und warum funktioniert die Suche dann trotzdem?

[Spooky]

Wenn ich

vendor/bin/contao-console config:dump-reference contao

ausführe, erhalte ich:

backend_search:
        enabled:              false

        # The DSN of the search adapter.
        dsn:                  ~

        # The name of the search index
        index_name:           contao_backend

Müsste dort dann nicht true stehen?

Mit config:dump-reference lässt du dir nur die Referenz ausgeben. Den tatsächlichen Stand siehst du mit debug:config. z.B.:

$ bin/console debug:config contao backend_search

Current configuration for "contao.backend_search"
=================================================

enabled: true
dsn: 'loupe://…/var/loupe'    
index_name: contao_backend

[do_while]

Ich habe Heute eine Antwort von All-Inkl bekommen, nachdem ich bei der ersten Ablehnung dann Yannicks Beitrag gepostet habe.

Hier nun die finale Antwort von Heute:

... vielen Dank für Ihre Anfrage.

Unsere Techniker haben dazu noch einmal Rücksprache gehalten. Jedoch bleibt, auch mit der Verwendung des Mounts durch die Option "hidepids", 
ein Zugriff auf Shared-Servern auf das Kommando "ps" nicht gestattet. 

Bei weiteren Fragen stehen wir Ihnen gern zur Verfügung.

Mit freundlichen Grüßen
Supportteam

Dann ist es jetzt offenbar so.

[Spooky]

Ich würde weiter nachhaken, mit welcher Begründung das so bleibt.