Nextcloud Optimierungen für Synology Installation

[wolewo]

Bei mir kommt mit dem Befehl php -v gar nichts heraus.
Was ist hier falsch??

root@DS2422:~# php -v
-ash: php: command not found
root@DS2422:~#

 

[luddi]

@Tuxnet
Dann muss ich wohl meine Aussage von vorhin revidieren und musste auch feststellen, dass bei Synology die Configs bei einem PHP Update überschrieben werden.

Bei mir waren es folgende Dateien die ich wieder anpassen musste:
/usr/local/etc/php80/cli/php.ini
/usr/local/etc/php80/cli/conf.d/extension.ini

 

[Crashandy]

Was ist hier falsch??

Eigentlich nichts.

Hast Du es einmal mit den direkten Befehlen versucht?
php -v - ist die PHP-Version vom DSM 7.1.1 und ist nicht veränderbar
php74 -v - ist die Version von PHP 7.4.* aus dem Paketzentrum
php80 -v - ist die Version von PHP 8.0.* aus dem Paketzentrum

Bei mir sieht es dann so aus:

root@DS1821:~# php -v
-ash: root@DS1821:~#: command not found
PHP 7.3.3 (cli) (built: Oct  7 2021 06:18:21) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.3, Copyright (c) 1998-2018 Zend Technologies
root@DS1821:~# php74 -v
PHP 7.4.30 (cli) (built: Oct 13 2022 15:59:44) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
root@DS1821:~# php80 -v
PHP 8.0.23 (cli) (built: Dec  6 2022 10:30:21) ( NTS )
Copyright (c) The PHP Group
Zend Engine v4.0.23, Copyright (c) Zend Technologies
root@DS1821:~#

 

[Crashandy]

Bei mir waren es folgende Dateien die ich wieder anpassen musste:
/usr/local/etc/php80/cli/php.ini
/usr/local/etc/php80/cli/conf.d/extension.ini

Ich habe leider bis jetzt noch nicht verstanden, warum man in diesen Dateien noch etwas ändern muss.
Meine wesentlichen Änderungen für eine schnelle Nextcloud habe ich nur in der user_settings.ini eingetragen und das Update auf die aktuelle PHP 8.0 Version hat diese Datei nicht verändert. Daher habe ich in meiner Nextcloud auch keinerlei Veränderungen bemerkt.

Allerdings habe ich auch vollständig auf den Eintrag
'memcache.distributed' => '\\OC\\Memcache\\Redis',
in meiner config.php verzichtet.

Auszug aus meiner config.php

  'memcache.local' => '\\OC\\Memcache\\APCu',
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'redis' =>
  array (
    'host' => '127.0.0.1',
    'port' => '6379',
    'timeout' => '0.0',
  ),
  'filelocking.enabled' => true,

 

[luddi]

Ich habe leider bis jetzt noch nicht verstanden, warum man in diesen Dateien noch etwas ändern muss.

Komischerweise hatte ich vor geraumer Zeit auch versucht alles über die user_settings.ini zu konfigurieren. Aber leider hatte ich keinen Erfolg.
Ich muss das ganze nochmals genauer betrachten, denn wenn es bei dir funktioniert wird es wohl bei mir auch entsprechend laufen müssen.

 

[wolewo]

@Crashandy

ok sieht bei mir ca auch so aus.

root@DS2422:~# php73 -v
PHP 7.3.33 (cli) (built: Mar 16 2022 11:34:11) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.33, Copyright (c) 1998-2018 Zend Technologies
root@DS2422:~# php74 -v
PHP 8.0.23 (cli) (built: Oct 13 2022 17:43:45) ( NTS )
Copyright (c) The PHP Group
Zend Engine v4.0.23, Copyright (c) Zend Technologies
root@DS2422:~# php80 -v
PHP 8.0.23 (cli) (built: Dec  6 2022 10:30:21) ( NTS )
Copyright (c) The PHP Group
Zend Engine v4.0.23, Copyright (c) Zend Technologies
root@DS2422:~#

 

[Crashandy]

Hallo @luddi,

ich habe in meiner user_settings.php nur die nötigsten Einträge stehen, damit z.B. auch der Cronjob im Aufgabenplaner mit "sudo -u http php80 /volume1/web/nextcloud/cron.php" ohne Fehler läuft.

extension = apcu.so
extension = redis.so

[core]
memory_limit = 512M
upload_max_filesize = 512M
post_max_size = 512M

[apc]
apc.shm_size = 512M
apc.enable_cli = 1

Mit php80 -m werden danach auch die Extensions apcu.so und redis.so dort aufgelistet, ohne die user_settings.php leider nicht.

