Nextcloud mit PHP 8.2: Erweiterung Redis wird immer wieder deaktiviert

[luddi]

Ohne Redis im Docker und bei aktivierter Zeile in der config.php
'memcache.distributed' => '\OC\Memcache\Redis',
gibt es sofort eine Fehlermeldung:

Hier möchte ich nochmals genauer darauf eingehen.

D.h. wenn Redis nicht im Docker läuft und der memcache.distributed gesetzt ist bekomme ich die Fehlermeldung?

Bei mir läuft nämlich Redis als Docker und Nextcloud ist nativ unter

/var/services/web/nextcloud/
├── <Instanz_No1>
└── <Instanz_No2>

Und genau in dieser Konstellation bekomme ich den besagten Fehler auch sobald memcache.distributed in der config gesetzt ist.

 

[luddi]

im Redis Status reichlich Keys in der Datenbank angelegt werden.

Bei dir sieht man im Status deines Screnshots die "Keys in store db0".
Weshalb sehe ich das nicht auf meiner Statusseite?

 

[Crashandy]

Weshalb sehe ich das nicht auf meiner Statusseite?

Und genau so sah es bei mir auch aus, bevor ich den Eintrag am Ende der Datei "php-fpm.ini" hinzugefügt habe.
Siehe meinen Beitrag #15 weiter oben.

Auch ohne die Zeile 'memcache.distributed' => '\OC\Memcache\Redis', funktioniert Redis mit diesem Eintrag in der "php-fpm.ini" perfekt. Es geht ja primär nur darum, dass die Datenbank nicht mehr für die file-locking Einträge verwendet wird.

Hier noch ein Screenshot aus einer anderen Nextcloud. Ich habe es nun auf 6 verschiedenen nativen Nextcloud-Instanzen auf verschiedenen DiskStationen eingerichtet. Zwei davon haben Redis nicht im Docker, sondern als Paket-Installation von hgy59.

 

[luddi]

Deinen Beitrag #15 habe ich bereits gesehen und auch bei mir ist es genau wie beschrieben konfiguriert.
Und auch die user_settings.ini ist bei mir exakt, wie in deinem Beitrag konfiguriert.





Woran könnte es noch liegen?

 

[Crashandy]

Woran könnte es noch liegen?

Dann lass uns noch weitere Eigenschaften und Einstellungen vergleichen.
Ich habe die Redis Stats jetzt auf allen meinen nativen Instanzen erfolgreich darstellen können und die Tabelle "oc_file_locks" bleibt jetzt auch überall leer.
Manchmal habe ich auch viele Tage mit der Fehlersuche verbracht und am Ende war es so, dass man eine winzige Kleinigkeit vergessen hat.

Zuerst hier die Eigenschaften meiner Dateien.



Hast Du in der config.php auch diese Zeile drin?

  'filelocking.enabled' => true,

PHP Profil für Nextcloud

Erweiterungen aktivieren (ab Nextcloud 26 auch sysvsem notwendig):
bcmath, bz2, curl, exif, ftp, gd, gettext, gmp, iconv, imagick, intl, ldap, mailparse, mysqli, openssl, pdo_mysql, posix, soap, sockets, sodium, ssh2, sysvsem, zip, zlib

Erweiterte Einstellungen -> FPM

FPM-Modus:                    Dynamisch
Max. Prozesse:                102 -> 120    (Standard DS716+II 102; DS1618+ 409; DS720+ 76; DS920+ 102; DS1821+ 409; DS723+ 102)
Kindprozesse bei Start:       2 -> 12
Mindestanzahl Prozesse:       2 -> 6
Maximalanzahl Prozesse:       4 -> 18

Erweiterte Einstellungen -> Kern

