Cronjob startet nicht

[Andy+]

Den open_basedir mußt Du komplett löschen. Insbesondere bei Verwendung von External Storage. Bei der Verwendung von gemeinsamen Ordnern über die Funktion „External Storage“ ist in den PHP-Einstellungen die Zeile „open_basedir“ zu leeren, da ansonsten diese Verzeichnisse auf der Oberfläche nicht angezeigt werden und somit nicht eingebunden werden können.

 

[PsychoHH]

Das kann in DSM 6 auch nicht funktionieren, da die php-Befehle etwas unterschiedlich sind :

DSM 5.x : /usr/bin/php
DSM 6.x : /usr/local/bin/php56

Eigentlich unter DSM 6.x /bin/php

 

[Andy+]

Dann guck mal, wo Deine php in DSM 5.2 und DSM 6 liegt.

 

[PsychoHH]

Unter DSM 5.2 ist es /usr/bin/php korrekt.

Ohne das php Paket ist es unter DSM 6 aber /bin/php


root@DS216plusII:/# cat /etc/VERSION
majorversion="6"
minorversion="0"
productversion="6.0.2"
buildphase="hotfix"
buildnumber="8451"
smallfixnumber="4"
builddate="2016/11/16"
buildtime="05:11:43"
root@DS216plusII:/# which php
/bin/php

 

[Andy+]

Okay, das kann sein, weil ich das SPK drauf habe. Dann wären die Pfade entsprechend

1-59/15 * * * * root /bin/su -s /bin/sh -c "/bin/php -f /volume1/web/owncloud/cron.php" http && /usr/bin/echo $(/usr/bin/date +\%Y-\%m-\%d) >> /volume1/Sicherungen/Protokolle/ownCloud_cron_php__$(/usr/bin/date +\%Y-\%m-\%d).log 2>&1

 

[Fraggle]

Ich checke heute abend dann die Pfad als erstes.

Was "open_basedir“ betrifft, ist das neu bei DSM 6? Denn bis auf das Upgrade ist ja nichts verändert und vorher funktionierte es.

 

[Andy+]

Das ist nicht neu, aber ggf. eine Möglichkeit, die Du testen solltest. Ansonsten schau doch mal nach, wo genau Deine php liegt :

/usr/bin/php
/usr/local/bin/php56
/bin/php
.........?

und je nachdem trägst Du dessen vollständigen Pfad in die Kommandozeile ein.

 

[maalik]

Hey Fraggle,

tut mir Leid, beim posten von mobil ist ein Leerzeichen dazugekommen, dass da nicht hätte sein dürfen:
Der Befehl lautet:

chown -R http:http /volume1/web/owncloud

Und in die Crontab muss folgendes

*/15    *       *       *       *       root   /bin/su -s /bin/sh -c "/usr/local/bin/php56 -f /volume1/web/owncloud/cron.php" http

Siehe auch hier:
http://www.synology-forum.de/showth...gen-für-Fehlermeldungen-Einrichtungswarnungen

 

[dil88]

Manchmal schleichen sich auch hier im Editor Leerzeichen ein, die nicht richtig sind. Es muss "chown -R" heißen, nicht "chown - R".

 

[maalik]

Argh verdammt, das war ja genau der Fehler den ich entfernen wollte Und irgendwie kam er wieder

 

[dil88]

Liegt - wie gesagt - vermutlich nicht an Dir, ich kenne das auch.

 

[Andy+]

Abgesehen von der Geschichte mit php, damit der Pfad stimmt, sollten auch die Rechte richtig sein. Da die diversen Scripte bei mir, ob nun DSM 5.2 oder DSM 6 nie funktioniert haben, mach ich das einfach pauschal. Entweder gebe ich über die Konsole

chown -R http:root /volume1/web/owncloud/ (oder statt root auch http)
chmod 755 /volume1/web/owncloud/ (ggf. auch 775)

ein, oder ich mache das über WinSCP

1. geh mit WinSCP nach /volume1/web/
2. markiere das Verzeichnis owncloud
3. Gruppe http oder root setzen
4. Eigentümer http setzen
5. Oktal 755 oder ggf. 775 setzen
6. x bei Gruppe, Eigentümer und……
7. OK

Damit gings bei mir immer, wenns mal gehakt hat. Da ist ownCloud und auch nextCloud uU. etwas empfindlich, wenn da was unzureichend ist.

 

[Fraggle]

Endlich daheim und ausprobieren:

Hey Fraggle,

tut mir Leid, beim posten von mobil ist ein Leerzeichen dazugekommen, dass da nicht hätte sein dürfen:
Der Befehl lautet:

chown -R http:http /volume1/web/owncloud

Und in die Crontab muss folgendes

*/15    *       *       *       *       root   /bin/su -s /bin/sh -c "/usr/local/bin/php56 -f /volume1/web/owncloud/cron.php" http

Kein Problem, das kenne ich. Also den chown Befehl habe ich ausgeführt, lief durch ohne Fehlermeldung (wäre auch seltsam gewesen )
dann habe

/bin/su -s /bin/sh -c "/usr/local/bin/php56 -f /volume1/web/owncloud/cron.php" http