root@DS1821:~# php80 -m
[PHP Modules]
apcu
bcmath
bz2
calendar
Core
ctype
curl
date
dba
dom
exif
fileinfo
filter
ftp
gd
gettext
gmp
hash
iconv
imap
intl
json
ldap
libxml
mailparse
mbstring
mysqli
mysqlnd
openssl
pcntl
pcre
PDO
pdo_dblib
pdo_mysql
pdo_pgsql
pdo_sqlite
pgsql
Phar
posix
readline
redis
Reflection
session
shmop
SimpleXML
soap
sockets
sodium
SPL
sqlite3
ssh2
standard
sysvmsg
sysvsem
sysvshm
tokenizer
xml
xmlreader
xmlwriter
xsl
zip
zlib

[Zend Modules]

Mein Redis läuft jetzt ca. 6 Tage (letzter Neustart der DS) und wird auch ordentlich genutzt.



Damit läuft meine Nextcloud für mich vollkommen zufriedenstellend und ich muss nicht immer bei jedem Update der PHP-Version etwas nachjustieren.

 

[luddi]

@Crashandy Danke für die Details.

ich habe in meiner user_settings.php nur die nötigsten Einträge stehen

Ist bei mir auch ähnlich.

Aber kurioserweise verstehe ich dieses Verhalten nicht...
In der /usr/local/etc/php80/cli/conf.d/user_settings.ini steht z.B. für [core] folgendes:

[core]
memory_limit = 1024M

Somit habe ich das memory limit über die user spezifische ini Datei auf 1024M erhöt.

Über php80 --ini bekomme ich angezeigt, dass genau diese ini Datei auch berücksichtigt wird. Aufgelistet unter "Additional .ini files parsed"

~  $ php80 --ini
Configuration File (php.ini) Path: /usr/local/etc/php80/cli
Loaded Configuration File:         /usr/local/etc/php80/cli/php.ini
Scan for additional .ini files in: /usr/local/etc/php80/cli/conf.d
Additional .ini files parsed:      /usr/local/etc/php80/cli/conf.d/extension.ini,
/usr/local/etc/php80/cli/conf.d/timezone.ini,
/usr/local/etc/php80/cli/conf.d/user_settings.ini

Wenn ich aber die php.ini auf Default lasse, d.h. memory_limit = 128M dann meldet die Nextcloud Instanz immer, dass das Memory Limit zu klein eingestellt ist.
Das kann man sehr einfach nachstellen, indem man den occ einfach ohne jegliche Parameter aufruft.

~  $ occ
The current PHP memory limit is below the recommended value of 512MB.

Stelle ich den Wert direkt in der php.ini auf einen Wert größer oder gleich 512MB dann verschwindet dieser Fehler.
Obwohl eigentlich der memory Wert in der user_settings.ini korrekt gesetzt ist, dieser aber leider nicht berücksichtigt wird.

Also ist es mir ein Rätsel weshalb meine user_settings.ini die anderen Parameter nicht überschreibt. Ich dachte zumindest, dass die user spezifische ini Datei höher prior ist.

Genau aus diesem Grund war ich gezwungen die php.ini direkt anzupassen weil die anderen Einstellungen nicht übernommen wurden.
Was mache ich mit der user_settings.ini wohl falsch?

 

[Crashandy]

Hallo @luddi

Hast Du Dein Nextcloud-Profil richtig eingestellt und aktiviert?

Hier noch meine Einstellungen, mit welchen ich schon lange arbeite.








Eventuell hilt Dir das ja weiter.

 

[luddi]

Hast Du Dein Nextcloud-Profil richtig eingestellt und aktiviert?

Ja selbstverständlich. Auch hier ist das Memory Limit größer 512M eingestellt.

Aber beantwortet meine Frage nicht. Denn komischerweise wird das unser_settings.ini ignoriert, obwohl es als geparsed angezeigt wird mit php80 --ini.

All die Einstellungen die man über das WebUI der DSM machen kann findet man hier.
Es gibt für jedes Profil ein Verzeichnis mit dem Namen einer UUID unter folgendem Pfad:
/var/packages/WebStation/etc/php_profile/

Sieht bei mir so aus:

~  $ ll /var/packages/WebStation/etc/php_profile
total 0
drwxr-xr-x 1 root root 288 Aug  7  2021 .
drwxr-xr-x 1 root root 504 Dec 29 12:02 ..
drwxr-xr-x 1 root root  28 Dec 29 12:02 1655ab00-edac-4176-a9d0-be25ccb4e083
drwxr-xr-x 1 root root  28 Dec 29 12:02 791227a2-2248-4fdd-a680-cc54aa81cc25
drwxr-xr-x 1 root root  28 Dec 29 12:02 db892277-104c-4663-aae4-a79ec0a5ccaa
drwxr-xr-x 1 root root  28 Dec 29 12:02 f0cff57b-bd11-4f2b-a050-ba1923a69a4d

