Add a grace period to obtain the lock to avoid "Error: lock /data/ipfs/repo.lock: someone else has the lock"

[meermanr]

Checklist

• My issue is specific & actionable.
• I am not suggesting a protocol enhancement.
• I have searched on the issue tracker for my issue.

Description

I want to use IPFS to distribute an OS update image to 100s of hosts in my compute estate, but I've been seeing a lot of the following error if I run, say, ipfs pin add ... while the ipfs daemon is still initialising:

Error: lock /data/ipfs/repo.lock: someone else has the lock

I was about to add some logic to backoff and retry in my Ansible playbook when it occurred to me that the ipfs CLI itself could do implement this and become easier to script this sort of usage.

I propose that instead of failing immediately the ipfs CLI should display a warning and then wait for the lock to become available. The warning could be displayed periodically, perhaps every 10s. I imagine my use case might look something like this:

# ipfs pin add /ipfs/bafyb4igq3a5ufgoaofhvmaxhhy7w4afpg6wpy42h646rro4fzds7d4sapm
WARNING: lock /data/ipfs/repo.lock: someone else has the lock. Retrying...
WARNING: lock /data/ipfs/repo.lock: someone else has the lock. Retrying...
WARNING: lock /data/ipfs/repo.lock: someone else has the lock. Retrying...
NOTICE  lock /data/ipfs/repo.lock: obtained
pinned bafyb4iftumpemeammdgxbxxkxoocftvgyzs3ljcdtvjipqrmltexpz7sbu recursively

In this session the lock was not available for somewhere between 30-40s. I would expect the warnings to be written to STDERR so as not to interfere with tools which may rely on the output of the CLI's STDOUT.