Name                            Wert
memory_limit                    128M -> 4G
post_max_size                   32M -> 10G
upload_max_filesize             32M -> 10G
apc.enable_cli                  0 -> 1
apc.shm_size                    32M -> 128M
apc.ttl                         0 -> 7200
opcache.enable_cli              0 -> 1
opcache.interned_strings_buffer 8 -> 64
opcache.jit                     tracing (1254) -> 1255 (5 = gesamtes Script optimieren)
opcache.jit_buffer_size         0 -> 256M
opcache.max_accelerated_files   10000 -> 100000
opcache.memory_consumption      128 -> 512
opcache.revalidate_freq         2 -> 60
output_buffering                4096 -> 0
max_execution_time              240 -> 3600
max_input_time                  60 -> 3600

Falls Du diese Einstellungen in ähnlicher Form bei Dir vorfindest und noch immer dieser Fehler erscheint, dann müssten wir mit MariaDB weitermachen. Da habe ich noch Optimierungen gemacht und die Zeitzonentabellen befüllt.

In phpMyAdmin von MariaDB 10 einloggen.
Datenbank z.B. "nextcloud"
SQL-Befehl(e) in Datenbank nextcloud ausführen:

SELECT @@global.time_zone, @@session.time_zone

Ergebnis sollte hier bei beiden sein: 'Europe/Berlin'
Wenn dort z.B. `SYSTEM` steht, dann könnte es schon das Problem sein.

Mehr fällt mir jetzt erst einmal nicht ein.

 

[luddi]

Das ist schon mal super, danke für die ganzen Hinweise. So auf den ersten Blick würde ich an den Einstellungen nichts vermissen. Ist ziemlich gleich bzw. ähnlich.
Ich werde das einmal bei Gelegenheit im Detail überprüfen und zu guter letzt auch die sql Datenbank anschauen.

Ich werde über das Resultat berichten.

 

[OdinsAuge]

Ergebnis sollte hier bei beiden sein: 'Europe/Berlin'
Wenn dort z.B. `SYSTEM` steht, dann könnte es schon das Problem sein.

Ich habe bei beiden SYSTEM stehen, wie kann ich das ändern?

 

[Crashandy]

Für die meisten Anwendungen sollte es eigentlich auch reichen, jedoch benötige ich zwingend für jAnrufmonitor diese richtigen Zeitzonen.
Die Zeitzonen-Tabellen sind bei MariaDB nach der Installation immer leer.
Eine Anleitung zum Befüllen der Tabellen findest Du hier.

Du kannst auch einfach in der Konsole den folgenden Befehl ausführen.

/volume1/@appstore/MariaDB10/usr/local/mariadb10/bin/mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql

Warning: Unable to load '/usr/share/zoneinfo/leapseconds' as time zone. Skipping it.

Diese Warnung kann ignoriert werden, da das System keine Schaltsekunden erhält.

Im Anschluss müsste nach dem Befehl

SELECT @@global.time_zone, @@session.time_zone;

an beiden Stellen 'Europe/Berlin' stehen.

Wichtig!
Erst jetzt, darf in der my.cnf im Abschnitt "Basics" die folgende Zeile am Ende eingefügt werden.
/volume1/@appconf/MariaDB10/my.cnf
default-time-zone = 'Europe/Berlin'

 

[Tom80]

Hallo,

ich habe die Einstellungen wie in Beitrag 15 angegeben vorgenommen, aber der folgende Fehler besteht weiterhin.

Es gibt einige Warnungen bei deiner Systemkonfiguration.

• Die Datenbank wird zum Sperren von Transaktionsdateien verwendet. Um die Leistung zu verbessern, richte bitte, sofern verfügbar, Memcache ein. Weitere Informationen findest du in der Dokumentation ↗.

Wenn ich versuche die Redis-Statistik aufzurufen, sehe ich nur das:


Was habe ich vergessen?

Gruß Tom

 

[Tom80]

Ich sehe jetzt auch die Statistik, allerdings auch ohne den Eintrag "Keys in store db0".
Der Fehler ist auch weg, daher ist das für mich so ok.

 

[orlet0815]

Die Datei "php-fpm.ini" liegt in dem folgenden Ordner.
/volume1/@appstore/PHP8.2/misc/php-fpm.ini

Moin. Du aktivierst damit das redis-php-modul an der WebStation der Synology vorbei, richtig? Übersteht diese manuelle Überschreibung auch diverse Synology-Updates?