Wie man jetzt herausfinden kann welche UUID für welches Profil zuständig ist hatte ich bereits hier in diesem Beitrag erwähnt.

Also führen wir das hier aus jq '.[] | [.php, .fqdn]' /var/packages/WebStation/etc/VirtualHost.json und bekommen folgende Ausgabe:

[
  "791227a2-2248-4fdd-a680-cc54aa81cc25",
  "fqdn....."
]
[
  "f0cff57b-bd11-4f2b-a050-ba1923a69a4d",
  "fqdn....."
]
[
  "791227a2-2248-4fdd-a680-cc54aa81cc25",
  "fqdn....."
]
[
  "1655ab00-edac-4176-a9d0-be25ccb4e083",
  "fqdn....."
]

Somit kann ich identifizieren, dass es sich bei dem Profil mit der UUID "f0cff57b-bd11-4f2b-a050-ba1923a69a4d" um die Nextcloud Instanz handelt bei der ich User spezifische Einsetllungen vornehmen möchte.

Und das wiederum führt mich exakt zu dieser "user_settings.ini"
/var/packages/WebStation/etc/php_profile/f0cff57b-bd11-4f2b-a050-ba1923a69a4d/conf.d/user_settings.ini

Hier sind nun exakt die Parameter und Werte konfiguriert die von der Standard php.ini abweichen und über die DSM GUI in der Web Station konfiguriert wurden.

Somit habe ich nun zwei user_settings.ini die beide ein Memory Limit größer oder gleich 512M konfiguriert haben, aber dennoch nicht zum tragen kommt.
Leider habe ich den ganzen Zusammenhang auf einer Synology bezüglich php noch nicht komplett begriffen. Es bleibt mir immer noch ein Rätsel.

 

[Tuxnet]

@luddi

Hast du den wer auch in dieser php.ini geändert ?
/usr/local/etc/php80/cli/php.ini
(memory limit )

 

[luddi]

Bei mir waren es folgende Dateien die ich wieder anpassen musste:
/usr/local/etc/php80/cli/php.ini
/usr/local/etc/php80/cli/conf.d/extension.ini

@Tuxnet guck mal hier Post #162

 

[Tuxnet]

@luddi

jap, aber da stand nicht was du alles geändert hast.

Wie sieht es mit der
/volume1/@appstore/PHP8.0/usr/local/etc/php80/cli/php.ini
aus ?

 

[luddi]

jap, aber da stand nicht was du alles geändert hast.

Da hast du recht. Aber hier in diesem Beitrag #168 habe ich mein eigentliches Problem beschrieben.

Wie sieht es mit der
/volume1/@appstore/PHP8.0/usr/local/etc/php80/cli/php.ini
aus ?

Auch das habe ich nochmals geprüft.

Allein für den einfachen Test mit dem "memory_limit" habe ich den Wert in der default INI Datei "/usr/local/etc/php80/cli/php.ini" zurück auf 128M gestellt.
Anschließend den occ Befehl z.B. occ -V aufgerufen.
Hier bekommt man sofort die Fehlermeldung dass der Speicher zu gering gewählt ist.

The current PHP memory limit is below the recommended value of 512MB.

Nun einmal diese INI Datei "/volume1/@appstore/PHP8.0/usr/local/etc/php80/cli/php.ini" angepasst und den Wert entprechend größer 512M gesetzt mit memory_limit = 1024M.
Aber auch hier bekomme ich beim Aufruf des occ Befehls wieder die gleiche Fehlermeldung.

Stelle ich in dieser Datei /usr/local/etc/php80/cli/php.ini den Wert auf 1024M so verschwindet der Fehler bei dem occ Befehl prompt.

Zudem ist ja die binary php80 bzw. /usr/local/bin/php80 ein symbolic link nach "php80 -> /var/packages/PHP8.0/target/usr/local/bin/php80".
Und unter "/var/packages/PHP8.0" findet man wiederum den link hierzu "target -> /volume1/@appstore/PHP8.0".

Das es sich in beiden Fällen um die gleiche binary handelt, wundert es mich auch nicht dass hier beide Male die gleiche INI Konfiguration angezeigt wird.



Mein Ergebnis hierzu ist jedenfalls folgendes.
Sofern das Configuration File "/usr/local/etc/php80/cli/php.ini" auf den Default Werten bleibt, ohne diese Datei zu modifizieren und es werden Werte in der "/usr/local/etc/php80/cli/conf.d/user_settings.ini" angepasst werden diese nicht respektiert.

