Gerade eben ist mir der Container wieder abgestürzt und wurde neu gestartet. Habe jetzt mal den ulimit -n Wert auf 65536 erhöht. Hoffe das hilft.
2021-10-02T21:50:16.880Z FATAL Unrecoverable error {"error": "accept tcp [::]:28967: accept4: too many open files in system; accept tcp [::]:28967: accept4: too many open files in system", "errorVerbose": "group:\n--- accept tcp [::]:28967: accept4: too many open files in system\n\tstorj.io/drpc/drpcserver.(*Server).Serve:88\n\tstorj.io/storj/private/server.(*Server).Run.func4:217\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57\n--- accept tcp [::]:28967: accept4: too many open files in system"}
Ich benutze für die Storj Festplatte btrfs als Dateisystem. Liegt es vielleicht daran?
Sehr wahrscheinlich ja. Ich hatte mehrere Knoten unter Linux laufen, einer funktioniert noch, hatte aber nie dieses Problem. Ich musste die zulässige Anzahl geöffneter Dateien nicht erhöhen. Sie alle verwendeten ext4, im schlimmsten Fall NTFS.
BTRFS funktioniert nur auf Synology einwandfrei (sie haben ein paar Fehler behoben, aber ihre Fixes nicht für die Community gepostet).
Das ist zwar recht interessant - es geht nicht so sehr um die Dateien an sich, sondern um die Anzahl der offenen Netzwerkverbindungen. Ich habe noch nie so viele offene Verbindungen auf Knoten anderer Speicherknotenbetreiber gesehen. Aber die Verbindung mit btrfs scheint direkt zu sein - wir wissen, dass dieses FS (außer Synology) sehr schlecht mit Dateisperren funktioniert - Uploads auf Ihr System wurden gestartet, aber nie beendet: Topics tagged btrfs
Jetzt können wir der Wissensbox hinzufügen, dass btrfs auch mehr offene Dateien benötigt. Auf dieser Grundlage wird 65536 vielleicht nicht ausreichen, aber ich bezweifle, dass Ihr System mehr Verbindungen als diese Nummer öffnen kann. Es enthält aber auch die Anzahl der regulären Dateien, nicht nur Verbindungen.
Ich würde empfehlen, von btrfs zu ext4 oder zfs zu migrieren, wenn Sie Snapshots so sehr benötigen.
Habe nun die alte btrfs Festplatte formatiert mit dem ext4 Dateisystem. Leider gingen mir meine bisher gespeicherten Storj-Daten verloren, da ich keine Möglichkeit hatte eben Mal 3 TB irgendwo zwischenzuspeichern. Setze nun eine neue Node auf und beginne wieder bei Null. Mal schauen ob es mit ext4 und ulimit -n 8192 besser funktioniert.
Habe nun eine neue Node aufgesetzt. Was mich auch gewundert hatte nun bekam ich als Storj Version die 1.39.5 angeboten. Bei meiner alten Node war die aktuellste Version 1.37.1. Automatische Updates hatten in der Vergangenheit problemlos geklappt. Aber jetzt sehe ich das schon die 1.39.5 draußen ist. Naja, ich hoffe es geht wieder mit ext4 als Dateisystem und einem Clean Install des Containers mitsamt neuer Identität.
Vielleicht sollte man nochmals im Tutorial darauf hinwiesen kein btrfs Dateisystem zu benutzen!
Docker-Versions-Updates erfolgen, nachdem alle Windows / Linux-GUIs aktualisiert wurden:
In einigen Fällen funktioniert es (Synology), aber für schwache Maschinen wie Raspberry Pi3 ist es nicht die beste Wahl. In der Dokumentation für Raspberry heißt es eindeutig, in ext4 zu formatieren: https://support.storj.io/hc/en-us/articles/360026612332