Synology: PHP 7 CLI fehlerfrei (Nextcloud und PHP 7)

Das PHP-Paket ist zwar schnell auf einer Synology DiskStation installiert, die richtige Konfiguration kann aber etwas komplexer ausfallen. Leider verhält sich PHP auf einer DiskStation etwas anders als auf einem gewöhnlichen Unix/Linux-Server. Gerade das PHP CLI verhält sich nicht immer wie erwartet. Manche Anwendungen lassen sich in der Konsole mit PHP 7 nicht ausführen. In diesem Artikel erkläre ich, wie man diesen Fehler behebt und so z.B. die Nextcloud-Konsolenkommandos occ mit PHP 7 ausführen kann.

PHP hat zwei Seiten, eine davon wird von Webserver (z.B. Apache) genutzt. Die andere Seite ist das CLI (Command Line Interface). Damit lassen sich PHP-Befehle und Scripte auf der Shell ausführen (z.B. über putty). Um PHP auf der Konsole auszuführen wird der Befehl php genutzt. Sind mehrere Versionen installiert, gibt es für jede Version einen eigenen Befehl (z.B. php56, php70). In der CLI-Version vom PHP-7.0-Paket sind nicht alle Extensions verfügbar (warum weiß wohl nur Synology selbst). Aus diesem Grund kommt es z.B. bei der Ausführung von sudo -u http php70 occ … zu einer Fehlermeldung. Da Nextcloud 13 angeblich der letzte Mayor-Release ist, der PHP 5.6 unterstützt, könnte das schon sehr bald wichtig werden.

Um PHP 7.0 richtig verwenden zu können, muss das richtige Profil angegeben werden.

  1. Zuerst brauchen wir den Namen vom richtigen Profil. Diese werden unter /var/packages/WebStation/etc/php_profile/ in einem Ordner pro Profil abgelegt. Der Name ist nicht sprechend, ihr müsst also auf eurer DiskStation selbst danach suchen. Solltet ihr mehrere Ordner (mindestens 2, wenn ihr PHP 5.6 und PHP 7.0 installiert habt/hattet) vorfinden, und nicht wissen, welche zu PHP 7 gehört müsst ihr euch den Inhalt etwas genauer ansehen. In jedem Ordner findet sich ein conf.d-Ordner und darin ist das Profil gespeichert. Geht zuerst sicher, dass das PHP 7-Profil einen Unterschied aufweist:
    1. Öffnet im DSM die WebStation und seht euch unter den PHP-Einstellungen die Profile an, sucht nach einem Unterschied (z.B. Extensions die in einem Profil aktiviert sind, im anderen nicht).
    2. Wenn ihr keine findet, aktiviert/deaktiviert eine Extension in einem der Profile.
    3. Öffnet jetzt die Profile (in /var/packages/WebStation/etc/php_profile/<Buchstabensalat>/conf.d/) mit vi oder nano und seht euch die aufgelisteten Extensions an. Dort findet ihr den Unterschied wieder und könnt somit die Profile zuordnen.
    4. Merkt euch den Namen für das PHP 7.0 Profil.
  2. Erstellt ein Script mit folgendem Inhalt:

    Statt <Buchstabensalat> setzt ihr den Namen eures PHP 7.0 Profils ein, den ihr oben ermittelt habt.
  3. Testet das Script in dem ihr in putty folgenden Befehl ausführt:

    Diser Befehl ist nichts anderes als php(70) -i also das phpinfo()-Äquivalent über die CommandLine. Wenn ihr alles richtig gemacht habt, wird euch die PHP 7.0-Konfiguration laut eurem Profil ausgegeben. Relativ zu Beginn der Ausgabe sollte auch die PHP-Version (in unserem Fall 7.0) aufgelistet sein.
  4.  Jetzt könnt ihr die OCC-Commands (oder alles anderen, dass PHP 7.0 und gewiusse Module benötigt) mit PHP 7.0 nutzen. Anstatt

    nutzt ihr die modifizierte PHP 7.0 CLI, indem ihr php56 einfach ersetzt:
  5. Jetzt könnt ihr den Nextcloud-Cron auch mit PHP 7.0 laufen lassen. Geht dazu im DSM in den Aufgabenplaner und erstellt eine neue Aufgabe, als Typ nehmt eigenes Script und lasst die Aufgabe alle 15 Minuten ausführen. Als Befehl gebt ihr folgendes ein:
  6. Da es etwas umständlich ist, immer den ganzen Pfad zum Script anzugeben und man den Pfad auch schnell mal vergisst, wenn man nach ein paar Wochen oder Monaten wieder einmal ein Nextcloud-Update macht, kann man sich das Leben ein wenig einfacher machen. Und zwar mit einem Alias. Man kann für die CommandLine einen Alias festlegen, also eine Art Abkürzung, dahinter kann sich ein langer Pfad verstecken aber auch ein komplexer Befehl inklusive verketteter Commands und Parametern. Wir wollen aber nur einen kurzen Alias für den Pfad und den Scriptnamen.
    Alias werden in der .bashrc_profile (zu finden in /etc.defaults/) angelegt. Öffnet die Datei mit einem Editor eures Vertrauens (via putty). Bei mir waren schon 2 Alias-Einträge vorhanden, ich habe den neuen einfach darunter hinzugefügt, ansonsten sollte es egal sein, wo der Eintrag eingefügt wird. Die Syntax sieht folgendermaßen aus:

    Jetzt müsst ihr Putty neu starten/die Verbindung neu aufbauen und dannach könnt ihr mit php7cli -i testen ob der Alias funktioniert. Ihr könnt ihn jetzt für die Aufrufe von occ-Commands nutzen oder auch in den obigen Aufruf der Nextcloud-Crons.Leider sind Anpassungen in der bashrc_profile genauso persistent wie z.B. die Anpassung des Timeouts von nginx und Apache, nachdem ihr ein DSM-Update installiert habe sind sie weg. Das heißt, ihr müsst sie dann weider neu eintragen.

 