Also aus meiner Sicht ein recht merkwürdiges Verhalten.

 

[Tuxnet]

@luddi

Ja, synology geht deinen eigenen seltsamen Weg

Endverbraucher feindlich

 

[luddi]

@Tuxnet Das wissen wir doch schon längst alle
Aber es ist schön, dass ich nicht der einzige bin, der hiermit zu kämpfen hat.

Es geht so lange alles gut mit den eigenen Einstellungen bis es wieder ein Update gibt.

 

[Crashandy]

@luddi

Ich habe bei mir noch einmal auf drei verschiedenen DS getestet und komme auf das gleiche Ergebnis.

Hier einmal zum Vergleich der aktuelle und unveränderte [core] Abschnitt in meiner /usr/local/etc/php80/cli/php.ini

[core]
sendmail_path = /usr/bin/ssmtp -t
ignore_repeated_source = 0
xmlrpc_error_number = 0
memory_limit = 128M
output_buffering = 4096
auto_globals_jit = 1
include_path = .:/usr/share/pear
log_errors = On
allow_url_fopen = 1
enable_dl = Off
upload_max_filesize = 32M
default_socket_timeout = 60
enable_post_data_reading = 1
ignore_user_abort = 0
display_startup_errors = 1
sys_temp_dir = /var/services/tmp
extension_dir = /usr/local/lib/php80/modules
hard_timeout = 2
smtp_port = 25
realpath_cache_size = 4096K
register_argc_argv = Off
html_errors = off
max_file_uploads = 20
max_input_nesting_level = 64
disable_classes =
default_mimetype = text/html
expose_php = Off
log_errors_max_len = 1024
post_max_size = 32M
report_memleaks = 1
variables_order = GPCS
short_open_tag = On
upload_tmp_dir = /var/services/tmp
max_execution_time = 240
serialize_precision = -1
docref_ext =
SMTP = localhost
precision = 14
unserialize_max_depth = 4096
implicit_flush = 1
xmlrpc_errors = 0
ignore_repeated_errors = 0
request_order = GP
allow_url_include = 0
disable_functions =
file_uploads = 1
docref_root =
max_input_time = 60
auto_detect_line_endings = 0
max_input_vars = 1000
report_zend_debug = 0
error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED
default_charset = UTF-8
realpath_cache_ttl = 120

Nun habe ich den Wert in meiner /usr/local/etc/php80/cli/conf.d/user_settings.ini hin und her geändert. (511MB, 512MB, 1024MB)

[core]
memory_limit = 511M

Mit dem Ergebnbis:

sudo -u http php80 /volume1/web/nextcloud/occ status
The current PHP memory limit is below the recommended value of 512MB.
  - installed: true
  - version: 25.0.2.3
  - versionstring: 25.0.2
  - edition:
  - maintenance: false
  - needsDbUpgrade: false
  - productname: Nextcloud
  - extendedSupport: false

Erhöhung um nur 1MB:

[core]
memory_limit = 512M

Mit dem Ergebnis:

sudo -u http php80 /volume1/web/nextcloud/occ status
  - installed: true
  - version: 25.0.2.3
  - versionstring: 25.0.2
  - edition:
  - maintenance: false
  - needsDbUpgrade: false
  - productname: Nextcloud
  - extendedSupport: false

Ab 512 MB bis egal wohin, ist der Fehler "The current PHP memory limit is below the recommended value of 512MB." verschwunden. Die user_settings.ini funktioniert, wie sie soll!

Was läuft bei Dir noch anders?

Hast Du eventuell in Deinen Alias- oder PATH-Einstellungen etwas verändert?
Nicht dass dort irgend welche Befehle oder Verzeichnisse aus alten Zeiten enthalten sind.

Hier meine Ausgabe:

root@DS716:~# alias
alias dir='ls -al'
alias grep='grep --color=auto'
alias ll='ls -la'
alias ls='ls --color=auto'

root@DS716:~# $PATH
-ash: /sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin: No such file or directory

Die Nextcloud auf meiner DS716+II tut nun schon seit 2016 ihren Betrieb, immernoch mit der damaligen Datenbank, allerdings nur noch als Testversion. Davor lief dort auch schon ownCloud, mehr recht als schlecht. Auf meiner DS1821+ läuft meine produktive Instanz mit den identischen Werten. Diese Nextcloud hat also diese ganzen alten PHP-Basteleien nicht miterleben müssen und läuft eigentlich sehr stabil.
Updates der PHP-Versionen haben bisher bei mir keine Probleme gemacht. Das Einzige war eben der Umstieg von PHP 7.4 auf PHP 8.0, mit der Einrichtung neuer Nextcloud-Profile in der Web Station und das war es schon.

 

