IIchan Archives — Электроника и ПО

Файл: Ipfs-logo-1024-ice-text.png -(42 KB, 600x600, Ipfs-logo-1024-ice-text.png)

ipfs Чии Сб 16 июля 2016 17:00:33 No.182522

Здесь, вроде, есть народ, который в этой хреновине разбирается?
У меня тут случилась такая проблема:
$ ipfs daemon --mount
Initializing daemon...
Swarm listening on /ip4/127.0.0.1/tcp/4001
Swarm listening on /ip4/192.168.0.5/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
16:38:04.294 ERROR  fuse/ipns: looking up [мой ipns]: Could not resolve name. ipns_unix.go:98
16:38:04.294 ERROR       node: error mounting: Could not resolve name. mount_unix.go:101
Error: Could not resolve name.
Когда я только её установил — всё работало нормально. Всё, что надо, монтировалось, то, что туда добавлялось, было доступно из сети. Потом народ стал жаловаться, что не видит, чего я туда выкладываю. И вот сейчас получил вот это. Поиск по гуглу вида "ipfs mount could not resolve name" показывает, что проблема возникает не только у меня, но решения не даёт. Я нашел только банальные советы типа "проверить конфиги" (в порядке), или выложить в ipfs что-то типа "Hello world" (никакого эффекта).

Есть идеи, как с этим можно бороться?
Удалить всё и пересоздать ноду заново? Не хотелось бы терять всё, что там лежит, да и не факт, что поможет…

Чии Сб 16 июля 2016 18:01:14 No.182523

Для начала запустить как IPFS_LOGGING=info ipfs daemon --mount и посмотреть на какие-нибудь предупреждения.
Если не поможет, то ipfs daemon --mount --debug.

Данная ошибка может выдавать всего в двух файлах: https://github.com/ipfs/go-ipfs/blob/master/namesys/dns.go и https://github.com/ipfs/go-ipfs/blob/master/namesys/namesys.go. Она там как ErrResolveFailed фигурирует.
Так что она может выдавать только при проблемах синтаксиса у имени, что будет фигурировать в логах, или при каких-то проблемах с DNS.

Чии Сб 16 июля 2016 18:46:09 No.182524

>>182523

>запустить как IPFS_LOGGING=info ipfs daemon --mount и посмотреть на какие-нибудь предупреждения

Их там есть. Для начала, после вызова mount:

18:23:54.235 WARNI    swarm2: swarm listener accept error: write tcp 127.0.0.2:4001->127.0.0.1:4001: write: broken pipe swarm_listen.go:128
18:23:54.944 WARNI    swarm2: swarm listener accept error: write tcp 127.0.0.2:4001->127.0.0.1:4001: write: broken pipe swarm_listen.go:128

Затем много строк вида

18:23:55.304  INFO       dht: received provider <peer.ID [бла]> for Qm[бла-бла-бла] (addrs: [список]) handlers.go:276
18:23:55.631  INFO   bitswap: Bitswap ReceiveError: EOF bitswap.go:375

После котортых получаем вот это:

18:24:06.598 WARNI   namesys: RoutingResolve get failed. routing.go:146
18:24:06.598 WARNI   namesys: No resolver found for [мой ipns] namesys.go:84
18:24:06.598 WARNI   namesys: Could not resolve [мой ipns] base.go:21
18:24:06.598 ERROR fuse/ipns: looking up [мой ipns]: Could not resolve name. ipns_unix.go:98
18:24:06.598 ERROR      node: error mounting: Could not resolve name. mount_unix.go:101

Ну и в конце:

18:24:06.633 WARNI    swarm2: swarm listener accept error: peerstream listener failed: accept tcp [::]:4001: use of closed network connection swarm_listen.go:128
18:24:06.633 WARNI    swarm2: swarm listener accept error: peerstream listener failed: accept tcp 0.0.0.0:4001: use of closed network connection swarm_listen.go:128

(но это, наверное, уже следствие предыдущих)

>>	Чии Сб 16 июля 2016 19:17:17 No.182525 >>182524 >swarm_listen.go …И кстати, файла с таким названием я в их репозитарии не нашел. И таки пребываю в недоумении, к чему именно оно не может получить доступ, и что с этим делать. Порты, вроде, свободны…

>>	Чии Сб 16 июля 2016 19:35:46 No.182526 >>182525 > И кстати, файла с таким названием я в их репозитарии не нашел. Потому что он там уже в скомпилированном виде. https://github.com/ipfs/go-libp2p/blob/master/p2p/net/swarm/swarm_listen.go#L128 мимо-вообще-не-слышал-про-ipfs

Чии Сб 16 июля 2016 21:07:18 No.182527

