Support "Bash on Windows" #154
Comments
|
Some people have reported having great luck using Meteor with the Windows Subsystem for Linux (see meteor/meteor#5091 (comment)). What issues are you seeing? |
|
I haven't tried it in a while, so maybe it works now. However, at least one person reported problems: |
|
I believe all versions of Meteor work great when completely self-contained inside WSL. However, this isn't ideal: WSL doesn't have a graphical environment, so you have to install your own X server on Windows (rather janky at the moment) or edit everything with vim or emacs in a console. The design of WSL is to allow both Linux and Windows applications to access files in the same filesystem, the Windows filesystem. (It doesn't work the other way). So you make your meteor app under This worked great up to Meteor 1.3.5.1, but no longer with Meteor 1.4. In this case you basically get this error: To reproduce this in WSL (again, works fine with 1.3.5.1, not with 1.4+): It's very likely the upgrade to Mongo 3.2 (in Meteor 1.4) that broke things; meteor/meteor#7583 is pretty clear that it's not working for anyone. You can also see lots more details in this thread: https://forums.meteor.com/t/linuxs-meteor-install-now-works-natively-on-windows/21954/21 A while ago, this post suggested the awkward workaround of setting up MongoDB using the Windows version of Meteor: My intuition for a fix here is to get Meteor to run the Windows-version of Mongo when it detects a WSL environment. But maybe it has something to do with file locking, in which case it would be far more complicated. |
|
Same problem here. That would be so nice to use meteor correctly on windows. |
|
Same problem also. The |
|
So here is a small summary of what I've found using Windows Subsystem for Linux:
People have tried, the Windows programs don't add the right headers to the files, and the files become invisible to Linux. This is the best case scenerio. Worst case would probably be file corruption and the Linux environment doesn't function.
Due to all these factors, how have people's experiences been using something like VcXsrv Windows X Server along with Atom or Sublime? Crashing? Slowdowns? Lag? Resource intensive? It's a janky-ass workaround, but it seems to be the only option for editing Windows Subsystem Linux files in Windows. |
|
I have a pretty weird setup right now, but it works:
I recently found that Meteor runs much faster on Windows if you disable Windows Defender real-time scanning, which uses 100% CPU as |
|
Has anyone here been trying Windows Sub-system for Linux (WSL) (a.k.a. Bash on Windows) with the bleeding edge Windows Insider Releases (nightly builds, etc.)? More specifically, does anyone know if some of the file system problems are alleviated with DrvFs? The blog post about it can be found here. I realize this was posted in April 2017, but I'm not sure if it's even been released into the official Windows 10 builds yet. WSL is obviously a work in progress by Microsoft, but it's something which we're really excited about since it greatly simplifies our ability to move Meteor forward quicker by allowing a unified code-base. It's incredible how far the Microsoft team has come (with what they were up against, compatibility-wise), but we still have a lot of exceptions in place just for Windows and WSL has certainly made some of that easier. A lot of the most breakthrough improvements to the WSL experience have appeared in the Insider builds, and 4 months before the Creatives Update was released I had amazing improvements in my experience on WSL (something I don't use often, as I'm on macOS, but the difference was incredible). We would greatly appreciate help from Windows users who are able to help us improve it. My assistance in getting started with contributing is always on the table, but the |
|
Hi, DrvFs doesn´t make mongo work.
Mongo keeps failing with the same error. |
|
@joadr What if you run: ...and then try starting Meteor (and Mongo) as usual? |
|
|
@joadr I think the previous post is the result of running |
|
@mizzao You are totally right, I will delete that post to not bring confusion. |
|
Anyway as meteor for windows is super slow, even disabling Windows Defender's Realtime Security, I work with an external mongo server, and then meteor runs well on WSL. |
|
Strange error in WSL at the moment: if trying to run more than one Meteor instance at once (on a different port), the following error occurs when starting the second instance: This is in the Meteor 1.5.2 tool, but the project is using some other Meteor release. |
|
I have had this issue with VMs and I just tried my fix on Bash on Windows. If you mount the local folder, it works. You should also mount node_modules to be safe Make sure you are in your app's directory so pwd works correctly |
|
I could also make it running the way @merlinpatt described using the simple-todo app. However, when I try to access Mongo in another console via EDIT: This is apparently not a Mongo error, since other Meteor commands throw the same error. |
|
@janKir did you find a solution? |
|
No, I did not try anything on the |
|
I found a workaround to the details @ meteor/meteor#9426. This appears to be because of: microsoft/WSL#1927 Workaround?Hack your local version of Change: https://github.com/meteor/meteor/blob/devel/tools/packaging/catalog/catalog-remote.js#L144 And it worked! FYI: here is the file on my local WSL installation of Meteor 1.6 to modify: RecommendationOption 1 new environment variableAdd an environment variable, A flag like this may be useful for users that are seeing this issue. Option 2 change journal modeor could simply make the change to Let me know if you want me to submit a PR for this. |
|
I believe that the fall creators update has the My entire project is on my For Meteor I am still getting the errors. I also tried: Looks like mongo is surprised by the file WiredTiger.wt, then it cannot do a Output |
|
Copy/pasting from meteor/meteor#9426 for further discussion: @brucejo75 said in meteor/meteor#9426 (comment):
@abernix replied in meteor/meteor#9426 (comment): We prefer automatic detection over additional configuration (which requires discovery and implementation by users who are experiencing the problem). If that's not possible, or this needs to be explored without breaking for another segment of users, then an environment variable might be a temporary option, but I'd like to avoid considering that as a solution. If you're confident in your solution (and can reason around any downsides to that change) I'd suggest we detect it automatically (Windows && WSL && ??) and make the change for everyone. If others can confirm this tweak to Mongo's journaling helps the situation, let's discuss making it more permanent! |
|
Changing the journal_mode to truncate made the |
|
Hi @abernix, like your idea about automatically detecting WSL (I had looked at any identifying environment variables and could not find any). Regarding downside, I know nothing about SQLite. From the threads on the WSL bugs I had gathered that WAL is the best performing of the SQLite journaling modes. The claim in the threads was that using non-WAL was a performance issue. Here is the journaling mode pragma description. I do not know how many times the SQLite DB is accessed per build, but I am going to guess it is in the 10's, maybe 100's. I am assuming that is a relatively small hit to the build performance and given it does not work at all on WSL today worth the change for WSL if we can keep it to that environment. |
Some benchmarking would be great if you have some time. I'd venture to say that it could be quite high. The SQLlite database is used to cache the package catalog and could be making a lot of requests. I'm not asking you to measure the requests, but perhaps if you could (outside of WSL) compare the two modes of operation. |
|
Hi @abernix, I activated And I was able to get timings from my project. All runs were performed on windows. First test:
Second test:
ALERT: I got a SQLite error on straight windows while in DiscussionI think the performance differences between the 2 schemes are negligible for this use case 10's of transactions per clean rebuild. Note the comment in the // WAL mode copes much better with (multi-process) concurrencyMaybe in earlier versions collision problems were detected when not using This is the checkin that turned on I could not find an associated issue. Maybe this? Maybe it was just voodoo 😺 |
|
An update to my earlier posts: Meteor 1.6.0 running on the Fall Creators Update (build 1709) still experiences the Mongo unable to start problem. (Not surprising given no updates to WSL were in this update.) However, though the earlier Creators Update (build 1703) improved inotify support for a number of Linux apps, it actually did not help for Mongo. So a fix is still somewhere in the future... |
|
any new about this issue ? |
|
Running Meteor using bash on windows (aka WSL) works well and has been my primary development environment since the beginning of the year. Mongo issuesI just filed meteor/meteor#9914 to make sure it is looked at directly. (the issue is a little buried in this thread, partly my fault! sorry @mizzao) There are issues running Mongo 😞, but they can be worked around!
Multiple simultaneous meteor serversWith the release of v1.7 there is an new environment variable: After you install v1.7 (and only after): |
|
For the mongo part, I would recommend using Mongo trough Docker, and connect to that instance instead. Makes it also possible to explore the database when Meteor ain't running. But mostly, I'm surprised by:
I've tried it in January when I bought my new notebook. But the filesystem on WSL is terribly slow. Really on the level that it's unbearable. |
|
re:
I set up my windows Mongo as a windows service. So it is always running when my dev box is up & I can always inspect it. No need for Docker. re:
I often times see comments like these. But I have no issues with speed. None! I made sure that defender was not monitoring my development directories and I made sure my editor was not monitoring meteor build directories. Both of these slow down the apparent filesystem speed by a large amount. I also turn off monitoring of node by defender. I added an update to the forum topic on this which shows my exclusion settings for Defender and for VSCode while developing using WSL. |
|
When i installed mongodb its works fine in linux wsl windows 10 april update |
|
@fifou17 , where did you install mongodb, windows? I installed inside Linux bash shell following this and it didn't fix for me... sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 9DA31620334BD75D9DCB49F368818C72E52529D4
echo "deb [ arch=amd64,arm64 ] https://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/4.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-4.0.list
sudo apt-get update
sudo apt-get install -y mongodb-org |
|
@ProphetDaniel i installed in linux bash ubuntu 18.04 using |
|
@fifou17, @ProphetDaniel, see meteor/meteor#9914 |
is any body there using meteor 1.8.0.2? anybody have the solution maybe? |
|
@ipinyulun the project must be in windows out of wsl and if you cloned the project from github you need to clone from wsl |
i use meteor 1.8.1 do all that thing but not work. |
|
@ipinyulun |
|
Can you build a single server on WSL? If not, you may need to reset your Meteor SQLite DB. This DB is used to track package installs for meteor. I am still using Meteor on WSL very successfully. I am hoping that WSL2 will resolve some of the files system issues of WSL and this issue may go away entirely! |
|
@brucejo75 |
|
It sounds like the Before building a project on WSL you might just try a For issues with |
|
@brucejo75 |
|
This worked for me:
|
|
Is this still an issue? Now, for me, everything works fine without the workaround suggested in the comment before the const JOURNAL_MODE declaration (line 23) in https://github.com/meteor/meteor/blob/master/tools/packaging/catalog/catalog-remote.js . Namely in a freshly created default app directory I'm using the latest Meteor 1.11.1 and Ubuntu 20.04 in WSL2 on Win10 (10.0.19041). |
|
Hi @PGlivicky, Is your default app directory off the linux root tree? e.g. ~pglivicky... If so, meteor & mongo will work just fine in that scenario. Issues come when:
Just installed WSL2 but have not gotten to the point of testing meteor yet. It would be good to know if you are working in those scenarios? |
|
Hello @brucejo75. Thank you for explaining. I'm using meteor in WSL2 for almost 2 months now with my project folder in my linux home directory ( ~/... ) and without issues. But the mongo itself worked absolutely fine even when my project was on the windows drive ( /mnt/c/... ). I had problems with editing the files there in vscode though, so I didn't test more than running a few mongo queries from shell. |
|
@PGlivicky, thanks for the update! Also, glad to hear that mongo is working. VScode Idea: Try editing your files with
Then editing files will not add the carriage return aka |
|
Hi @brucejo75 what about creating a PR to incorporate your adjustments into Meteor core? |
|
Hi @filipenevola, I already did! See TRUNCATE journal mode for packaging DB on Windows like file systems. But it turned out that this caused an issue for meteor upgrade. So this fix was made. And a new environment variable Beyond that I think some documentation may help. At least the environment variable should be documented and then it may be helpful to outline the issues with running mongo on WSL. I can add that to my todos. |
thank you for the tip. I'll try that. |
|
@brucejo75 Please do! |
and others
Migrated from: meteor/meteor#7583
Meteor 1.4 and meteor 1.5 don't work on Windows Subsystem for Linux. 1.3 worked though. If this worked, MDG could drop support for regular windows binaries. That would be great because meteor on windows is painfully slow anyways.
The text was updated successfully, but these errors were encountered: