Ipfs: Ipfs 0.4.10 stürzt ab, wenn Dateien größer als 50 MB hinzugefügt werden

Sie können umleiten durch ipfs daemon 2>stderr.log

Ich kann es auch nicht reproduzieren, ich habe etwa 10x60MiB-Dateien ausprobiert.

Es stellt sich heraus, dass ipfs beim Hinzufügen einer großen Datei abstürzt.

Zum Beispiel offizielle Ubuntu-ISO.

Unter MacOS stürzt es ab:

ipfs add ubuntu-16.04.2-desktop-amd64.iso
 488.00 MB / 1.45 GB [=============================>------------------------------------------------------------]  32.92% 20s17:54:27.509 ERROR commands/h: unexpected EOF client.go:247
Error: unexpected EOF

Unter Linux wird ein Fehler ausgegeben, aber der Daemon-Prozess scheint weiter zu laufen:

~/Downloads % ipfs add ubuntu-16.04.2-desktop-amd64.iso 
 32.00 MB / 1.45 GB [=>----------------------------------------------------------------------------]   2.16% 30s17:53:01.534 ERROR commands/h: open /home/user/.ipfs/blocks/SF/put-579906520: too many open files client.go:247
Error: open /home/user/.ipfs/blocks/SF/put-579906520: too many open files

% ipfs daemon
Initializing daemon...
Adjusting current ulimit to 2048...
Successfully raised file descriptor limit to 2048.
Swarm listening on /ip4/127.0.0.1/tcp/4001
Swarm listening on /ip4/172.17.0.1/tcp/4001
Swarm listening on /ip4/172.18.0.1/tcp/4001
Swarm listening on /ip4/172.19.0.1/tcp/4001
Swarm listening on /ip4/172.20.0.1/tcp/4001
Swarm listening on /ip4/172.21.0.1/tcp/4001
Swarm listening on /ip4/172.22.0.1/tcp/4001
Swarm listening on /ip4/172.23.0.1/tcp/4001
Swarm listening on /ip4/172.24.0.1/tcp/4001
Swarm listening on /ip4/192.168.1.107/tcp/4001
Swarm listening on /ip6/::1/tcp/4001
API server listening on /ip4/127.0.0.1/tcp/5001
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080
Daemon is ready
17:53:01.534 ERROR commands/h: err: open /home/user/.ipfs/blocks/SF/put-579906520: too many open files handler.go:285

Ich habe versucht, ein Downgrade auf frühere Versionen durchzuführen, und die einzige Version, die nicht abstürzt, ist 0.4.6 :

~/Downloads % ipfs add ubuntu-16.04.2-desktop-amd64.iso 
added QmTc9mzzoEChP2Wyc4uGWGkkifC99y8o4KmxwVyg18MP76 ubuntu-16.04.2-desktop-amd64.iso
~/Downloads % ipfs version
ipfs version 0.4.6
~/Downloads % pacman -Q go-ipfs
go-ipfs 0.4.6-1

Ich kann dies auch nicht unter macOS 10.12.5 und Ubuntu 16.04 mit ipfs 0.4.10 reproduzieren.

$ truncate -s 500M testfile
added QmV7q5aTmvZtGWja4wpodiUTEpBVWYFkQGRQ8PmJMDPG62 testfile
$

War Ihr Build von ipfs aus dem Quellcode, Ihrem Paketmanager oder der Binärdatei aus dem Web? Versuchen Sie es vielleicht mit einem sauberen ~/.ipfs Verzeichnis, um zu sehen, ob das Problem weiterhin besteht.

Sie stammen alle von Paketmanagern. Jede Ausgabe in den obigen Nachrichten begann mit rm -rf ~/.ipfs && ipfs init .

@Netherdrake, wenn Sie Ihren Daemon mit der Option --routing=none ausführen, schlägt er dann immer noch auf die gleiche Weise fehl?

Mit --routing=none funktioniert es einwandfrei.

Okay, in diesem Fall wird eine Datei hinzugefügt, die dazu führt, dass das Subsystem des DHTs-Anbieters eine Verbindung zu viel zu vielen Peers herstellt. Wenn Sie das Flag --routing=none entfernen und ipfs add --local sollten die Dinge auch gut funktionieren.

Ich arbeite an einem Fix dafür, wir werden hoffentlich etwas in der nächsten Version haben.

Oh, mir ist auch klar, dass dieses Problem im falschen Repository liegt. Verwenden Sie in Zukunft ipfs/go-ipfs, um solche Probleme zu melden.