>>182526
Угу, спасибо, только понятнее для меня происходящие не стало… Кажется, теперь видно, что эта ошибка относится к коннекту с другими пирами, но откуда оно берётся…

>>182524

>broken pipe

А если его с ключем --debug запустить, оно вместо этого пишет connection reset by peer. Но суть дела остаётся прежней:

Монтирует (вроде бы).

Выдает все ошибки и варнинги, указанные в >>182524.

Отмонтирует обратно.

Алсо

>dht: received provider <peer.ID [бла]> for Qm[бла-бла-бла] (addrs: [список]) handlers.go:276
>bitswap: Bitswap ReceiveError: EOF bitswap.go:375

похоже, к делу отношения не имеет, а являет собой обычный процесс нормальной работы этой системы.

Чии Сб 16 июля 2016 21:37:06 No.182528

>>182527
Хрен его знает, честно говоря.
Кажется, что оно пытается зачем-то приконектиться к самому себе.
Но самое главное, что ему не удается построить сеть, через которую происходит резолв чего-то необходимого для работы.

Похоже, тебе все-таки придется обращаться в багтрекер к разработчикам. Они, скорее всего, смогут сказать что-то более определенное.

>>	Чии Сб 16 июля 2016 22:35:37 No.182529 >>182528 >тебе все-таки придется обращаться в багтрекер к разработчикам Мда. Похоже на то. Жуткая всё-таки глюкала этот самый ipfs… Ну, спасибо, хотя бы, за попытку…

>>	Чии Вс 17 июля 2016 11:21:59 No.182544 >>182522 > Error: Could not resolve name. https://github.com/ipfs/go-ipfs/issues/2383 > не видит, чего я туда выкладываю У тебя внешнего ip нету.

Чии Вс 17 июля 2016 21:13:36 No.182556

>>182544

>внешнего ip нету.

Ну… В каком-то смысле да. Прямое соединение с внешним интернетом имеется только у 192.168.0.1. Нода же, как можно видеть из логов, поднята на 192.168.0.5. Но, вроде, всё по локальной сети раздается и маршрутизируется без проблем.

И к тому же — ведь вначале всё работало же! Так что с ним случилось?
И вообще, странно это, если оно не может соединяться изнутри локалок. Это как, на роутере ipfs-ноду поднимать, что ли?

Чии Вс 17 июля 2016 22:21:08 No.182557

>>182556
Когда ты только запускаешь эту штуку то она соединяется с бутстрап нодами, которые по совместительству еще и шлюз. В этот период все работает. Потом соединение с этими нодами отваливается, а обратно к тебе они уже пробится не могут через нат и скачать с тебя соответственно тоже.

Попробуй включить utp транспорт, попробуй пробросить 4001 порт, попробуй подключится к cjdns (bootstrap ноды его используют), для соединения между собой можно ipv6 использовать.

Чии Пн 18 июля 2016 01:48:13 No.182558

>>182522
Попробуй поменять номера портов. Может помочь.
Конкретных регламентированных разработчиком портов, на которые стоит менять адреса с дефолтных 4001/5001/8080, увы, нет. Так что делай, если совесть не будет мучать.
>>182557

>для соединения между собой можно ipv6 использовать

Будут проблемы при подключении к нему тех, у кого IPv6 нет.

Чии Пн 18 июля 2016 13:35:51 No.182560

Так. Я не знаю, что произошло. Я ничего не делал. Но сейчас оно, внезапно, смонтировалось нормально.

И это плохо, вообще-то. Потому что непонятно, почему оно отваливалось, когда оно отвалится в следующий раз, и что с этим делать.

>>182557

>Потом соединение с этими нодами отваливается, а обратно к тебе они уже пробится не могут через нат и скачать с тебя соответственно тоже.

Возможно, я что-то неправильно понял, но при запуске ipfs daemon без mount — список пиров быстро становился весьма крупным. Т.е. по крайней мере с ними оно коннектилось.

>Попробуй

Попробую… когда снова отвалится. Вот только поможет ли?

>>182558

>Попробуй поменять номера портов.

Эм… Я, вообще-то, более чем уверен, что никто никакие порты из этого списка на пути не блокирует.
Или такая операция заставит ее "встряхнуться" и начать как-то перестраивать себя? И порты предлагается менять всякий раз, когда оно начнёт таким образом тупить?

>>	Чии Пн 18 июля 2016 13:47:45 No.182561 Алсо >внешнего ip нету Подкрути уже NAT - пробрось нужные порты на машину, на которой работает демон IPFS.

>>	Чии Пн 18 июля 2016 23:57:44 No.182566 >>182560 Оно от неработающей связи, от неработающего mount как отписались в баге выше помогает ipfs publish.