Meine Storj Node startet permanent neu

Node Operators troubleshooting
,
1

Ich bin seit über einem Jahr bei Storj als Node Operator tätig. Seit einer Woche startet meine Node (also der Docker Container in dem Storj läuft) alle paar Minuten bis Stunden ständig neu. Betriebsystem ist ein Ubuntu Server mit Docker.
Was kann ich dagegen tun?

2

Poste mal deinen Log Output: docker logs storagenode 2>&1 --tail 200

3

4

Das ist nur ein Ausschnitt und der sieht so aus als ob alles funktioniert.
Leite doch den Output einmal in eine Datei um und lass es laufen bis er wieder neu startet. Vielleicht sieht man dann eine Fehlermeldung: How do I redirect my logs to a file? - Node Operator

5

Ich habe die config.yaml angepasst. Bekomme aber irgendwie kein Log file in dem Output Ordner?

6

Dann stimmt vielleicht mit deiner config.yaml etwas nicht oder es gibt ein Permissionproblem, dass der Prozess nicht auf den Ordner zugreifen kann.

7

oder Sie haben den Container nach dem Ändern von config.yaml nicht neu gestartet

8

Nachdem der Storj Container eine Zeit lang wieder gut lief. Fangen nun wieder die Probleme an. Meist läuft der Container nicht mal 2 Stunden durch.
Hier mein Log mit dem Fehler:

2021-09-30T14:59:00.994Z ERROR pieces:trash emptying trash failed {"error": "pieces error: filestore error: context canceled", "errorVerbose": "pieces error: filestore error: context canceled\n\tstorj.io/storj/storage/filestore.(*blobStore).EmptyTrash:154\n\tstorj.io/storj/storagenode/pieces.(*BlobsUsageCache).EmptyTrash:310\n\tstorj.io/storj/storagenode/pieces.(*Store).EmptyTrash:367\n\tstorj.io/storj/storagenode/pieces.(*TrashChore).Run.func1:51\n\tstorj.io/common/sync2.(*Cycle).Run:92\n\tstorj.io/common/sync2.(*Cycle).Start.func1:71\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57"} 2021-09-30T14:59:01.018Z ERROR piecedeleter could not send delete piece to trash {"Satellite ID": "12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S", "Piece ID": "PJPWDZIMITXCQ2PJAQPEFIUQ4X2UE7VT7OFRXZTSXFVQGAMN2NJA", "error": "pieces error: pieceexpirationdb: context canceled", "errorVerbose": "pieces error: pieceexpirationdb: context canceled\n\tstorj.io/storj/storagenode/storagenodedb.(*pieceExpirationDB).Trash:112\n\tstorj.io/storj/storagenode/pieces.(*Store).Trash:354\n\tstorj.io/storj/storagenode/pieces.(*Deleter).deleteOrTrash:185\n\tstorj.io/storj/storagenode/pieces.(*Deleter).work:135\n\tstorj.io/storj/storagenode/pieces.(*Deleter).Run.func1:72\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57"} 2021-09-30T15:00:37.412Z FATAL Unrecoverable error {"error": "accept tcp [::]:28967: accept4: too many open files; accept tcp [::]:28967: accept4: too many open files", "errorVerbose": "group:\n--- accept tcp [::]:28967: accept4: too many open files\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"}

Muss ich nun wieder eine neue Node aufsetzen oder kann man das Problem irgendwie beheben? Folgenden Fehler habe ich auch öfters:

