Skip to content
This repository has been archived by the owner on Nov 30, 2023. It is now read-only.

Dot Net Core devcontainer without "The configured user limit (128) on the number of inotify instances has been reached" #418

Open
johnnyreilly opened this issue Jul 18, 2020 · 5 comments
Labels
dotnet feature-request Request for new features or functionality upstream Issue identified as 'upstream' component related (exists outside of VS Code)

Comments

@johnnyreilly
Copy link

johnnyreilly commented Jul 18, 2020

I use the dotnetcore devcontainer and it's wonderful! Thanks so much for putting it together!

I have one problem with the container. I often experience the famous "The configured user limit (128) on the number of inotify instances has been reached" issue, particularly when running tests. This doesn't seem to a well solved problem in the dot net core space.

@paillave has suggested a workaround:

echo fs.inotify.max_user_instances=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

Is there a way we could apply the suggestion here to the dotnetcore devcontainer image? That way, anyone using the dotnetcore devcontainer wouldn't bump on this issue.

dotnet/aspnetcore#7531
dotnet/aspnetcore#8449
https://github.com/dotnet/aspnetcore/issues/21838

I should say that it would be tremendous if the problem was directly solved in dot net core, but I'll take a workaround when I have one!

@Chuxel
Copy link
Member

Chuxel commented Jul 21, 2020

This is a great suggestion. Happy to take a PR if you've got one, otherwise we'll add this to the queue to pick up!

@Chuxel Chuxel added dotnet feature-request Request for new features or functionality labels Jul 21, 2020
@johnnyreilly
Copy link
Author

johnnyreilly commented Jul 25, 2020

Thanks @Chuxel - I'd love to contribute a PR but try as I might I haven't succeeded in resolving this myself. I thought raising the issue here might help to surface one from a kind soul with the answer 😉

So if you, @paillave or anyone else is able to help when you get a chance I'd greatly appreciate it. (And looking at the linked issues I'd say I'm not alone in that!)

cc @travisgosselin who is bumping on this too:

@johnnyreilly
Copy link
Author

Just to share ideas that I've come upon (but don't seem to be able to get working):

# RUN sudo sysctl fs.inotify.max_user_watches=524288 fs.inotify.max_user_instances=524288 net.core.somaxconn=524288 scache.object_max_active=524288 && sudo sysctl -p
RUN echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
RUN echo fs.inotify.max_user_instances=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

I tried marrying this with privileged: true but it didn't seem to work

@Chuxel Chuxel added the upstream Issue identified as 'upstream' component related (exists outside of VS Code) label Sep 2, 2020
@turowicz
Copy link

turowicz commented Sep 4, 2020

Same issue here on some of the containers. I can't figure out why some of them work others don't. This only happens when usin "Open Repository in a Container" feature.

@johnnyreilly
Copy link
Author

Just a side note: this is tagged as dotnet-core and it definitely applied to dot net. That said, I'd say this issue of
watchers running out is likely a general problem faced by devcontainers at present. It probably affects other languages / frameworks as well; anything that relies upon file watching I guess.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
dotnet feature-request Request for new features or functionality upstream Issue identified as 'upstream' component related (exists outside of VS Code)
Projects
None yet
Development

No branches or pull requests

3 participants