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

Created on 12 Mar 2017 · 10Comments · Source: commercialhaskell/stack

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.

upstream issue

Source

sjakobi

👍1

Most helpful comment

I've opened an upstream issue for this on the hackage-security tracker: https://github.com/haskell/hackage-security/issues/186

mgsloan on 14 Mar 2017

👍2

All 10 comments

I've opened an upstream issue for this on the hackage-security tracker: https://github.com/haskell/hackage-security/issues/186

mgsloan on 14 Mar 2017

👍2

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

ezyang on 17 Mar 2017

👍1

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

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

sjakobi on 17 Mar 2017

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.

ezyang on 17 Mar 2017

@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.

sjakobi on 17 Mar 2017

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.

ezyang on 17 Mar 2017

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

sjakobi on 19 Mar 2017

Seems like the exception swallowing is happening in hackage-security - https://github.com/haskell/hackage-security/issues/187

mgsloan on 19 Mar 2017

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