Warum Synology im PHP-7.0-Paket nicht alle Extensions für die CLI-Version unterstützt, kann ich nicht sagen. Aber mit etwas Nachbessern bekommt man auch das geregelt. Vielen Dank an Lux007 aus dem Synology-Forum für die Lösung.

11 thoughts on “Synology: PHP 7 CLI fehlerfrei (Nextcloud und PHP 7)

  1. Auch auf die Gefahr hin das die Frage etwas unverschämt ist 🙂
    Ich habe gestern meine Synology Nextcloud auf 15 angehoben und bekomme jetzt folgende Warnungen:

    Es gibt einige Warnungen bei Deiner Systemkonfiguration.
    Du verwendest derzeit PHP 7.0.30. Upgrade deine PHP-Version, um die Geschwindigkeits- und Sicherheitsupdates zu nutzen, welche von der PHP-Gruppe bereitgestellt werden, sobald diese Deine Distribution unterstützt.
    Dieser Installation fehlen einige empfholene PHP-Module. Für bessere Leistung und bessere Kompatibilität wird dringend empfohlen, diese zu installieren.
    imagick

    An der PHP Version können wir nichts ändern (Wird irgendwann von selbst kommen) aber evtl Haben Sie einen Tipp wie ich imagick als PHP Modul installiert kriege?

    Ihre Blog Einträge sind wirklich klasse. Ohne sie hätte ich die Nextcloud wahrscheinlich niemals vernünftig ans Laufen gebracht!

    VG
    Michael Ludes

  2. Vielen Dank für die ganze Arbeit! Ich bin gerade dabei, der Synology diesen Cronjob mit cron.php beizubringen. Ich mache das so:
    Ich lege in Systemeinstellung – Aufgabenplaner eine „Geplante Aufgabe“ – „Benutzerdefiniertes Skript“ an. Benutzer ist „root“. Unter dem Tab „Zeitplan“ trage ich ein: Datum: „Täglich“. Erste Ausführungszeit ist: „00“. Frequenz ist: „Alle 15 Minuten“. Letzte Ausführungszeit ist: „23:45“. Unter dem Tab „Aufgabeneinstellungen“ kommt unter „Befehl ausführen – Benutzerdefiniertes Skript“:

    curl –insecure https://127.0.0.1/cron.php

    Das läuft jetzt alle 15 Minuten. Im Nextcloud Admin-Konto unter „Einstellungen – Grundeinstellungen – Hintergrund-Aufgaben“ erscheint der grüne Punkt. Unter „Protokollierung“ erscheinen keine Fehlermeldungen. Cron macht jetzt im Prinzip nichts anderes als irgendein fremder Server, wenn ich „Webcron“ bei „Hintergrund-Aufgaben“ angegeben hätte. Soweit so gut.

    Aber: Wenn ich „curl –insecure https://127.0.0.1/cron.php“ im Terminal als root eingebe, kommt die Meldung:

    {„data“:{„message“:“Backgroundjobs are using system cron!“},“status“:“error“}

    Kann man das ignorieren? Läuft das jetzt wirklich? Würde mich über eine Einschätzung freuen.

    Nochmal Danke!
    Uli

    PS: Etwas kurios: In /etc/crontab macht der Synology-Aufgabenplaner aus der oben beschriebenen Aufgabe (also ein Skript als root alle 15 Minuten auszuführen) die folgende Zeile:

    0,15,30,45 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23 * * * root /usr/syno/bin/synoschedtask –run id=6

    Normalerweise würde man das doch so machen:
    */15 * * * * root /usr/syno/bin/synoschedtask –run id=6

    Oder wenigstens so:
    0,15,30,45 * * * * root /usr/syno/bin/synoschedtask –run id=6

    Hmm.

  3. Vielen Dank für die ganze Arbeit! Ich bin gerade dabei, der Synology diesen Cronjob mit cron.php beizubringen. Ich mache das so:
    Ich lege in Systemeinstellung – Aufgabenplaner eine „Geplante Aufgabe“ – „Benutzerdefiniertes Skript“ an. Benutzer ist „root“. Unter dem Tab „Zeitplan“ trage ich ein: Datum: „Täglich“. Erste Ausführungszeit ist: „00“. Frequenz ist: „Alle 15 Minuten“. Letzte Ausführungszeit ist: „23:45“. Unter dem Tab „Aufgabeneinstellungen“ kommt unter „Befehl ausführen – Benutzerdefiniertes Skript“:

    curl –insecure https://127.0.0.1/cron.php

    Das läuft jetzt alle 15 Minuten. Im Nextcloud Admin-Konto unter „Einstellungen – Grundeinstellungen – Hintergrund-Aufgaben“ erscheint der grüne Punkt. Unter „Protokollierung“ erscheinen keine Fehlermeldungen. Cron macht jetzt im Prinzip nichts anderes als irgendein fremder Server, wenn ich „Webcron“ bei „Hintergrund-Aufgaben“ angegeben hätte. Soweit so gut.

    Aber: Wenn ich „curl –insecure https://127.0.0.1/cron.php“ im Terminal als root eingebe, kommt die Meldung:

    {„data“:{„message“:“Backgroundjobs are using system cron!“},“status“:“error“}

    Kann man das ignorieren? Läuft das jetzt wirklich? Würde mich über eine Einschätzung freuen.

    Nochmal Danke!
    Uli

    PS: Etwas kurios: In /etc/crontab macht der Synology-Aufgabenplaner aus der oben beschriebenen Aufgabe, ein Skript als root alle 15 Minuten auszuführen, die folgende Zeile:

    0,15,30,45 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23 * * * root /usr/syno/bin/synoschedtask –run id=6

    Normalerweise würde man das doch so machen:
    */15 * * * * root /usr/syno/bin/synoschedtask –run id=6

    Oder wenigstens so:
    0,15,30,45 * * * * root /usr/syno/bin/synoschedtask –run id=6

    Hmm.

    1. Also wenn der Punkt grün ist, würd ich mal sagen der Job wird ausgeführt.
      Leider arbeitet die DS oft nicht sehr sauber wenn Eingaben in der GUI in Text/Config-Form umgesetzt werden.

      Warums im Terminal nicht geht, kann ich dir auch nicht ganz sagen. Eventuell liegts auch daran, dass über die Commandline etwas fehlt, das der Webserver aber hat. Eben wie oben beschrieben die PHP 7 Module.

      Grüße
      Andreas

  4. Irgendwie will das bei mir nicht funktionieren.
    Bei mir bleiben die Fehler von Nextcloud.

    Fehlender Index „share_with_index“ in der Tabelle „oc_share“.
    Fehlender Index „parent_index“ in der Tabelle „oc_share“.
    Fehlender Index „fs_mtime“ in der Tabelle „oc_filecache“

    Habe den Befehl von Daniel say ausgeführt und bekomme folgende Ausgabe.

    admin@DS1817:~$ sudo -u http /usr/local/bin/php70 -c /var/packages/WebStation/etc/php_profile//conf.d/user_settings.ini -f /volume1/web/nextcloudnew/occ db:add-missing-indices
    An unhandled exception has been thrown:
    OCP\AppFramework\QueryException: Could not resolve defaultTokenProvider! Class defaultTokenProvider does not exist in /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php:110
    Stack trace:
    #0 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(125): OC\AppFramework\Utility\SimpleContainer->resolve(‚defaultTokenPro…‘)
    #1 /volume1/web/nextcloudnew/lib/private/ServerContainer.php(132): OC\AppFramework\Utility\SimpleContainer->query(‚defaultTokenPro…‘)
    #2 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(81): OC\ServerContainer->query(‚defaultTokenPro…‘)
    #3 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(104): OC\AppFramework\Utility\SimpleContainer->buildClass(Object(ReflectionClass))
    #4 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(125): OC\AppFramework\Utility\SimpleContainer->resolve(‚OC\\Authenticati…‘)
    #5 /volume1/web/nextcloudnew/lib/private/ServerContainer.php(132): OC\AppFramework\Utility\SimpleContainer->query(‚OC\\Authenticati…‘)
    #6 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(171): OC\ServerContainer->query(‚OC\\Authenticati…‘)
    #7 /volume1/web/nextcloudnew/3rdparty/pimple/pimple/src/Pimple/Container.php(114): OC\AppFramework\Utility\SimpleContainer->OC\AppFramework\Utility\{closure}(Object(OC\Server))
    #8 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(123): Pimple\Container->offsetGet(‚OC\\Authenticati…‘)
    #9 /volume1/web/nextcloudnew/lib/private/ServerContainer.php(132): OC\AppFramework\Utility\SimpleContainer->query(‚OC\\Authenticati…‘)
    #10 /volume1/web/nextcloudnew/lib/private/Server.php(364): OC\ServerContainer->query(‚OC\\Authenticati…‘)
    #11 /volume1/web/nextcloudnew/3rdparty/pimple/pimple/src/Pimple/Container.php(118): OC\Server->OC\{closure}(Object(OC\Server))
    #12 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(123): Pimple\Container->offsetGet(‚OCP\\IUserSessio…‘)
    #13 /volume1/web/nextcloudnew/lib/private/ServerContainer.php(132): OC\AppFramework\Utility\SimpleContainer->query(‚OCP\\IUserSessio…‘)
    #14 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(171): OC\ServerContainer->query(‚OCP\\IUserSessio…‘)
    #15 /volume1/web/nextcloudnew/3rdparty/pimple/pimple/src/Pimple/Container.php(114): OC\AppFramework\Utility\SimpleContainer->OC\AppFramework\Utility\{closure}(Object(OC\Server))
    #16 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(123): Pimple\Container->offsetGet(‚UserSession‘)
    #17 /volume1/web/nextcloudnew/lib/private/ServerContainer.php(132): OC\AppFramework\Utility\SimpleContainer->query(‚UserSession‘)
    #18 /volume1/web/nextcloudnew/lib/private/Server.php(1408): OC\ServerContainer->query(‚UserSession‘)
    #19 /volume1/web/nextcloudnew/lib/private/Server.php(683): OC\Server->getUserSession()
    #20 /volume1/web/nextcloudnew/3rdparty/pimple/pimple/src/Pimple/Container.php(118): OC\Server->OC\{closure}(Object(OC\Server))
    #21 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(123): Pimple\Container->offsetGet(‚OC\\App\\AppManag…‘)
    #22 /volume1/web/nextcloudnew/lib/private/ServerContainer.php(132): OC\AppFramework\Utility\SimpleContainer->query(‚OC\\App\\AppManag…‘)
    #23 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(171): OC\ServerContainer->query(‚OC\\App\\AppManag…‘)
    #24 /volume1/web/nextcloudnew/3rdparty/pimple/pimple/src/Pimple/Container.php(114): OC\AppFramework\Utility\SimpleContainer->OC\AppFramework\Utility\{closure}(Object(OC\Server))
    #25 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(123): Pimple\Container->offsetGet(‚AppManager‘)
    #26 /volume1/web/nextcloudnew/lib/private/ServerContainer.php(132): OC\AppFramework\Utility\SimpleContainer->query(‚AppManager‘)
    #27 /volume1/web/nextcloudnew/lib/private/Server.php(1703): OC\ServerContainer->query(‚AppManager‘)
    #28 /volume1/web/nextcloudnew/lib/private/legacy/app.php(342): OC\Server->getAppManager()
    #29 /volume1/web/nextcloudnew/lib/private/legacy/app.php(113): OC_App::getEnabledApps()
    #30 /volume1/web/nextcloudnew/lib/base.php(654): OC_App::loadApps(Array)
    #31 /volume1/web/nextcloudnew/lib/base.php(1068): OC::init()
    #32 /volume1/web/nextcloudnew/console.php(46): require_once(‚/volume1/web/ne…‘)
    #33 /volume1/web/nextcloudnew/occ(11): require_once(‚/volume1/web/ne…‘)
    #34 {main}PHP Fatal error: Uncaught OCP\AppFramework\QueryException: Could not resolve defaultTokenProvider! Class defaultTokenProvider does not exist in /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php:110
    Stack trace:
    #0 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(125): OC\AppFramework\Utility\SimpleContainer->resolve(‚defaultTokenPro…‘)
    #1 /volume1/web/nextcloudnew/lib/private/ServerContainer.php(132): OC\AppFramework\Utility\SimpleContainer->query(‚defaultTokenPro…‘)
    #2 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(81): OC\ServerContainer->query(‚defaultTokenPro…‘)
    #3 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(104): OC\AppFramework\Utility\SimpleContainer->buildClass(Object(ReflectionClass))
    #4 /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php(125): OC\AppFramework\Utility\SimpleContainer->resolve(‚OC\\Authenticati…‘)
    #5 /volume1/web/nextcloudnew/lib/private/Serve in /volume1/web/nextcloudnew/lib/private/AppFramework/Utility/SimpleContainer.php on line 110

  5. Aber jetzt…
    mit dem < Zeichen vor Buchstabensalat wurde Buchstabensalat hier beim posten einfach aus der Befehlskette gelöscht…

    sudo -u http /usr/local/bin/php70 -c /var/packages/WebStation/etc/php_profile/Buchstabensalat/conf.d/user_settings.ini -f /volume1/web/cloud/occ db:add-missing-indices

  6. … hier der vollständige Befehl:
    sudo -u http /usr/local/bin/php70 -c /var/packages/WebStation/etc/php_profile//conf.d/user_settings.ini -f /volume1/web/cloud/occ db:add-missing-indices

  7. Auch von mir vielen Dank für den Beitrag!
    Leider hat es bei mir nicht ganz funktioniert aber durch deinen Beitrag und das Synology-Forum bin ich auf die Lösung gekommen.

    Für alle über den Aufgabenplaner der Synology die occ-Befehle (bspw: occ db:add-missing-indices) oder den conjob ausführen möchten, hier die Lösung die bei mir geklappt hat:

    sudo -u http /usr/local/bin/php70 -c /var/packages/WebStation/etc/php_profile//conf.d/user_settings.ini -f /volume1/web/cloud/occ db:add-missing-indices

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.