ausprobiert und erhielt dies:

PHP is configured to populate raw post data. Since PHP 5.6 this will lead to PHP throwing notices for perfectly valid code. To fix this issue set <code>always_populate_raw_post_data</code> to <code>-1</code> in your php.ini

Da php bei mir hier überall liegt:
/bin/php
/usr/bin/php
usr/local/bin/php56
usr/local/bin/php56-cgi
usr/local/bin/php56-fpm
usr/local/bin/phppdbg56

habe ich auch noch diese Zeilen ausprobiert:

root@DS712:~# /bin/su -s /bin/sh -c "/usr/bin/php -f /volume1/web/owncloud/cron.php" http
root@DS712:~# /bin/su -s /bin/sh -c "/bin/php -f /volume1/web/owncloud/cron.php" http

An der Konsole tut sich nichts.

Im Log finde ich zu der php56 Version oben

file_exists(): open_basedir restriction in effect. File(/l10n/) is not within the allowed path(s): (/var/services/tmp:/etc.defaults:/usr/bin/php:/usr/syno/synoman:/etc:/var/run:/volume1/@tmp/php:/var/services/web:/var/services/photo:/var/services/blog:/var/services/homes) at /volume1/web/owncloud/lib/private/l10n.php#462

zu /usr/bin/php Variante und zu /bin/php Version:

An exception occured in driver: could not find driver

Damit es vollständig ist:

cat /etc/VERSION
majorversion="6"
minorversion="0"
productversion="6.0.2"
buildphase="hotfix"
buildnumber="8451"
smallfixnumber="4"
builddate="2016/11/16"
buildtime="05:11:44"
root@DS712:~# which php
/bin/php

 

[PsychoHH]

To fix this issue set <code>always_populate_raw_post_data</code> to <code>-1</code> in your php.ini

Probiert?

 

[Fraggle]

Gestern ja, in der php.ini die sich im Ordner /etc/php befindet
Genauer gesagt habe ich dort Eintrag

always_populate_raw_post_data = -1

im Abschnitt php hinzugefügt, da er vorher nicht existierte.
Gerade eben habe ich bei /usr/local/etc/php56/php.ini auch ausprobiert und

/bin/su -s /bin/sh -c "/usr/local/bin/php56 -f /volume1/web/owncloud/cron.php" http

erneut ausprobiert, der Fehler bleibt.
Which php gibt als Pfad ja auch /bin/php an, da wäre der obige Befehl doch eh nicht der richtige, oder?

 

[maalik]

In der Datei /usr/local/etc/php56/php.ini die Zeile
Code:
always_populate_raw_post_data = -1

hinzufügen:
http://www.synology-forum.de/showth...-ist-da!/page7&p=633524&viewfull=1#post633524

 

[Andy+]

Hast Du geloggt und was ist das Ergebnis auf der Adminseite? Ich kann nur nochmal anraten, sich nicht nur auf das Ergebnis der Konsole zu verlassen. Denn von dort kommt manchmal nichts und doch hat man das Ziel bereits erreicht.

 

[Fraggle]

@Maalik
Thx, ich vergaß

Anschließend über die Paketverwaltung die webstation und phpmyadmin gestoppt und wieder gestartet, (Sicherlich hätte es hier eine elegantere Lösung über die Konsole gegeben...)

Das werde ich heute abend testen.

@Andy:
Das loggen hatte ich vergessen. Das es aber nicht funktioniert hat, kann ich daran erkennen, daß im OC Backend der letzte erfolgreiche cron steht und daß mein Newsreader in OC keine neuen Nachrichten zeigt (da kommen täglich x-hundert rein und seit dem 26. kommt nichts mehr. Aber loggen werden ich noch machen.

 

[Andy+]

Wenn nichts hilft, dann geh bei den crontab-Kommandos nochmal alle Zeichen durch. Manchmal laufen diese Dinger wegen einer klitzekleinen Kleinigkeit nicht. Die Frage ist zudem, welchen Editor Du verwendest, da nicht jeder das Script "clean" hält, auch das könnte eine Rolle spielen.

 

[Fraggle]

Hmm, jetzt komme ich nicht mal an den Punkt es richtig zu probieren. Soll heißen, ich habe das gemacht:
http://www.synology-forum.de/showth...-startet-nicht&p=672633&viewfull=1#post672633

Als ich dann wie im Link beschrieben phpAdmin und Webstation beenden und neustarten wollte, sah ich, daß webstation beendet, phpmyadmin zwar lief, aber nach beenden nicht starten ließ. Es benötigt webstation ist die Meldung. Nur kann ich Webstation nicht starten. Es heißt immer, der Dienst kann nicht gestartet werden. Ich habe die Zeile dann auch mal wieder entfernt und versucht webstation zu starten. Ohne Erfolg.
Benötige ich wirklich webstation? Owncloud funktioniert ja ansonsten auch ohne. Und wie bekomme ich phpMyAdmin dann ohne webstation gestartet.

Bis zum wirklichen ausprobieren mit loggen kam ich also nicht einmal.