search

ipfs / kubo

An IPFS implementation in Go
https://docs.ipfs.tech/how-to/command-line-quick-start/
Other
16.17k stars 3.02k forks source link

IPNS mount fails offline #2167

Open Kubuxu opened 8 years ago

Kubuxu commented 8 years ago

Tested in 0.4:

[root@test1 ipfs]# ~/go/bin/ipfs mount
12:51:25.225 ERROR  fuse/ipns: looking up /ipns/QmeRMMbeJvdGp5UALPqWDiwb4Wqn3WG7oK73n2wXJXAGC5: could not resolve name. ipns_unix.go:90
12:51:25.226 ERROR core/comma: error mounting: fusermount: exit status 1 could not resolve name. mount_unix.go:219
chpio commented 8 years ago

also:

$ ipfs daemon --mount
Initializing daemon...
Swarm listening on ...
[snipp]
API server listening on /ip4/127.0.0.1/tcp/5001
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8081
19:03:22.454 ERROR  fuse/ipns: looking up /ipns/Qme96accAunin9tBtytzqLhbqN23nMmnZsdpsoTQYZnEEY: Could not resolve name. ipns_unix.go:98
19:03:22.454 ERROR       node: error mounting: fusermount: exit status 1 mount_unix.go:97
19:03:22.454 ERROR       node: error mounting: Could not resolve name. mount_unix.go:101
19:03:22.455 ERROR     swarm2: swarm listener accept error: peerstream listener failed: closed swarm_listen.go:128
19:03:22.455 ERROR     swarm2: swarm listener accept error: peerstream listener failed: accept tcp 0.0.0.0:4737: use of closed network connection swarm_listen.go:128
19:03:22.455 ERROR     swarm2: swarm listener accept error: peerstream listener failed: closed swarm_listen.go:128
19:03:22.455 ERROR     swarm2: swarm listener accept error: peerstream listener failed: accept tcp [::]:4737: use of closed network connection swarm_listen.go:128
Error: fuse failed to access mountpoint /ipfs

edit: im getting this error with plenty peers connected (63)

hackergrrl commented 8 years ago

@chpio: I think your problem is that the directory /ipfs does not exist. If you want to use the default mount locations you'll need ensure /ipfs and /ipns exist.

chpio commented 8 years ago

@noffle why do you think they do not exist?

$ ll /
total 30424
[...]
drwxr-xr-x   1 thomas root          0 Feb  4 12:33 ipfs/
drwxr-xr-x   1 thomas root          0 Feb  4 12:34 ipns/
[...]
wilkie commented 8 years ago

I've noticed (version 0.4.2) that it will fail to mount if it cannot find another server running. So if I create a private cluster by adding two machines such that they are mutually bootstrapping, I cannot run "daemon --mount" on both. I have to go to one of them, run a normal "daemon"... go to the next one and run "daemon --mount" and then kill the daemon on the first and re-run with "daemon --mount"

Basically, it won't mount unless it is on a network and can talk to at least one other machine. But you can trick it eventually by killing that first machine once you've successfully mounted once. Seems strange, even if seeing the failure in this case is mostly impractical.

jbenet commented 8 years ago

Wow what, that's very odd. If you or someone else can write a sharness test with iptb would help us debug this. On Sun, Sep 4, 2016 at 1:30 AM wilkie notifications@github.com wrote:

I've noticed that it will fail to mount if it cannot find another server running. So if I create a private cluster by adding two machines such that they are mutually bootstrapping, I cannot run "daemon --mount" on both. I have to go to one of them, run a normal "daemon"... go to the next one and run "daemon --mount" and then kill the daemon on the first and re-run with "daemon --mount"

Basically, it won't mount unless it is on a network and can talk to at least one other machine. But you can trick it eventually by killing that first machine once you've successfully mounted once. Seems strange, even if seeing the failure in this case is mostly impractical.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ipfs/go-ipfs/issues/2167#issuecomment-244559205, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIcoYC0wITeGiiGXNq_1GPLu2L93JvKks5qma64gaJpZM4G_mR7 .

Kubuxu commented 7 years ago

Try doing ipfs name publish QmbXBAKDgbhE8HkGuEF4FuQQJej2mxqXtYSMsBPuJDqgjq

It will publish file with ipfs as its content, it might solve the issue.

Isomorph70 commented 5 years ago

Starting the daemon on a laptop without network connection, will cause the daemon to close down.

Start with network disconnected.