2021-09-30T15:00:58.996Z	ERROR	piecestore	failed to add bandwidth usage	{"error": "bandwidthdb: database is locked", "errorVerbose": "bandwidthdb: database is locked\n\tstorj.io/storj/storagenode/storagenodedb.(*bandwidthDB).Add:60\n\tstorj.io/storj/storagenode/piecestore.(*Endpoint).beginSaveOrder.func1:711\n\tstorj.io/storj/storagenode/piecestore.(*Endpoint).Upload:430\n\tstorj.io/common/pb.DRPCPiecestoreDescription.Method.func1:209\n\tstorj.io/drpc/drpcmux.(*Mux).HandleRPC:33\n\tstorj.io/common/rpc/rpctracing.(*Handler).HandleRPC:58\n\tstorj.io/drpc/drpcserver.(*Server).handleRPC:102\n\tstorj.io/drpc/drpcserver.(*Server).ServeOne:60\n\tstorj.io/drpc/drpcserver.(*Server).Serve.func2:95\n\tstorj.io/drpc/drpcctx.(*Tracker).track:52"}
2021-09-30T15:01:03.381Z	ERROR	collector	unable to delete piece	{"Satellite ID": "12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs", "Piece ID": "EISWVDRSVSDT2G3352VN5WGNDFUCFW5UOGGYYYXE2MCEQSILPNFA", "error": "pieces error: filestore error: file does not exist", "errorVerbose": "pieces error: filestore error: file does not exist\n\tstorj.io/storj/storage/filestore.(*blobStore).Stat:103\n\tstorj.io/storj/storagenode/pieces.(*BlobsUsageCache).pieceSizes:239\n\tstorj.io/storj/storagenode/pieces.(*BlobsUsageCache).Delete:220\n\tstorj.io/storj/storagenode/pieces.(*Store).Delete:299\n\tstorj.io/storj/storagenode/collector.(*Service).Collect:97\n\tstorj.io/storj/storagenode/collector.(*Service).Run.func1:57\n\tstorj.io/common/sync2.(*Cycle).Run:92\n\tstorj.io/storj/storagenode/collector.(*Service).Run:53\n\tstorj.io/storj/private/lifecycle.(*Group).Run.func2.1:87\n\truntime/pprof.Do:40\n\tstorj.io/storj/private/lifecycle.(*Group).Run.func2:86\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57"}
9

Könntest du einmal auf deinem Host ulimit -a ausführen, genauso wie einmal im container via
docker exec -it storagenode /bin/sh dann ebenfalls ulimit -a und beide Ausgaben hier posten?

1 Like
10

ulimit -a auf Host:

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 15108
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 15108
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

ulimit -a in Container:

core file size (blocks)         (-c) 0
data seg size (kb)              (-d) unlimited
scheduling priority             (-e) 0
file size (blocks)              (-f) unlimited
pending signals                 (-i) 15108
max locked memory (kb)          (-l) 64
max memory size (kb)            (-m) unlimited
open files                      (-n) 1024
POSIX message queues (bytes)    (-q) 819200
real-time priority              (-r) 0
stack size (kb)                 (-s) 8192
cpu time (seconds)              (-t) unlimited
max user processes              (-u) 15108
virtual memory (kb)             (-v) unlimited
file locks                      (-x) unlimited
11

Erhöhen Sie diesen Wert mindestens 5-mal.

12

Auf dem Host oder im Container? Habe jetzt mal den Wert im Host und im Container geändert. Müsste es nun wieder laufen ohne Abstürze? Weil ich verliere jeden Tag Uptime :o(

13

Ja, er sollte. Der Online-Score wird nach 30 Tagen online wiederhergestellt.
Sie haben richtig gehandelt, um die zulässige Anzahl von Dateien sowohl auf dem Host als auch auf dem Container zu erhöhen.

14

Ich habe den Wert mittels ulimit -n 8192 geändert. Leider vergisst Linux die Einstellung nach ein paar Minuten wieder. Wie kann ich den Wert nun dauerhaft ändern. Benutze Ubuntu Linux Server 20.04.

15
16

Ich habe Ihre Anleitung probiert leider ist die Änderung nicht permanent. Habe jetzt die /etc/security/limits.conf bearbeitet und folgende Einträge reingesetzt:

* soft nofile 8192
* hard nofile 524288

Anschließend noch die Datei /etc/pam.d/common-session bearbeitet und ganz unten den Eintrag:

session required pam_limits.so

reingesetzt. Sogar 'nen Reboot durchgeführt die Werte bleiben bei 1024. Egal was ich mache?!

17

Musste noch die /etc/systemd/user.conf und /etc/systemd/system.conf mit der folgenden Zeile ergänzen:

DefaultLimitNOFILE=8192

Nach einem neuen Reboot hat er die neuen Werte übernommen. Für Host als auch Container ;o)

18

Es freut mich zu hören, dass Sie es geschafft haben, ihn davon zu überzeugen, es richtig zu machen!

19

Meine Node läuft nun schon seit 5,5 Stunden unterbrechungsfrei. So lange lief sie die letzten Monate nicht durch. Sollte ich den ulimit -n Wert noch höher setzen wegen der Zukunft?

20

Es ist schwer zu sagen. Normalerweise müssen Sie nicht einmal mehr als 1024 erhöhen.