IPFS HTTP services should start early and wait while the node is booting up · ipfs/kubo#8557

(1 comment) (0 reactions) (0 assignees)Go (13,906 stars) (2,725 forks)batch import

P3exp/intermediatehelp wantedkind/enhancement

Description

Checklist

This is a bug report, not a question. Ask questions on discuss.ipfs.io.
I have searched on the issue tracker for my bug.
I am running the latest go-ipfs version or have an issue updating.

Installation method

built from source

Version

go-ipfs version: 0.10.0
Repo version: 11
System version: amd64/linux
Golang version: go1.17.1

Description

IPFS has a "long" lag time of a few seconds upward to many tens of seconds before starting it's HTTP listeners when starting ipfs daemon.

This is an issue because while the node is starting if you attempt to use a command it will just fail because the port is closed.

That not the "commun" way services works, most services that average linux users encounter starts their listeners very early but doesn't enter any accept loop yet. That mean you can dial the API while the service is starting and it will automatically wait until the service is started.

You could argue about how commun is that behaviour, but I still belive it's way better as the current situation give a pretty good time where you can try to do a command and it will fail because IPFS daemon holds the lock but the API isn't started yet.

What I propose will make thoses commands wait that IPFS is actually started and then proceed as normal.

(technically my proposition is racy it's just in term of nano seconds to miliseconds instead of seconds to tens of seconds but appart from tying the datastore lock to a unix socket existing I don't see how we can atomically lock the datastore to the openning of the API)

Contributor guide

Tech stack: gorest api
Domain: backendperformance
Issue type: bug
Difficulty: 3
Estimated time: 1-3 hours
Activity status: stale
Clarity: mostly clear
Prerequisites: Go programmingIPFS architecture
Newbie friendliness: 40
Research direction: The issue proposes to start HTTP listeners early and delay the accept loop until the node is fully booted. The contributor should examine the daemon startup process in the repository, specifically in files such as 'cmd/ipfs/daemon.go' and the core HTTP server code (likely in 'core/corehttp/'). They need to implement a mechanism to open the listener socket early but defer accepting connections until the datastore and other services are ready. The issue suggests a pattern similar to holding the datastore lock until the API socket is opened, but that is not atomic. More research is needed to find a reliable way to signal readiness. There are no linked pull requests, so the contributor should start a new approach.