[luddi]

Die user_settings.ini funktioniert, wie sie soll!

Genau so hätte ich es bei mir auch erwartet.

Was läuft bei mir anders? Ja das ist eine gute Frage...

Hast Du eventuell in Deinen Alias- oder PATH-Einstellungen etwas verändert?

Die ~/.bash_aliases habe ich definitiv verändert. Darin liegen Aliase die ich häufig verwende um nicht ständig alles eingeben zu müssen. Ist ja nichts besonderes und das mache ich auf all meinen Unix Systemen.
Darin ist aber auch nichts was in Richtung php deutet.

Klar habe ich für occ auch ein Alias angelegt aber das ist aus meiner Sicht eher unspektaulär ohne Einwirkung auf das hier erwähnte Verhalten.

alias occ='sudo -u http php80 /var/services/web/nextcloud/<fqdn>/occ'

Wobei php80 in den alias nicht umgebogen wurde und zeigt nach wie vor mit which php80 auf die binary "/usr/local/bin/php80".

Die PATH Variable habe ich nicht modifiziert und ist exakt wie auch bei dir gleich.

$ $PATH
-ash: /sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin: No such file or directory

Bei mir läuft Nextcloud auch schon seit Jahren und auch bei mir mit der damals angelegten Datenbank problemlos. Nextcloud selbst scheint ja hier nicht das Problem zu sein, sondern PHP auf Synology und dessen Web Station.

Genau das Verhalten bezüglich der user_setttings.ini würde ich bei mir auch erwarten bzw. mir wünschen.
Denn die user_settings.ini sollte ja die höchste Priorität haben um alle anderen Default Werte überschreiben zu können.
Aber scheinbar wird diese Datei leider nicht respektiert.

Die Funktionalität ist ja definitiv gegeben. Die Nextcloud läuft verlässlich mit PHP 8.0 als Back-End Script Sprache.
Also mir fehlt aktuell auch die Idee woran es auf meinem System liegen könnte, dass es sich komplett daneben verhält.

 

[Tom80]

Hallo zusammen,

ich bekomme bei mir Nextcloud mit php 8.0.23-0103 nicht hin. Wenn ich mich einloggen will erhate ich diesen Fehler:



Wenn ich wieder auf php 74 umstelle und ins Log von Nextcloud schaue sehe ich folgende Fehlermeldungen:


Jemand eine Idee woran das liegt?

folgendes Habe ich angepasst:

Extension Eintrag:
/usr/local/etc/php80/cli/conf.d/extension.ini
Ergänzung um:
extension = apcu (wenn nicht bereits vorhanden)
extension = redis.so

php-fpm.ini Extension Eintrag:
/volume1/@appstore/PHP8.0/misc/php-fpm.ini
Ergänzung um:
extension = redis.so

 

[orlet0815]

extension = apcu.so

Genau so hätte ich es bei mir auch erwartet.

Was läuft bei mir anders? Ja das ist eine gute Frage...

Darf ich mich als weitere Testkarnikel mit ranhängen? Ich schlage mich auf die Seite von Luddi, meine /usr/local/etc/php80/cli/conf.d/nextcloud.ini schien auch keine Auswirkung zu haben. Die Lösung:

root@SynologyNAS:/usr/local/etc/php80/cli/conf.d# ls -la
total 20
drwxr-xr-x 2 root root 4096 Mar 16 11:30 .
drwxr-xr-x 3 root root 4096 Mar 6 15:25 ..
-rw-r--r-- 1 root root 938 Mar 16 11:30 extension.ini
-rw------- 1 root root 163 Mar 16 10:33 nextcloud.ini
-rw-r--r-- 1 root root 33 Jan 6 12:26 timezone.ini
root@SynologyNAS:/usr/local/etc/php80/cli/conf.d# chmod 644 nextcloud.ini
root@SynologyNAS:/usr/local/etc/php80/cli/conf.d# ls -la
total 20
drwxr-xr-x 2 root root 4096 Mar 16 11:30 .
drwxr-xr-x 3 root root 4096 Mar 6 15:25 ..
-rw-r--r-- 1 root root 938 Mar 16 11:30 extension.ini
-rw-r--r-- 1 root root 163 Mar 16 10:33 nextcloud.ini
-rw-r--r-- 1 root root 33 Jan 6 12:26 timezone.ini

Und ja, der Cron läuft ja unter "http", die ganzen "php --ini" laufen (meistens) als "root".