"Exception ~/.stack/indices/Hackage/hackage-security-lock: createDirectory: already exists"

[sjakobi]

I got the following exception after aborting the previous stack command with Ctrl+C:

~/s/hackage-server (master|✔) $ stack init --ignore-subdirs
Looking for .cabal or package.yaml files to use to init the project.
Using cabal packages:
- hackage-server.cabal

Selecting the best among 10 snapshots...

Missing some cabal revision files, updating indices
Selected mirror https://s3.amazonaws.com/hackage.fpcomplete.com/                                 
Downloading timestamp                                                                            
Exception /home/simon/.stack/indices/Hackage/hackage-security-lock: createDirectory: already exists (File exists) when using mirror https://s3.amazonaws.com/hackage.fpcomplete.com/
Selected mirror http://hackage.fpcomplete.com/                                                   
Downloading timestamp                                                                            
Exception /home/simon/.stack/indices/Hackage/hackage-security-lock: createDirectory: already exists (File exists) when using mirror http://hackage.fpcomplete.com/
Selected mirror http://objects-us-west-1.dream.io/hackage-mirror/                                
Downloading timestamp                                                                            
Updating package index Hackage (mirrored at https://s3.amazonaws.com/hackage.fpcomplete.com/) .../home/simon/.stack/indices/Hackage/hackage-security-lock: createDirectory: already exists (File exists)
~/s/hackage-server (master|✔) $ stack --version
Version 1.4.1, Git revision 036ca52fed01ec51e5e537e4c6cc557ec7363784 (dirty) (4658 commits) x86_64 hpack-0.17.0

My guess is that the lock directory wasn't removed during the exception cleanup for the previous command.

rmdir ~/.stack/indices/Hackage/hackage-security-lock fixed the immediate problem.

[mgsloan]

I've opened an upstream issue for this on the hackage-security tracker: haskell/hackage-security#186

[ezyang]

@sjakobi Did you by any chance C-c the process twice? Trying to figure out if you are triggering GHC's hard quit mechanism.

[sjakobi]

Did you by any chance C-c the process twice?

I'm pretty sure I did! Thanks for investigating!

[ezyang]

OK, that's consistent with the behavior you saw: on the second C-c, the RTS hard quits so bracket handlers don't get the opportunity to run. Not much we can do here.

[sjakobi]

@ezyang Ah, that's good to know! I think I was under the impression that the first C-c didn't do anything so I C-c'd again. Not sure how much time stack should reasonably take to process the first C-c.

[ezyang]

Yeah, it's definitely tough for users to know about this. I've had some applications where teardown takes some time; I find it helps to emit something like "Application is shutting down, please be patient..." which helps convince people (mostly me) to not C-c again until it is really taking a long time.

[sjakobi]

@ezyang it appears that stack just (incorrectly) swallowed the C-c in this situation (see #3073).

[mgsloan]

Seems like the exception swallowing is happening in hackage-security - haskell/hackage-security#187

This happened to me twice in two days, on a CI server where multiple stack builds happen in parallel

[andrewdoh]

@sjakobi ran into this issue as well. this line worked, thanks.
rmdir ~/.stack/indices/Hackage/hackage-security-lock