Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can no longer compile two things at once with 2.1.1 from 1.9.3 #4876

Closed
dten opened this issue Jun 17, 2019 · 10 comments
Closed

Can no longer compile two things at once with 2.1.1 from 1.9.3 #4876

dten opened this issue Jun 17, 2019 · 10 comments

Comments

@dten
Copy link

@dten dten commented Jun 17, 2019

It used to be fine compiling a project in different .stack-work directories or different projects at the same time.
After upgrading to stack 2.1.1 I can't even build different projets at the same time let a long the same project.

Just get this error until the first build has finished. After that I can try build the second project.
This makes stack unusable on CI, and pretty awful to use locally with multiple projects.

Encountered error while migrating Pantry database:
    SQLite3 returned ErrorProtocol while attempting to perform prepare "PRAGMA journal_mode=WAL;": locking protocol
Please report this on https://github.com/commercialhaskell/stack/issues
As a workaround you may delete Pantry database in /home/david/.stack/pantry/pantry.sqlite3 triggering its recreation.
@dten dten changed the title Can no longer compile two thing at once with 2.1.1 from 1.9.3 Can no longer compile two things at once with 2.1.1 from 1.9.3 Jun 17, 2019
@dten
Copy link
Author

@dten dten commented Jun 17, 2019

Tried this on some colleagues' machines, seems like it's to do with WSL 😿 p.s. i'm on WSL Ubuntu 18.04

@dten
Copy link
Author

@dten dten commented Jun 17, 2019

The internet says WAL is broken on WSL, is there a choice to not use WAL :)?

@borsboom
Copy link
Contributor

@borsboom borsboom commented Jun 24, 2019

Oh, that's annoying, it certainly would be nice for Stack to work out of the box on WSL. Looks like WAL is enabled by default in persistent-sqlite, but does provide an option to disable it. @snoyberg Can you think of any downside for Stack/Pantry to disable WAL by default? Alternatively, we could provide a configuration option to disable it.

@igraves
Copy link

@igraves igraves commented Jun 24, 2019

I'm seeing this same issue running on MacOS with docker. 2.1.1 works locally on MacOS, but in the docker image (latest fpco/stack-build) stack build fails with this message.

@jihygk
Copy link

@jihygk jihygk commented Jun 27, 2019

Also encountering this on OS X with the docker build on 2.1.1. Went back to 1.9.3 and it was working again.

@borsboom
Copy link
Contributor

@borsboom borsboom commented Jun 27, 2019

Strange, I don't seem to be able to reproduce this on macOS (using the current stable version of Docker for Mac).

@borsboom
Copy link
Contributor

@borsboom borsboom commented Jun 27, 2019

Pull request that disables WAL mode for new databases: #4915

snoyberg added a commit that referenced this issue Jun 28, 2019
Disable WAL mode for SQLite databases (fixes #4876)
@borsboom borsboom closed this in 398f9fa Jul 14, 2019
@ygale
Copy link

@ygale ygale commented Jul 24, 2019

@borsboom @snoyberg A comment in microsoft/WSL#2395 says that disabling WAL will not fix the issue, just make it happen less often. Someone else reports working around it by introducing a delay to avoid the race condition. The core issue is microsoft/WSL#1927. This was reported more than two years ago, but so far still no response from Microsoft.
EDIT: Looks like the MS WSL team is focusing on WSL2 now.

@borsboom
Copy link
Contributor

@borsboom borsboom commented Jul 24, 2019

I think disabling WAL by default is the right choice anyway (since it also can cause problems on network filesystems and with Docker for Mac).

I think it's out of scope for Stack to do anything more to work around this issue. SQLite is hardly an esoteric choice for local data storage, and if Microsoft purports Linux compatibility it really should work out of the box. Adding 0.1 second delays before writing to the DB, as suggested in one comment, would be terrible for performance (and I suspect just makes the problem less likely).

@ygale
Copy link

@ygale ygale commented Aug 4, 2019

@borsboom Agreed. And this is anyway fixed in WSL2. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants