Parallel calls to init may fail to start the daemon

[dpordomingo]

It happens from time to time, but sometimes running srcd init ends with could not start daemon.

The way that I was able to reproduce it more often was running it

$ srcd init
INFO[0000] removing container srcd-cli-bblfshd          
INFO[0000] removing container srcd-cli-daemon           
INFO[0001] removing container srcd-cli-gitbase          
INFO[0001] starting daemon with working directory: /projects/src/github.com/dpordomingo/pga-performance/pga/repos/00 
ERRO[0002] could not start daemon:
    could not create srcd-cli-daemon:
    could not create container srcd-cli-daemon:
    Error response from daemon:
    Conflict. The container name "/srcd-cli-daemon" is already in use by container "3045e594ec70033f7297a06fa5429ecc1afe2f9d3818b4781529ebcafaed1d5c".
    You have to remove (or rename) that container to be able to reuse that name.

while running in a different tab

watch --interval=1 'srcd sql "SHOW PROCESSLIST;"'

it seems that there can be a race condition when the daemon is initialized from different places.

imo init process should happen only once at the same time, and wait in case other command is doing other things on background.

[carlosms]

For context, sql implies an init if the daemon is not running.

I guess we could create a lock file in ~/.srcd and fail one of the parallel init, or do one after the other. But I'm not sure this is a use case we want to support.

[dpordomingo]

I think that init should not collide with other attempts of initializing the daemon.

[smacker]

I agree with Carlos that this is a very weird case and that it can be fixed by lock file. I would keep the issue but put a super-low priority on it.