# /usr/local/bin/ipfs daemon --mount --enable-gc
Initializing daemon...
go-ipfs version: 0.4.22-
Repo version: 7
System version: amd64/linux
Golang version: go1.12.7
16:15:26.943 ERROR    p2pnode: mdns error:  No multicast listeners could be started discovery.go:46
Swarm listening on /ip4/127.0.0.1/tcp/4001
Swarm listening on /ip6/::1/tcp/4001
Swarm listening on /p2p-circuit
Swarm announcing /ip4/127.0.0.1/tcp/4001
Swarm announcing /ip6/::1/tcp/4001
API server listening on /ip4/127.0.0.1/tcp/5001
WebUI: http://127.0.0.1:5001/webui
16:15:26.952 ERROR  fuse/ipns: looking up /ipns/QmXaoEVUoG4iBHNktwEY3HRutqVzgPoWX7eA6MbxDLc2pA: failed to find any peer in table ipns_unix.go:107
16:15:26.962 ERROR   node: error mounting: failed to find any peer in table mount_unix.go:95
16:15:26.973 ERROR     swarm2: swarm listener accept error: accept tcp6 [::]:4001: use of closed network connection swarm_listen.go:78

Error: failed to find any peer in table`

Start with network connection:

# /usr/local/bin/ipfs daemon --mount --enable-gc
Initializing daemon...
go-ipfs version: 0.4.22-
Repo version: 7
System version: amd64/linux
Golang version: go1.12.7
Swarm listening on /ip4/127.0.0.1/tcp/4001
Swarm listening on /ip4/192.168.1.146/tcp/4001
Swarm listening on /ip6/::1/tcp/4001
Swarm listening on /ip6/fde4:9a1a:b30d:0:bceb:c7e0:5e42:6101/tcp/4001
Swarm listening on /p2p-circuit
Swarm announcing /ip4/127.0.0.1/tcp/4001
Swarm announcing /ip4/192.168.1.146/tcp/4001
Swarm announcing /ip4/84.238.58.235/tcp/4001
Swarm announcing /ip6/::1/tcp/4001
Swarm announcing /ip6/fde4:9a1a:b30d:0:bceb:c7e0:5e42:6101/tcp/4001
API server listening on /ip4/127.0.0.1/tcp/5001
WebUI: http://127.0.0.1:5001/webui

Start with no mount and network disconnected.

# /usr/local/bin/ipfs daemon --enable-gc
Initializing daemon...
go-ipfs version: 0.4.22-
Repo version: 7
System version: amd64/linux
Golang version: go1.12.7
16:20:09.575 ERROR    p2pnode: mdns error:  No multicast listeners could be started discovery.go:46
Swarm listening on /ip4/127.0.0.1/tcp/4001
Swarm listening on /ip6/::1/tcp/4001
Swarm listening on /p2p-circuit
Swarm announcing /ip4/127.0.0.1/tcp/4001
Swarm announcing /ip6/::1/tcp/4001
API server listening on /ip4/127.0.0.1/tcp/5001
WebUI: http://127.0.0.1:5001/webui
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080
Daemon is ready

Conclusion adding --mount and starting without network connection will bring the daemon down.

bmwiedemann commented 3 years ago

I am still seeing this regularly with go-ipfs-0.9.0

Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080
Daemon is ready
2021-08-01T06:30:06.252+0200    ERROR   fuse/ipns       ipns/ipns_unix.go:99   looking up /ipns/k2k4r8l6o7dpp61kq5y1toins4daxtj1pubflnv4cvoeyealqi3lzd1i: could not resolve name
2021-08-01T06:30:06.252+0200    ERROR   node    node/mount_unix.go:95   error mounting: could not resolve name

Could it be that ipfs mount tries to pull in data from IPFS and that it gets garbage-collected reguarly, so will be missing again on next start?

Edit: ipfs name publish $CID did help.

apps4uco commented 2 years ago

Hi, the process terminates sporadically this is the output:

$ ipfs daemon --mount
Initializing daemon...
go-ipfs version: 0.12.0
Repo version: 12
System version: amd64/linux
Golang version: go1.16.12
...
2022-02-21T10:20:15.421-0500    ERROR   fuse/ipns   ipns/ipns_unix.go:99    looking up /ipns/k51qzi5uqu5dl0ssb1jkmv1q85srr58ipi9ikqc5ofex8iis32cfkswm6ea21r: could not resolve name
2022-02-21T10:20:15.421-0500    ERROR   node    node/mount_unix.go:95   error mounting: could not resolve name

Error: could not resolve name

and the process just exits.

It would be great if you could look into it and have retry with exponential backoff in the daemon process.

This bug is 6 years old (if its the same issue).

nessdoor commented 2 years ago

I can reproduce the exact same behaviour on 0.12.2. Starting once without the --mount option and then restarting with the mounts enabled fixed the issue, but this is really annoying, especially if you have remote nodes.

deane-c64 commented 1 year ago

can say this exact same thing is happening to me in 0.18.1 . Same as @nessdoor it is fixed with removing--mount & using ipfs daemon alone. Then 'ipfs mount'! Be lovely to resolve this bug!