New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
odd error message from dht code #4237
Comments
|
47 in ASCII is a forward slash ( |
|
I get this message twice every time I publish to IPNS, I'm publishing to a key that I'm pretty sure was generated as ed25519. |
|
Yeah I get this message too from the ipfs daemon whenever I run "ipfs name publish ...something...". The ipfs-name-publish command just hangs without producing any output and I have to kill it with ctrl-c. Ipfs publish / ipns seems to be just broken for me. (Using ipfs version 0.4.11) |
|
@agentme how long did it hang before you killed it? it should have a hard timeout at 30 seconds |
|
Oh, I think I just didn't wait that long. I tried it now and it does eventually finish successfully. Whoops. I think I assumed the red error message in my ipfs daemon terminal happening at the same time was actually an error fatal to the request. Is the command supposed to take a long time to run? I thought it would be quick like add. I've even seen it slightly over 30 seconds: |
|
Its not supposed to take that long, but it is right now. We've identified some issues very recently in the dht handlers; Apparently some really overloaded nodes are taking forever to respond to requests, which causes clients to wait (like we're seeing here). tracking issue: libp2p/go-libp2p-kad-dht#88 |
|
Had the same error printed by daemon: https://discuss.ipfs.io/t/v0-4-11-ipfs-publish-creates-error-webui-not-loading/1194 |
|
Same here, ipfs 0.4.11, the daemon crashes and restarts after 1minute and few seconds (more or less). |
|
@aventrax your daemon shouldnt be crashing. Do you have any other information? Stack traces or other log output? |
|
@whyrusleeping How can I provide you theese logs? I have the service starting as a normal user by systemd. I don't know where the logs are, probably under ~/.ipfs/ ? |
|
@aventrax logs are printed out to stderr |
|
|
@whyrusleeping Using strace ipfs daemon I've got (cutting the first part..): |
|
Inizializing ipfs with another user on the same VPS results the same. I'm thinking about hitting a limit on the vps, perhaps open files or something like this, because the daemon crashes after 200+ peers, it never crash before.. |
|
I have added brand new vps, also that throws the mentioned error with invalid cid version number, running version 0.4.11 on ubuntu 64bit. I am also getting this in combination with ipfs name publish command. |
|
So, this error isn't causing any bugs (it indicates that we're doing something fishy but it isn't likely to cause any problems, I think). According to c372d79, we switched to switch to using CIDs as DHT keys. However, we didn't really; we just switched to CIDs for provider records. We still use paths for public keys and IPNS records. This does bring up a good point... we should be consistent dammit! We now have a mix of unicode paths ( |
|
is there any update on this issue? It seems using ipfs version 0.4.11 on windows, can't publish anything. While i tried the following... It did said it was published after more than 1 minute. Whatsoever i got the following errors on my daemon And i can't "ls" the new hash, can't access it through the http api. can't do anything. Also Resolves that, after more than 2 minutes. |
|
Not really. This is, effectively, just a noisy error message that you should ignore (although that's still a bug). |
|
This should be demoted to a warning in the next release. (0.4.12) |
|
@whyrusleeping would you like a PR for that? It's still an error. |
|
I've updated my comment, Also while browsing throught http api And still doesn't show anything, loads infinitely |
|
Sorry my mistake, i got it working. |
|
Still an |
|
from zeb on irc: |
|
I'm also getting the errors:
This is on a completely fresh linux 64 bit machine, 0.4.3, the only command run on the daemon has been "ipfs swarm peers" for monitoring purposes. The error times look regular, is this IPNS? Is IPNS published when there is nothing to publish? |
|
@mattseh the likely root of the issue is someone else publishing an ipns entry with something that we don't recognize as a CID. this isnt really an error in that it causes incorrect daemon behaviour, but its something that we're not exactly handling properly. |
|
@whyrusleeping the problem is that IPNS entries aren't CIDs (actually, I'm pretty sure that only provider records are CIDs). See #4237 (comment). |
whyrusleeping commentedSep 17, 2017
Got this on my node, havent really investigated much.
The text was updated successfully, but these errors were encountered: