search

ipfs / kubo

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

Subcommand to wait until IPFS daemon is ready #6455

Open ghost opened 5 years ago

ghost commented 5 years ago

I have a systemd service file for ipfs that works pretty well, although the daemon isn't immediately ready. If I try to do anything with the service immediately after launch, I get this: Error: cannot acquire lock: Lock FcntlFlock of /srv/ipfs/.ipfs/repo.lock failed: resource temporarily unavailable

Is there some kind of a subcommand that I can add to my systemd service with ExecStartPost that would only return once ipfs is ready to go? ipfs wait_for_daemon, something like that.

Thank you!

eingenito commented 5 years ago

Hey @teran-mckinney. I don't think there is any ipfs command (intentional or incidental) that will do what you want. If a command needs to talk to a running daemon it tries to do so immediately and then errors out if it can't. It's a good idea tho. You could also hack a command together to wait for the daemon to listen on one of its sockets.

I'm curious - how long does it take for your ipfs daemon to complete startup do you think?

ghost commented 5 years ago

Thank you for your reply!

I don't think it's that long, maybe 5-10 seconds. I could certainly do a sleep but it's not my preference unless there's no other option. And yeah, I thought about writing a script to do it but figured I'd bring it up here since I think more than just myself could benefit from something like this.

eingenito commented 5 years ago

I just noticed there is a simple go program to do this in the project: https://github.com/ipfs/go-ipfs/tree/master/thirdparty/pollEndpoint. The project uses it in some of its integration tests. It's not a replacement for including the facility in the ipfs binary itself obviously as it has to be built and installed manually. And it's not necessarily better than a simple shell script.

Even if the facility were built into ipfs it would still have to do basically the same thing, poll for an endpoint to respond, but it could be smarter about picking up config.

ghost commented 5 years ago

Nice, that could work for now and be a starting point for the main tool. Thanks for finding that!