hackage-server icon indicating copy to clipboard operation
hackage-server copied to clipboard

Killing a Docker container running hackage-server causes it to fail to start again

Open lexi-lambda opened this issue 9 years ago • 2 comments

I’m not currently sure if this is an issue with hackage-server, acid-state, Docker, or something else, but I figured I would report it all the same. Here are the steps I’ve used to reproduce the issue:

$ docker run -d --name hackage-server -v hackage-state:/runtime/state hackage-server
$ docker kill hackage-server
$ docker run -it -v hackage-state:/runtime/state hackage-server
hackage-server: Guessing public URI as http://f5143d805ae8:8080
(you can override with the --base-uri= flag)
state/db/Users/open.lock: Locked by 5: resource busy

I’m not sure what is causing that error, but it seems to be the opposite of what I would expect: my understanding was that the whole point of acid-state is to be able to recover from ungraceful shutdown.

lexi-lambda avatar Oct 07 '16 17:10 lexi-lambda

That's a false alarm raised by acid-state. Here's how you can reproduce this in current master.

Terminal 1:

$ docker build . -t siddhu/hackage-server
$ docker run -it -p 8080:8080 --name hackage-server siddhu/hackage-server /bin/bash
# hackage-server run --static-dir=datafiles

Terminal 2:

$ docker kill hackage-server
$ docker start hackage-server
$ docker attach hackage-server
# hackage-server run --static-dir=datafiles

My guess is that the function doesProcessExist in acid-state is not handling some condition correctly. Running the server again should be a quick workaround in this case.

ghost avatar Sep 23 '17 03:09 ghost

I ran into this issue as well. As a temporary fix I changed the command run by docker to:

bash -c "rm state/db/*/*/*.lock; rm state/db/*/*.lock; hackage-server run --static-dir=datafiles"

malob avatar Nov 17 '18 23:11 malob