Nextcloud APCu & Redis, Internal Error

  • Hey Leute, vielleicht kann mir wer von euch ja weiterhelfen, ... ich verzweifel gerade an meinem Nextcloud Setting.


    Redis läuft in der neusten Version, compiliert aus source:


    Code
    root@xf0:~# ps ax | grep redis
     3336 pts/0    S+     0:00 grep redis
    22598 pts/0    T      0:00 /bin/sh /etc/init.d/redis_6379 stop
    29366 ?        Ssl    0:03 /usr/local/bin/redis-server 127.0.0.1:6379


    bzw.


    Code
    root@xf0:~# redis-cli
    127.0.0.1:6379> ping
    (error) NOAUTH Authentication required.
    127.0.0.1:6379>



    APCu läuft ebenfalls, wobei es anscheinend egal ist, ob aus dem Source compiliert oder per pecl installiert, ...

    Code
      php=7,2 
      echo "extension = apcu.so" | tee -a /etc/php/$php/mods-available/apcu.ini
      ln -s /etc/php/$php/mods-available/apcu.ini /etc/php/$php/fpm/conf.d/30-apcu.ini
      ln -s /etc/php/$php/mods-available/apcu.ini /etc/php/$php/cli/conf.d/30-apcu.ini
      ln -s /etc/php/$php/mods-available/apcu_bc.ini /etc/php/$php/fpm/conf.d/30apcu_bc.ini
      ln -s /etc/php/$php/mods-available/apcu_bc.ini /etc/php/$php/fpm/conf.d/30apcu_bc.ini


    service php$php-fpm restart


    Nextclud config schaut so aus:



    port steht noch mit drin, obwohl ich nen socket nutze, aber auch über localhost und port 6379 ... gleicher Fehler


    Ich hab folgende Settings probiert:

    APCU und Redis (s.o.) = Internal Error

    Nur Redis als memcache locking = klappt

    Nur APCu als memcahce locking = klappt


    Nur Redis fürs local und locking = fail

    NUr APCu fürs local und locking = fail


    Wenn wer irgend einen Tipp für mich hat, wäre ich sehr dankbar, ... denn mir gehen die Ideen aus :/

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...

  • apcu läuft definitiv, ...



    https://stats.xf0.de/apc.php

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...

  • Redis läuft wie ne 1

    Code
    207:M 21 Mar 16:42:06.118 # Server initialized
    1207:M 21 Mar 16:42:06.118 * DB loaded from disk: 0.000 seconds
    1207:M 21 Mar 16:42:06.118 * Ready to accept connections
    1207:M 21 Mar 16:42:06.119 * The server is now ready to accept connections at /tmp/redis.sock

    Und sonst finde ich nix auffälliges, .. das wurmt mich gerade echt

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...

  • Also, ich bin jetzt soweit, dass APCu und Redis laufen, wenn per Port angebunden, ... aber nicht bper socket, ... was ich eigentlich wollte. werde mir das noch mal angucken, evtl. muss ich noch nen paar rechte setzten :/

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...

  • Ich hab in meiner Instanz nur zur Sicherheit auch nochmal nachgesehen und ich verwende genau diese Konfiguration wie von Ihnen gewünscht. APCu für memcache.local und redis für memcache.locking dafür verwende ich diese config.

    Code
    'filelocking.enabled' => 'true',
      'memcache.local' => '\\OC\\Memcache\\APCu',
      'memcache.locking' => '\\OC\\Memcache\\Redis',
      'redis' => 
      array (
        'host' => '/var/run/redis/redis-server.sock',
        'dbindex' => 1,
        'port' => 0,
        'timeout' => 0.0,
      ),

    Eventuell könnte der Fehler sein das in deiner config'memcache.local' => '\OCMemcache\APCu',verwendet wurde statt 'memcache.local' => '\OC\Memcache\APCu',allerdings mag es sein das Ihnen dieser Fehler bereits aufgefallen ist. Daher wäre meine zweite Vermutung das der Webuser nicht die korrekten Rechte hat einen Socket unter /tmp/redis.sock anzusprechen.

  • allerdings mag es sein das Ihnen dieser Fehler bereits aufgefallen ist. Daher wäre meine zweite Vermutung das der Webuser nicht die korrekten Rechte hat einen Socket unter /tmp/redis.sock anzusprechen.

    Hey, danke erst mal für die Antwort. Der erste Fehler war mir tatsächlich aufgefallen, ... nach ca. 30min haha.

    Ich denke auch, es gibt ein Problem mit den Rechten, Redis lief die meiste Zeit als root, somit hatte nginx bzw. www-data keine Berechtigung für den Socket. Hab mich aber gerade eh selbst ausgesperrt, ... fail2ban für nextcloud sei dank - haha. Hab vergessen, dass ich das pw geändert habe. Naja werde den Server nachher wohl noch mal aufsetzten.

    Wie genau läuft denn Redis bei dir? über den user bzw. die gruppe "redis"? Per /etc/init.d script, oder als system service?

    Hab bis jetzt nur die standard config, bzw. das standard init.d script von Redis verwendet, bzw. um -a <secret> erweitert und -p <port> durch -s <socket> ausgetauscht.

    Habs auch probiert über das script redis-server als redis user laufen zu lassen, ... aber ein su redis -c <cmd> wollte irgendwie nicht.

    Wenn du also ein nettes init.d script hast, oder nen redis.service, wäre ich dir sehr dankbar.

    Das Standard Service Script lief bei mir leider nicht :/

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...

  • Sehr sehr verwirrend, ...

    Also Redis läuft nun und ist per socket erreichbar.

    Hierfür hab ich eben einen user "redis" angelegt und den der www-data gruppe hinzugefügt


    2 Dinge machen mich stutzig:


    1) nach nem reboot waren sowohl ordner, als auch rechte weg, ... muss ich jetz tbei jedem start das hier ausführen?

    Code
      mkdir /var/run/redis
      chown -R redis:www-data /var/run/redis


    2) Warum zur Hölle bekomme ich das Ganze nicht als autostart zum laufen?


    Code
    root@xf0:~# systemctl enable  redis
    Synchronizing state of redis.service with SysV service script with /lib/systemd/systemd-sysv-install.
    Executing: /lib/systemd/systemd-sysv-install enable redis
    update-rc.d: error: redis Default-Start contains no runlevels, aborting.


    Das service script schaut so aus:


    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...

  • Also mein Redis Status Report sieht folgendermaßen aus

    Allerdings sieht mein service file bedeutend anders aus.

    Ich denke das vor allem das Problem mit den nicht beständigen readwrite permissions durch das Service file von mit geregelt werden. Schau dir das Service file an und verändere es je nach Ordner bzw Prozess Priotiät und dann sollte vieles deutlich einfacher gehen.


    Ich frage mich auch wieso /usr/local/bin/redis-server verwendet wird und nicht der klassische unter /usr/bin/redis-server? Hast du redis selbst compiliert?

  • jop, redis hab ich selbst compiliert. Läuft nun alles, lag tatsächlich an den Rechten. Hab speziell dazu noch nen anderen Thread, inkl. Lösung ?

    Thread <<


    Unter Debian ist der Standardpfad /usr/local/bin ... bei Ubuntu sollte es z.B. in /usr/bin liegen. Keine Ahnung, wie apt und Co das regeln ?


    Bin aber auch kein Experte auf dem Gebiet.

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...

  • Unter Debian ist der Standardpfad /usr/local/bin ... bei Ubuntu sollte es z.B. in /usr/bin liegen. Keine Ahnung, wie apt und Co das regeln ?



    Das entscheidet der Paketverwalter und nicht "apt & co" wo welche Datei am Ende landet.

    Generell sagt man: alles was selbst kompiliert wird, landet unter /usr/local

    Wenn du da ein anderes Verzeichnis haben möchtest, musst du vor dem Kompilieren dem ./configure Skript einen Parameter auf den Weg geben, der den Prefix ändert (z.B. /usr oder / statt /usr/local)


    Pakete die du über die System-Repos beziehst sind so gepräfixt, dass sie in /usr landen. Wichtige Systemsoftware wird in / (also leztenendes in /bin) landen.


    Wenn du dir mit den Präfixen unsicher bist, hilft auch die Ausgabe von ./configure --help vor dem Kompilieren.


    Zum anderen Thema: SystemD hat ja die SysV Init Skripte und damit auch den start-stop-daemon abgelöst. Beide erfüllen die gleiche Aufgabe: Prozessduplizierung und Prozessüberlagerung im Hintergrund unter definiertem Arbeitsverzeichnis und definierten Nutzern. Bitte nur entweder oder nutzen, und nicht das eine Nutzen um das andere zu nutzen.


    Es wäre ungefähr so als würdest du MySQL installieren und dir ein Skript unter /etc/init.d/mysqld erstellen mit dem Inhalt: wenn /etc/init.d/mysqld start, dann führe aus: systemctl start mysqld


    Macht wenig Sinn.

  • So, bin jetzt mal dazu gekommen, dein Service file auszuprobieren. läuft bis auf eine Ausnahme super. Danke dafür!


    Mein Problem ist folgendes:

    Code
    .....
    Mär 22 21:18:18 xf0.de systemd[1]: Starting Advanced key-value store...
    Mär 22 21:18:19 xf0.de systemd[1]: redis.service: PID file /var/run/redis/redis.pid not readable (yet?)
    Mär 22 21:18:19 xf0.de systemd[1]: Started Advanced key-value store.

    Hab aber:


    ReadWriteDirectories=-/var/run/redis und RuntimeDirectory=/var/run/redis ...


    Was mache ich falsch?


    Edit: Bzw. wenn ich aus dem service file raus lasse, dann läuft es ohne Probleme. pid file wird ja eh noch mal über die config definiert.
    Würde mich aber dennoch interessieren, wo der Fehler liegt

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...

  • ReadWriteDirectories=-/var/run/redis und RuntimeDirectory=/var/run/redis ..

    RuntimeDirectory wäre in dem Fall nur redis, /var/run wird automatisch ergänzt ;)

    Wenn du /var/run/redis als Directory einsetzt, dann nimmt er eigentlich /var/run/var/run/redis

  • ach verdammt - haha.


    Danke fürs Aufklären! Ne Idee, warum er wegen dem PIDFile meckert?


    Sollte mir echt mal ein bisschen was zu den services anlesen! Bin irgendwie noch die klassischen init.d scripte gewohnt, ...

    Bin zwar auch kein Experte in Sachen bash, aber da hab ich mich im laufe der Zeit mal reingefuchst.


    Muss aber an dieser Stelle zugeben, die Art service script scheint einiges zu vereinfachen und zu verkürzen


    Vielen Dank auf jeden Fall für den ganzen Input hier und im anderen Thread!

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...

  • Prinzipiell braucht SystemD bei Prozessen keine PID-Überwachung. Er merkt sich die PID vom zum startenden Prozess. Wenn kein ExecStop angegeben ist, schickt er einfach ein SIGINT an den gemerkten Prozess.


    In dem File nutzt er jetzt die PID um den Prozess über kill abzuschießen. Einige Prozesse brauchen das so, weil sie nur auf bestimmte Signale reagieren oder anderweitig abgeschaltet werden möchten. Von Prozess zu Prozess unterschiedlich. Bei dir müsste es funktionieren, wenn du ExecStop und PIDFile auskommentierst.


    SystemD schreibt das PIDFile aber nicht, das muss schon Redis machen (über die Redis-Config - deswegen findet er es auch nicht und meckert)


    https://www.freedesktop.org/so…emd.service.html#PIDFile=

    (zzgl. Type und GuessMainPID)