Unbekannter Fehler - Cloud bricht zusammen Too many Connection

Liebe Community Sehr geehrte Damen und Herren vom Support,
wir haben jetzt seit 2 Jahren die Cloud laufen und nach jedem Update habe ich Beschwerden.

Die neue berechtigte beschwerde lautet, nach einer unbekannten Zeit X bricht die Cloud auf allen Endgeräten zusammen die Cloud ist nicht bedienbar. Als Administrator konnte ich die Ursache noch nicht ermitteln, aber die Cloud und Endgeräte produzieren massiv viele Connection die nicht beendet werden, das heißt mit dem Befehl plesk db “SHOW FULL PROZESSLIST” sind tausende Einträge die nicht beendet werden. Ja ich habe die Prozesse auf 1000 erhöht nachdem bei Version 27 die Probleme aufgetreten waren.

Nachdem ich den Server Neu Starten muss weil auf Plesk hab ich kein Zugriff sind4 prozesse sichtbar das ist normal. Das heißt je länger die Cloud läuft um so mehr Prozesse werden nicht sauber gestoppt und meistens ist das über mitternacht der Fall.

Poste Configs und Logs. Vor allem vom Webserver/PHP von Apache2/nginx.

Beispiel das war noch vor dem letzten Update Version 27

Das geht leider nur im Beschräktem Rahmen, gerne helfe ich Ihnen bei dem nicht mehr Kontrolliebaren Problem mit aber die Logs kann ich hier definitif nicht posten ich brauch da ein anderes Medium “nicht Öffentlich”

Das ist eine Fehlermeldung von vielen

Ich habe eine Virtuelle Maschine auf VM Ware ESXI 7.X
Basis Betriebssystem ist Ubuntu 22.04

Intel(R) Xeon(R) E-2236 CPU @ 3.40GHz (10 core(s))
Plesk Obsidian v18.0.59_build1800240229.10 os_Ubuntu 22.04
Ubuntu 22.04.4 LTS

Eine weitere Fehlermeldung

2024-03-17 16:47:28 Error XXIP AdresseXX AH01071: Got error ‘Primary script unknown’

PHP 8.2.16
memory limit 2048
max execution time 30
max input time 90
post max size 100M
upload max filesize 100M
opchache.enable on Standard
disable function opchache get status

PHP FPM Einstellung
pm.max_children 1200
pm.max request 5000
pm ondemand Standard

Zusätliche Konfiguration vom Plesk:
; Additional directives added by Plesk Optimization Settings
; DO NOT MODIFY THIS FIELD BECAUSE IT WAS GENERATED AUTOMATICALLY
; SO ALL YOUR CHANGES WILL BE LOST THE NEXT TIME THE BLOCK IS GENERATED.
opcache.enable=1
opcache.enable_cli=1
opcache.huge_code_pages=1
opcache.interned_strings_buffer=64
opcache.jit = 1255
opcache.jit_buffer_size = 128M
opcache.max_accelerated_files=10000
opcache.max_wasted_percentage=15
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1
opcache.revalidate_path=0
opcache.validate_timestamps = 0
apc.enable_cli = 1
; Additional directives added by Plesk Optimization Settings

Bin nicht sicher ob ich das überlesen haben, aber nutzt ihr Redis?
https://docs.nextcloud.com/server/stable/admin_manual/configuration_server/caching_configuration.html#memory-caching

Das nimmt viel Last von der Datenbank.

Und die Datenbank selbst kann man auch optimieren:
https://docs.nextcloud.com/server/stable/admin_manual/configuration_database/linux_database_configuration.html#parameters
Die Standardeinstellungen sind nicht unbedingt für Nextcloud optimiert. Und wenn für einige Queries auf die Festplatte gecached wird, wird die Datenbank sehr langsam.

  • Ursache ist in Klärung
<?php
$CONFIG = array (
  'passwordsalt' => 'XXX',
  'secret' => 'XXX',
  'trusted_domains' => 
  array (
    0 => 'localhost',
    1 => 'cloud.XXX.de',
    2 => 'www.cloud.XXX.de',
  ),
  'datadirectory' => '/var/www/vhosts/cloud.XXX.de/.nextcloud/data/XXX',
  'dbtype' => 'mysql',
  'version' => '28.0.3.2',
  'overwrite.cli.url' => 'https://localhost',
  'dbname' => 'XXX_XXX',
  'dbhost' => 'localhost:3306',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'XXX_XXX',
  'dbpassword' => 'XXX',
  'installed' => true,
  'filelocking.enabled' => false,
  'memcache.locking' => '\\OC\\Memcache\\Redis',
  'redis' => 
  array (
    'host' => 'localhost',
    'port' => 6379,
    'timeout' => 0.0,
    'password' => '',
  ),
  'instanceid' => 'XXX',
  'twofactor_enforced' => 'true',
  'twofactor_enforced_groups' => 
  array (
    0 => 'XXX',
  ),
  'twofactor_enforced_excluded_groups' => 
  array (
    0 => 'XXX',
    1 => 'XXX',
    2 => 'XXX',
  ),
  'mail_smtpmode' => 'smtp',
  'mail_smtpsecure' => 'tls',
  'mail_sendmailmode' => 'smtp',
  'mail_from_address' => 'cloud',
  'mail_smtphost' => 'smtp.XXX.de',
  'mail_smtpauthtype' => 'LOGIN',
  'mail_smtpauth' => 1,
  'mail_domain' => 'XXX',
  'mail_smtpport' => '587',
  'mail_smtpname' => 'cloud@XXX',
  'mail_smtppassword' => 'XXX',
  'log_type' => 'errorlog',
  'default_language' => 'de',
  'default_locale' => 'de_DE',
  'default_phone_region' => 'DE',
  'maintenance' => false,
  'updater.release.channel' => 'stable',
  'theme' => '',
  'loglevel' => 2,
);

