Skip to content
This repository has been archived by the owner on Dec 1, 2022. It is now read-only.

Security lock error #29

Closed
UnkindPartition opened this issue Oct 16, 2018 · 4 comments
Closed

Security lock error #29

UnkindPartition opened this issue Oct 16, 2018 · 4 comments

Comments

@UnkindPartition
Copy link
Contributor

http://stackage-head.s3-website-us-east-1.amazonaws.com/build/nightly-2018-09-26-2e1df7c1556fc2fb6f7449ae07a382c57a0a536c/th-data-compat/overview.html

user error (hTryLock: lock already exists: /home/circleci/.stack/indices/Hackage/hackage-security-lock)
@UnkindPartition
Copy link
Contributor Author

See commercialhaskell/stack#3055

Particularly this:

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

Probably that's what happens to us as well

@UnkindPartition
Copy link
Contributor Author

See fpco/stackage-curator#66

UnkindPartition added a commit that referenced this issue Oct 23, 2018
@UnkindPartition
Try latest hackage-security as a possible solution for #29
00e5cae
UnkindPartition added a commit that referenced this issue Oct 23, 2018
@UnkindPartition
Try latest hackage-security as a possible solution for #29
29a7ebc
UnkindPartition added a commit that referenced this issue Oct 23, 2018
@UnkindPartition
Try latest hackage-security as a possible solution for #29
d373a1e
UnkindPartition added a commit that referenced this issue Oct 24, 2018
@UnkindPartition
Try latest hackage-security as a possible solution for #29
561ce3e
UnkindPartition added a commit that referenced this issue Oct 24, 2018
@UnkindPartition
Try latest hackage-security as a possible solution for #29
e87c4f0
UnkindPartition added a commit that referenced this issue Oct 25, 2018
@UnkindPartition
Try latest hackage-security as a possible solution for #29
e8eb9ca
UnkindPartition added a commit that referenced this issue Oct 25, 2018
@UnkindPartition
Try latest hackage-security as a possible solution for #29
cf09f48
UnkindPartition added a commit that referenced this issue Oct 25, 2018
@UnkindPartition
Try latest hackage-security as a possible solution for #29
fe295b8
@UnkindPartition
Copy link
Contributor Author

The good news is that the above commit seems to have fixed the issue.

Now, it appears we no longer even acquiring the lock when performing stack update (which is where the problem happened initially).

The version of stack in both cases should be the same, and the version of hackage-security is very close too. It would be nice to get to the bottom of this. Was stack perhaps compiled differently? Or is it a very recent change in hackage-security?

UnkindPartition added a commit that referenced this issue Oct 26, 2018
@UnkindPartition
Revert "Try latest hackage-security as a possible solution for #29"
da435c1 
This reverts commit fe295b8.

Instead, try a simple 'stack update' before running stackage-curator,
so that 'stack unpack' inside stackage-curator doesn't need to do it.
@UnkindPartition
Copy link
Contributor Author

Should be fixed now — see the above commit.

UnkindPartition added a commit that referenced this issue Nov 12, 2018
@UnkindPartition
Revert "Try latest hackage-security as a possible solution for #29"
6975ce2 
This reverts commit fe295b8.

Instead, try a simple 'stack update' before running stackage-curator,
so that 'stack unpack' inside stackage-curator doesn't need to do it.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@UnkindPartition