Closed phpmac closed 3 months ago
Can someone give more context about the criticality of this issue, please?
This bug here seems to be obnoxious logging rather than some other underlying issue. It's going to be reverted in the next go-libp2p release (and will get propagated into the following kubo release) https://github.com/libp2p/go-libp2p/issues/2762.
I built the error with docker. You can try it.
If I need to provide detailed information, it will be a few days later.
2024 年 5 月 6 日星期一 20:04, pablomendezroyo @.***(mailto:2024 年 5 月 6 日星期一 20:04, pablomendezroyo < 来信:
Can someone give more context about the criticality of this issue, please?
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>
Basically ipfs is trying to close a port which has already terminated by itself or some other reason.. also stopping ipfs deamon is not closing the ports properly i think (use netstat to see). After restarting pc , launching ipfs daemon , adding a file , ipfs.io works fine for few minutes or few tries.. after that 504 Gateway timeout it gives on any further uploads. My theory is that the ports binding is not good and is lost resulting misbehaviour after few tries/minutes for launching ipfs for first time after restarting pc.
This should be fixed in v0.29
Not fixed yet, still have the bug.
Indeed, the upstream project had some hiccups. Reopening as we need https://github.com/libp2p/go-libp2p/pull/2861
Still faced this issue when using Kubo (containerized in version 0.29.0-3f0947b).
Checklist
Installation method
ipfs-desktop
Version
No response
Config
No response
Description