Das wäre die Config.PHP alles wo ich davon ausgehe das jemand den Zugriff aud das gerät versucht habe ich durch XXX ersetzt.

Nach einer unbekannten Zeit X, nachdem keiner mehr aktiv die Cloud nutzt, habe ich diese Anzeige. Hier stellt sich die Frage was heißt das? Was ist Statistics warum werden die Prozesse in der Datenbank nicht beendet und warum kommen an dieset Stelle immer mehr Prozesse???

Ist das ein Fehler den Ihr schnell beheben könnt, muss hier an der Datenbank in der Config was umgestellt werden? Ich habe die Konfiguration nach der Schulung von Udemy angepasst mit der Hoffnung das die Cloud sauber läuft.

Wie gross ist denn deine oc_authtoken Tabelle?

Theoretisch ist es nur ein Eintrag pro verbundenem Gerät/Anwendung. Es gab einen Bug-Report, wo diese Tabelle extreme Grösse annimmt. Nicht sicher, ob das richtig gelöst wurde:

Die Datenbank-Logs, sind das die Slow-Query-Einträge (man kann Queries loggen, die länger als xx Sekunden benötigen).

Die Community bietet nur kostenlosen und unverbindlichen Support hier an. Von Nextcloud kannst du eine Enterprise Version buchen:

Also die Tabelle oc_authtoken zeigt mir 770 Datensätze mit 0.0021 Sekunden dauer an. Ich kann sagen das die Cloud von ungefähr 60-65 Personen genutzt wird tendenz steigend.

Nachtrag ich habe eine Person in der Liste mit abnormalen vielen Einträge und unbekannter Browser - Ich lösch die mal raus.

Es könnte sein, dass das Gerät einer Person sehr viele fehlerhafte Zugriffe macht. Du solltest daher nicht nur die Einträge löschen, sondern evtl. auf die Person zugehen. Erstelle auch gerne eine Statistik, wie viele der Einträge z. B. von einer Person stammen.

Nachtrag ich habe diese Person Kontaktiert und erfahren, das diese nicht mit Webbrowser und nicht mit der APP arbeitet.

Er nutzt die OCS-API mit einer selbstentwickelten System.
Der Fehler wird quasi über die Schnittstelle verursacht.

Bitte dem Entwickler Team mitteilen und Prüfen lassen!
Das heißt die Prozesse werden nicht in der SQL Abfrage sauber beendet und bleiben bestehen.

Wenn ihr einen Fehler in der OCS API oder anderswo in Nextcloud vermutet und das den Entwicklern mitteilen wollt, eröffnet bitte ein Issue auf GitHub: Issues · nextcloud/server · GitHub

Das erscheint mir jetzt nicht extrem viel, wenn es jetzt tausende Einträge wären.

Kommt ein bisschen drauf an, was dieses System macht, je nachdem kann man da schon einen Server auslasten. Kann aber auch was sein, was unerwartet viele Resourcen benötigt und ein Fehler in Nextcloud ist.

Wie gesagt, wir sind kein offizieller Support. Du musst das selbst melden, am besten eine genauere Beschreibung, was ihr mit den automatisierten Anfragen macht, damit die Entwickler das nachvollziehen können.

1 Like

@DJ-Chrischi
Naja. Ich könnte mir vorstellen, dass einfach das Script deiner eigenen Entwickler zu oft läuft. Baut doch mal einen Zähler ein. Vielleicht werden irgendwelche Rückkehr-Codes falsch interpretiert. Ich könnte mir vorstellen, dass der Fehler nicht in der Nextcloud-Software, sondern nur an der falschen Anwendung der API liegt. Vielleicht kann man seine eigene Nextcloud auch so konfigurieren, dass diese Art von Fehler eleminiert werden. Stichwort Brute-Force.

2 Likes

Weiss jemand wie ich die Verwendung von selbstentwickelten Anwendungen (die Nutzung der API) prinzipiell verbieten kann?

Man könnte den User-Agent blocken oder über robots.txt, aber das lässt sich leicht umgehen. Evtl. falls die API-Endpunkte nicht für die normalen Clients genutzt werden, könnte man die blockieren. Oder evtl. time limits etc.

Ich würde zunächst mal den Kompromiss suchen, mal schauen, warum das alle lahmlegt. Evtl. gibt es wirklich irgendwo einen Fehler, oder mit einer besseren Konfiguration könnte sich das vermeiden lassen. Für Nutzer können solche Skripte und direkte Zugänge via API ein großer Vorteil sein, und wenn du es schaffst, dass sie nicht alles lahmlegen, kann es dir auch egal sein.