Batch Import scheitert bei Aufruf via Drush / Server-Cron (Access Denied)
Eingetragen von montviso (2188)am 28.05.2015 - 11:32 Uhr in
Seit ca. 2 Jahren importiere ich bei zwei Projekten Produktdaten via Feeds_batch (Cron Hook Modul) in Nodes.
Dazu kommen folgende Module zum Einsatz:
Feeds, Feeds Tamper, Elysia Cron, Background Process (optional).
Irgendwann habe ich von Poorman Cron auf den Server Cron umgestellt, um große Datenmengen zuverlässiger einlesen zu können.
Seit ca. Anfang Mai funktioniert das nicht mehr.
Evt. hängt es mit einem Update zusammen, das kann ich leider nicht mehr genau sagen.
Jedenfalls ist das System mit Core und Modulen auf aktuellem Stand (Drupal 7.37).
Ich kann den Fehler nun wie folgt einschränken:
- Feeds Import kann händisch durchgeführt werden (über /import/)
- Ausführen des crons funktioniert via Backend (Elysia Cron händisch starten).
- Funktioniert nicht via Drush: Aufruf
/pfad_auf_mein_drush/drush --debug -r /pfad_auf_mein_projekt elysia-cron run
- Funktioniert nicht via Server Cron: Aufruf mit .sh-Datei mit wget www.meinedomain.de/cron?cron_key=meinkey
- Es gibt keine Fehlermeldung im Log, keine Benachrichtigung per Email über gescheiterten Cron vom Server (was bei anderen Fehlern passiert).
- Fehlermeldung im Drush unspezifisch:
Drush command terminated abnormally due to an unrecoverable error
.
Wenn ich den Cron über die Webadresse mit Cron-Key mit eingeschaltem cron_hook für mein selbst geschriebenes Modul über den Browser aufrufe, dann bekomme ich die Zugriff-Verboten-Seite.
Schalte ich den Cron-Job im Elsyia für dieses Modul aus, dann läuft der Cron fehlerfrei durch.
Der Unterschied zwischen Aufruf mit Batch bzw. Background Process besteht nur darin, daß ich bei
batch_process('node/10005');
wenigstens eine Fehlermeldung erhalte, während sonst der Fehler im Background abgehandelt wird.
Die Seite, auf die der Batch verweist (node/10005) ist für Gäste erreichbar.
Auch in der Oberfläche für die Batch-Prozesse (admin/config/system/batch/overview) bekomme ich die Zugriff-Verboten-Meldung, wenn ich den Link auf einer Batch-ID betätige.
Folgende Versuche habe ich nach Recherche im Netz zu Drupal + Batch + Acess denied schon gemacht:
- Redirects in der .htaccess:
Getestet mit default .htaccess - gleicher Fehler
- max_allowed_packet zu niedrig:
steht auf 16 MB, es wurde zu Testzwecken ein Import File mit nur 15 Einträgen getestet, bzw. Ein Google Alert Import gemacht, der pro Import nur 10 Einträge macht. Damit kann dieses Problem ausgeschlossen werden.
- Versuchsweise die Rechte für den Feeds-Import auch für Gäste frei gegeben: Gleicher Fehler
- Hinweise auf einen Patch sind uralt und können so nicht mehr eingespielt werden:
https://www.drupal.org/node/434032#comment-2286988
- Lesbare URL's ausgeschaltet (nicht, daß das eine Option wäre...aber zum Tetsten)
Hilft nicht
- Timeout kann ausgeschlossen werden, weil alle Werte in der php.ini sehr hoch stehen und nur wenige Daten eingelesen werden.
Nun bin ich am Ende mit meinem Latein und wirklich Dankbar über jeden Hinweis, was ich noch probieren kann.
Oder wie ich z.B. Drush zu einer besseren Fehlermeldung überreden kann.
- Anmelden oder Registrieren um Kommentare zu schreiben
kann es an den rechten liegen?
am 28.05.2015 - 12:32 Uhr
in welchem Benutzerkontext läuft drush, bzw. die shell?
Das ist Drush 6.1 (das letzte
am 28.05.2015 - 13:26 Uhr
Das ist Drush 6.1 (das letzte ohne Composer) auf einem HostEurope Linux-Webserver.
Benutzerkontext, Du meinst vermutlich, weil es ein andere User ist, als der Webserver?
Was müssen wir da genau wissen und wie finde ich das raus?
Ich gestehe....mit Drush bin ich noch nicht so wahnwitzig bewandert...obwohl es ja schon zum Verlieben ist, wenn es klappt...
Zur Erinnerung: der Server Cron-Job hat das Gleiche Problem und auch wenn ich via Browser und cron-Key den Cron ausführe.
Und das Ganze passiert erst seit einer Weile, wurde aber an den Benutzereinstellungen nichts geändert.
dann müsste es
am 28.05.2015 - 14:20 Uhr
einen Eintrag in einer LOG-Datei geben.
Entweder im access.log oder im error.log müsste etwas stehen, was auf den Fehler hinweist.
Diese Log-Einträge sind meist recht aussagefähig.
schau mal
am 28.05.2015 - 14:44 Uhr
wer der owner ist, und wer im cron der ausführer ist.
Im Access Log steht das, was
am 28.05.2015 - 16:37 Uhr
Im Access Log steht das, was zu erwarten ist:
a) wenn ich via Browser cron ausführe:
GET /batch?op=start&id=1558 HTTP/1.1 403
Wenn ich via Drush ausführe, dann steht da erwartungsgemäß nichts drinnen, weil es ja am Apache vorbei läuft.
In der Error-Datei steht nichts zu dem Thema, weil eine 403 Meldung ja kein Fehler im eigentlichen Sinne ist, vermute ich.
Der Owner ist der Webserver-Benutzer, wie bei allen anderen Dateien auch.
Bzw. wo muß ich genau schauen?
Muß ich im Putty zum Drush ausführen den Benutzer wechseln?
Aber im Browser Cron haben wir ja das gleiche Problem.
So, ich habe den post hier
am 28.05.2015 - 18:57 Uhr
So, ich habe den post hier jetzt 3 mal gelesen, aber ehrlich gesagt stehe ich auch auf dem Schlauch.
Das es drush seitig was mit owner Rechten zu tun haben soll wage ich zu bezweifeln. Drush wird mittels php pear installiert, d.h. hat demnach die gleichen Rechte wie php selbst. Somit also unwahrscheinlich. Du hast ja oben den Fehler schon eingeschränkt auf Elysium oder eben nicht Elysium.
Deaktiviere das doch mal, und lasse entweder einen feed oder alle feeds unkanalisiert reinlaufen. Wenn es das ist weißt Du mit Gewissheit dass es am Elysium liegt.
Zitat:auf Elysium oder eben
am 28.05.2015 - 19:58 Uhr
auf Elysium oder eben nicht Elysium.
ne, das hast Du falsch verstanden...oder ich habe es falsch ausgedrückt.
Wenn ich den Cron im Elsys. aufrufe, dann klappt es, wenn ich ihn über den Browser oder Drush aufrufe, dann nicht.
Allerdings ist es im Drush egal, ob ich "cron run" oder "elysia-cron run" aufrufe - geht in beiden Fällen nicht.
Aber ich habe in der Tat zwischenzeitlich mal Folgendes getestet:
Habe in einer Installation, die wenig Module hat, Background Process+Progress installiert, sowie mein Modul und habe dort einen einfachen Google RSS Feed Import aufgerufen.
Genau das gleiche Problem, auch ohne Elysia.
Das Modul ist also aus dem Schneider.
Es ist definitiv der batch-Aufruf, der den 403 Fehler verursacht.
Hier mal noch das Modul, aus dem ich alles entfernt habe, was nicht unbedingt drinnen stehen muß:
<?php
/**
* @file
* Importiert bestimmte Produktfeeds und setzt die entsprechenden Nodes vorher auf deaktiv
*/
function feedsimport_cron() {
$feed = 'google_rss_feed_milchtankstelle';
$file ='http://news.google.de/news?pz=1&cf=all&ned=de&hl=de&q=Milchtankstelle&cf=all&output=rss';
$source = feeds_source($feed, 0);
$config = $source->getConfig();
$config['FeedsHTTPFetcher']['source'] = $file;
$source->setConfig($config);
$source->save();
$batch = array(
'title' => t('Importing feeds test'),
'init_message' => t('test Batch is starting.'),
'operations' => array(
array('feeds_batch', array('import', $feed, 0)),),
'progress_message' => t('Processed @current out of @total.'),
'error_message' => t('Example Batch has encountered an error.'),
'finished' => 'batch_example_finished',
);
batch_set($batch);
batch_process('node/10005');
}
function batch_example_finished($success, $results, $operations) {
//Mach mal gar nix
}
?>
Puh...ist das blöde zu debuggen...bin schon ganz wuschig.
Zum Thema wuschig, das ist
am 28.05.2015 - 20:06 Uhr
Zum Thema wuschig, das ist dann der Moment in der ich die Flasche Wein entkorke!
Zitat: das ist dann der
am 29.05.2015 - 06:05 Uhr
das ist dann der Moment in der ich die Flasche Wein entkorke!
Das ist wohl jeder anders.
Da hätte ich heute morgen so einen dicken Schädel, daß gar nix mehr ginge.
So heißt es frisch auf in den neuen Tag... ;-)
Hallo, ich habe den Thread
am 29.05.2015 - 09:04 Uhr
Hallo,
ich habe den Thread sorgfältig gelesen.
Mein Gedanke ist, das hier evtl. ein NAT Problem vorliegen könnte.
Hat Dein Server eine interne (192.168.*.*) externe (122.44.*.*) sowie eine loopback (127.0.0.1) Adresse?
Kannst Du den Cron Job über drupal.sh ausführen (liegt im skripts Verzeichnis)?
Hier ist ein Artikel der Dir evtl. weiter helfen könnte:
http://www.failover.co/blog/drupal-7-running-cron-command-line
Interessant was er bei Caveats schreibt
LG
Robert
Danke Robert, das sind ja
am 29.05.2015 - 15:18 Uhr
Danke Robert, das sind ja tolle Denkanstöße.
Aufruf über drupal.sh habe ich gleich mal ausprobiert.
Das funktioniert auch nicht.
Es gibt auch keinerlei Fehler- oder Erfolgsmeldung aus.
Ich kann nur im Backend auf der Fehlerseite sehen, daß der Cron wie üblich am Modul aufgehört hat.
Wenn ich den Modul-Cron im Elsysia deaktiviere, dann läfut der Cron auch über die drupal.sh durch.
Also keine Änderung.
Als nächstes beschäftige ich mich mit dem NAT-Problem...erst mal keine Ahnung.
In einem Subverzeichnis läuft diese Installation nicht.
Jetzt habe ich mich noch mal
am 29.05.2015 - 16:02 Uhr
Jetzt habe ich mich noch mal schlau gemacht bezüglich NAT-Problem und auch mit dem HostEurope-Support gesprochen.
Die meinen, das kann nicht der Fall sein.
Im Cron-Log sind keine Fehler zu sehen.
Ich habe mich auch noch mal abgesichert, daß es nicht an einer Paket-Umstellung bei HE von Virtual Server Managed Pro auf WebServer Supreme legen kann.
Die Umstellung war am 30.04. und bis zum 11.05 lief der ServerCron noch.
Im Server Cron-Log sind keine Fehler zu sehen.
Der Herr vom First-Level-Support meint, er tippt drauf auf ein Problem mit einem Modul-Update.
So einen Verdacht habe ich auch langsam bezüglich Background Process.
In den Issues ist aber nichts zu finden.
Ich werde mal versuchen, ob ich noch wo ne alte Installation auftreibe, wo ich das gegen testen kann.
Bei welchem Modul würdet Ihr auf drupal.org eine Frage deswegen stellen?
Mir graut zwar schon davor wegen englisch, aber wenn sonst nichts hilft.
Hallo Montviso,hast Du nun
am 29.05.2015 - 16:35 Uhr
Hallo Montviso,
hast Du nun NAT oder nicht, dann kanst Du es selber testen.
Du must nur einen wget von der internen Adresse auf die externe machen
um zu sehen ob Du die externe Adresse von der Internen Adresse auf Port 80 erreichen kannst.
Der cron wird über PHP CLI ausgeführt.
Dieser schreibt Fehler standardmässig zu stdout bzw. stderr (Console).
Da ein Skript dies im Hintergrund ausführt siehst Du keine Fehlermeldung.
Soweit ich weiss kann PHP CLI Feher auch in eine Datei schreiben.
Beachte auch dass der Benutzer der den CronJob anwirft ein anderer
sein kann als www-data
Schau hier.
http://stackoverflow.com/questions/6387542/php-cli-wont-log-errors
Evtl kannst du eine Fehlerausgabe in eine Datei erzwingen mit
php -a >> /var/log/php_errors.log 2>&1
Viel Glück
Robert
PS:
Vergiss das mit dem NAT, wenn es das wäre müsste ein Timeout kommen und kein 403 er
Hallo Montviso,
am 29.05.2015 - 17:26 Uhr
Robert und ich haben eben ein bisschen länger Zeit miteinander verbracht.
Für Dich in Kürze:
Oberstes Ziel sollte es sein dass Du den error file irgendwohin schreibst. Sobald Du ihn hast sende ihn an uns.
Falls Du nicht weist wie das geht sende mir mit das BS uz. Dann gucke ich mal;)
BG
Marc
Schrieb ich ja, daß es kein
am 29.05.2015 - 17:38 Uhr
Schrieb ich ja, daß es kein NAT sein kann.
Ja, stimmt...PHP Cli verwendet ja eine andere php.ini.
Schreibrechte auf die php.ini habe ich nicht.
Deshalb mache ich meine Änderungen an der regulären php.ini via .htaccess Datei.
Das greift bei PHP Cli nicht, oder?
Da könnte ich nur versuchen, im Rootverzeichnis dieser Domain eine eigene php.ini zu schreiben und dort ne Logdatei einzutragen.
Ich fasse noch mal zusammen.
1. Aufruf via Elysia im Backend: geht
2. Aufruf via .sh Datei mit wget über Sever Cron geht nicht
3. Drush: geht weder cron run noch elsyia-cron run (ist das auch php-cli?)
4. drupal.sh mit Aufruf www.domain.de/cron.php?cron_key=mykey geht nicht.
In allen Fällen greift die php.ini für PHP CLI statt der normalen, richtig?
Das mit den Benutzerrechten geht mir natürlich auch die ganze Zeit im Kopf rum, nahe liegend bei einer 403 Meldung.
Aber ich habe einfach keinen Ansatz, wie ich das richtig testen kann.
Jetzt erst gelesen, danke
am 29.05.2015 - 17:42 Uhr
Jetzt erst gelesen, danke Marc...ich versuche, daß ich so ein error-file zustande bekomme.
Neue Erkenntnisse:1.
am 30.05.2015 - 15:01 Uhr
Neue Erkenntnisse:
1. Schritt: Eine neue Installation mit drush von Core Version 7.25 erstellt
und dort die Module
Background Process 7.x-1.8
Progress 7.x-1.1
installiert.
Dazu ein eigenes Cron-Modul mit einem ganz einfachen Batch-Prozess.
(Beispiel aus dem Netz).
Dieser Batch läuft ohne Probleme durch, egal ob wie ihn aufrufe.
2. Schritt: Diese Version per drush auf aktuellen Stand upgedated (Core + Module)
Ergebnis: Aufruf via www.meindomain.de/cron.php?cron_key=mykey scheitert am alt bekannten Access denied.
Daraus schließe ich, daß das Problem mit Update Core oder Background-Process rein gekommen ist.
Bzw. da ist auch noch das Modul Progress im Spiel, an dem könnte es natürlich auch noch liegen.
Ich könnte natürlich noch genau abchecken, aber welcher Version das passiert ist, aber dazu habe ich jetzt keine Lust mehr.
Ich versuche jetzt erst mal einen Issue beim Modul Background Process zu formulieren.
Zitat: 2. Schritt: Diese
am 30.05.2015 - 15:56 Uhr
2. Schritt: Diese Version per drush auf aktuellen Stand upgedated (Core + Module)
Hast du diese 7.37 Version noch? 2 ganz simple Ideen wären:
Unter Statusbericht die Benutzerberechtigungen neu aufbauen und unter Dateisystem nachsehen ob neue Pfade /tmp etc. gesetzt werden müssen?
Wäre vermutlich zu simpel, aber manchmal....
Grüße Jenna
Den Rebuild habe ich
am 30.05.2015 - 16:18 Uhr
Den Rebuild habe ich gemacht.
Pfad auf /tmp geprüft und Rechte stehen auf 777.
Klappt trotzdem nicht.
Und glaube mir - ich bin reif für jeden Tipp...und sei er noch so simple. ;-)
Hallo Montviso, nochmal ein
am 12.06.2015 - 11:25 Uhr
Hallo Montviso,
nochmal ein paar Tips evtl. hilft Dir das weiter.
ch fasse noch mal zusammen.
1. Aufruf via Elysia im Backend: geht
2. Aufruf via .sh Datei mit wget über Sever Cron geht nicht
3. Drush: geht weder cron run noch elsyia-cron run (ist das auch php-cli?)
4. drupal.sh mit Aufruf www.domain.de/cron.php?cron_key=mykey geht nicht.
PHP-CLI wird unter dem User ausgeführt unter dem Du eingeloggt bist.
Wenn Du z.B: als root eingeloggt bist und eine cron.php Datei erstellst hat auch nur root Zugriff darauf.
Möchtest Du über diese den Webserver ausführen (User www-data) bekommst Du Zugriff verweigert.
mach mal ein
ls -lin dem Verzeichnis und Sie nach, welche Benutzer/Gruppe darauf Zugriff haben.Tu das auch bei Dateien, welche vom cron.job benutzt werden sollen.
Punkt 1. läuft über den Webserver
Die anderen Punkt über die Shell und den User der dort eingeloggt ist.
Hier noch ein Link:
http://serverfault.com/questions/453811/how-to-configure-php-cli-on-linu...
MfG
Robert
Hi Robert, Danke auch für
am 23.06.2015 - 07:18 Uhr
Hi Robert,
Danke auch für Deine Antwort, die etwas unter gegangen ist.
Das mit den Userrechten hatte ich schon kontrolliert.
Wie oben beschrieben scheint es ein Problem zu sein mit der neuen Version vom Modul Background Process.
Ich habe dort einen Issue aufgemacht, aber leider noch keine Antwort bekommen.
Leider kommt beim Projekt
am 23.06.2015 - 07:22 Uhr
Leider kommt beim Projekt Background Process keine Antwort auf meinen Issue.
Das wundert mich, weil ich das Problem mit der neuen Version sowohl auf dem Server, als auch auf einem lokalen Windows-System nachbauen konnte.
Ist das Modul so wenig in Benutzung?
Hat jemand ein Modul mit cron-hook unter der neuen Version von Background Process am Laufen?