Was spricht dagegen, die WebStation die Arbeit machen zu lassen, indem die wie unter #3 beschrieben die json-Datei bearbeitet wird? Diese Änderung könnte zwar auch bei einem Update überschrieben werden, sie beeinflusst aber nur die GUI der Webstation, nicht das eigentliche Einstellungsscript, welches mit der GUI verändert wird. Und dieses wurde ja geschaffen, als man die Option in der GUI aktiviert hat.

Ansonsten eine feine Zusammenfassung. Einzige Ergänzung: ich würde unter /usr/local/etc/php82/cli/conf.d/ nicht user_settings.ini nehmen. PHP-CLI geht sowieso durch alle Dateien in conf.d. Also kann man seine speziellen Einstellungen auch in eine z.B. nextcloud.ini packen, da weis man später, für wen man diese Änderungen eingebaut hat.

 

[Crashandy]

Übersteht diese manuelle Überschreibung auch diverse Synology-Updates?

Bei einer Paketaktualisierung von PHP 8.2 muss dieser Eintrag in die "php-fpm.ini" wieder neu hinzugefügt werden und das ist bei mir dann die einzige Änderung.

Was spricht dagegen, die WebStation die Arbeit machen zu lassen, indem die wie unter #3 beschrieben die json-Datei bearbeitet wird?

Das ist natürlich auch ein möglicher Weg, jedoch geht dieser Eintrag leider auch bei einer Aktualisierung von PHP 8.2 verloren. Wichtig ist eben nur, dass man sich eine Art Dokumentation für die Änderungen anlegt.

ich würde unter /usr/local/etc/php82/cli/conf.d/ nicht user_settings.ini nehmen.

Da ich PHP 8.2 nur für meine Nextcloud verwende, ist es für mich egal. Wer es mag, kann die Datei natürlich auch nextcloud.ini nennen.

 

[Crashandy]

Aktueller Stand nach Update auf mehreren DiskStationen

Durch die Aktualisierung von PHP 8.2 wird nichts an dem Eintrag im separaten Nextcloud-Profil geändert.
Aktualisierung auf DSM 7.2.2 mit anschließender Aktualisierung auf PHP 8.2.21 auf meiner DS1821+.
Die Nextcloud funktionierte nach der Aktualisierung tatsächlich noch fehlerfrei.
Speicherort des separaten Nextcloud-Profils:
/volume1/@appconf/WebStation/php_profile/individueller_Key_des_Profils/conf.d/user_settings.ini

Bei einer Paketaktualisierung von der Web Station und auch von PHP 8.2 muss der Eintrag aus Beitrag #3 in der extension_list.json wieder neu hinzugefügt werden.
Speicherort der Datei: /volume1/@appstore/PHP8.2/misc/extension_list.json

Begründung:
Da der Eintrag vorher einmal in der GUI aktiviert wurde, bleibt dieser Eintrag in dem Nextcloud-Profil der Web Station erhalten und funktioniert vorerst noch fehlerfrei. Spätestens nach einer Änderung und der erneuten Speicherung des Profils würde die user_settings.ini wieder neu geschrieben werden und der Eintrag "redis" ist verschwunden.

Das bedeutet, dass der absolute Königsweg für die Redis-Funktionalität, der von @Fusion in Beitrag #3 beschriebene Eintrag in der extension_list.json wäre. Somit ist auch in der GUI von der Web Station die Erweiterung "redis" sichtbar und kann dort aktiviert oder deaktiviert werden. Eine Modifizierung der php-fpm.ini ist bei dieser Variante nicht mehr notwendig.

Beitrag noch einmal bearbeitet, da bei einer Aktualisierung auf einer DS720+ und DS723+ die extension_list.json vorher nicht modifiziert war, sondern nur die php-fpm.ini mit dem Redis-Eintrag am Ende.
Es bleibt also dabei, dass auch bei der Aktualisierung vom Paket PHP 8.2 ausschließlich die Datei extension_list.json modifiziert werden muss.