Defult ulimit way too low

[spsDrop]

I cannot use bash on Windows for the web development I do at work. The default ulimit is way too low for most complex node projects.

From my companies READ.ME

Increase your file descriptor limit or you will run into build errors (because Gulp opens many concurrent files)

ulimit -n 65536

• Expected results
  Should be able to run gulp and build my projects

• Actual results (with terminal output if applicable)
  Error: EMFILE: too many open files

• Your Windows build number
  14986

I know we can't change it but can we raise the default limit to something much higher than 8000 or what ever it's set to now. The 65536 limit has been working for our web team for 2+ years now.

[aseering]

Hi @Soljin -- WSL's defined behavior is "what stock Ubuntu does". And stock Ubuntu has an even lower default limit -- 1024 vs 2048. (The Mac default is actually even lower -- 256.)

Most Web environments other than NodeJS are totally happy with this limit in a dev environment. In my experience, NodeJS deals with it fine as well, if you install the graceful-fs package:

http://blog.izs.me/post/56827866110/wtf-is-emfile-and-why-does-it-happen-to-me

Have you seen graceful-fs before? Does it solve your problem?

[aseering]

Incidentally -- if you do want a higher limit, keep in mind that WSL is supposed to do exactly what Ubuntu Linux does. So, if you convince the Ubuntu folks to raise their limit, I would expect WSL to follow suit.

But I would expect you to get some push-back from the Ubuntu folks: There is some cost to having such a large limit. Performance, kernel data structures, etc. And there's no advantage on most machines to trying to read tens of thousands of files concurrently; you're going to unnecessarily hose any magnetic hard drive with that much seek()'ing, and a good SSD will return the files fast enough that there's no advantage. It's better to batch/pool those reads, which is what graceful-fs tries to do.

[spsDrop]

Well to be fair Ubuntu and mac allow you to raise the ulimit. And it is very common to require a developer to raise the ulimit. We use graceful-fs and I've brought the issue up to our tools teams but they just say raise the limit. It's hard to ask companies and developers to invest time and money into making development work within these ulimit constraints. When you have some many other options that will let you raise the limit arbitrarily.

I've essentially given up on bashonwindows (after trying relentlessly for 8 months to make it work). I just figured I'd bring this up as the issue that forced me to not be able to use it. Right now I'm running ubuntu in a headless vm.

[aseering]

Ah, I see -- so would your problem be solved if WSL allowed you to raise the ulimit? To be honest, I had forgotten that it didn't support that. (And I mis-read that part of your ticket the first time through.) Thanks for pointing it out! And I definitely agree, if you can't increase the limit at all, that's frustrating.

For what it's worth, my guess is that this ticket would get more attention from the WSL team if you tweaked its title and description (or filed a new ticket, either way) to say 'Can't raise "open files" ulimit' and added in a few lines of text showing the error message that you get when you try to increase the ulimit. Then the ticket is both a real frustrating user story and an Ubuntu incompatibility. (I'm not on the WSL team myself; I just watch enough tickets to know what gets their attention quickly :-) )

[spsDrop]

There are a few tickets open skiing for the ability to change the ulimit. And they all are resolved as a feature request. And link to a place to vote for new features. I figured if allowing users to change the ulimit was far off. The default value could at least be set very high to avoid needing to raise the limit. I'm not really sure what the impact of a high ulimit would be if any.

http://stackoverflow.com/questions/21591535/is-there-any-downside-to-setting-ulimit-really-high

From reading here there doesn't seem to be a real performance reason. It just seems like if seeing a high value has little effect and is more a concern when running in a multi user environment. Than it would make sense for a tool designed almost entirely for development to have a high ulimit.

[bmayen]

As you mentioned, the User Voice site is where feature requests like this get voted on. Might as well upvote this if you haven't already: https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/15125013-allow-changes-to-stack-size-via-the-ulimit-command. Though I agree that it's probably far off.

[aseering]

@Soljin -- do you have a reference to a ticket for "open files" ulimit in particular? (Also do you have any example of any ulimit request that has been resolved at all, in any way, other than as "fixed"? I can't find one.)

ulimits are not one monolithic thing. The vast majority of them can be changed today, at least on the latest Insider build. (They may not work correctly; I haven't tested most of them so I can't say one way or the other. I know, for example, that the stack size can be decreased but not increased -- no one has yet asked for it to be increased beyond the current and IIRC Ubuntu-standard default of 8mb. But if they don't work, that would want a separate ticket for each limit: The code that manages processor scheduling / CPU time is surely not, for example, the same code within WSL that handles core dumps.)

Regarding performance, that post is correct (as far as I know) that raising the limits themselves does not typically have a significant performance cost on modern desktop (not embedded) systems with a relative abundance of system resources. But it implies that processes can use the raised limit. Concrete example: Say you actually try to open 64k files at once. If you're reading from a magnetic disk, there's a calculation that you can do involving the ratio between your drive's spindle speed and linear bit density that, for a typical workstation hard drive, ends up saying that you want between a 1mb and 10mb buffer per file (not more and not less) in order to simultaneously amortize disk-seek costs and potential over-reading readahead costs, assuming your files are that big and/or they are packed consecutively on disk. 10mb * 64k is 640 gigabytes of readahead buffer. If you don't have enough RAM to allow for that much buffering, especially if you are reading large files, that can potentially pay a 100-1000x performance cost. So there's a very real reason why programs that try to open so many files might want to be guided vigorously towards batching their reads.

@bmayen -- per above -- that UserVoice refers to the stack size; this refers to the open-files count.

[benhillis]

Adding lings to related work items: #1682 #1686 #1688

[stehufntdev]

There was an accidental regression where the RLIMIT_NOFILE checks were too strict, and that was fixed in early February. The fix should be out for insider builds soon though the rlimits are still not actually applied.

[spsDrop]

@stehufntdev I just tried 15042. No luck. Do you know if this fix is supposed to be out in 15042?

events.js:160
throw er; // Unhandled 'error' event
^
BadRequireError: failed to resolve module!: EMFILE: too many open files, open '/mnt/c/Users/jesse/shakti/app/package.json'

[stehufntdev]

@Soljin, yes the fix mentioned above should be in 15042. That fix only re-relaxes the RLIMIT_NOFILE checks though the rlimits are still not actually applied so you may see different failures.

Does the ulimit -n 65536 command now work? The failure you posted most recently looks like a different issue from the original post and I wanted to double check.

[spsDrop]

@stehufntdev

jfoltz@lgwl-jfoltz:/mnt/c/Users/jesse/shakti/app$ ulimit -n 65536
bash: ulimit: open files: cannot modify limit: Invalid argument

You could never actually set the ulimit. So I don't see how this is fixed. I still hit the ceiling when trying to build my app. And I can't modify the ulimit.

[stehufntdev]

Thanks for the clarification on the repro, I was running the command as root which showed the accidental regression.

Was ulimit -n 65536 working previously for you as a non-root user in WSL?

[spsDrop]

No it didn't work root or not and continues to not work as root or not (with large values).

[stehufntdev]

Thanks for confirming. Sounds like the main issue here is the resource limits not being honored which we are tracking. To help us prioritize the work can you please give us feedback on user voice, https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/?

[benhillis]

Closing this out as a duplicate of #1688 to track in a single place. This change in in Code Review and will be available in Insider builds soon.

[mandeinfo]

Is the fix available yet for Ubuntu on windows subsystem ?