Repository navigation
System.IO.IOException: The configured user limit (1024) on the number of inotify instances has been reached, or the per-process limit on the number of open file descriptors has been reached. #37664
Description
Activity
From @ackginger in #27272:
Isn't the issue actually here in PhysicalFilesWatcher:
https://github.com/dotnet/runtime/blob/master/src/libraries/Microsoft.Extensions.FileProviders.Physical/src/PhysicalFilesWatcher.cs#L134
This class attempts to respectDOTNET_USE_POLLING_FILE_WATCHERas it is constructed withpollForChanges=truein that case (by PhysicalFileProvider), and proceeds to registerPollingFileChangeTokens for use instead of watching the filesystem ... howeverTryEnableFileSystemWatcheris called regardless of the value ofPollForChanges.FWIW, I managed to solve this issue by hosting my App Service in a distinct App Service Plan (was mixing Function Apps and "regular" Web Apps in the same).
Actually I have several Function Apps deployed on Azure and one "regular" Web App, all built on .NET Core 3.1 and hosted on Linux containers.
I had the same issue as you with the above mentionned error message on my "regular" web app. I ended up hosting it on an App Service Plan distinct from the one for Function Apps.My bad, thought I could be able to unblock you :(
Good luck!Will this be retroactively fixed for dotnet core 3.1? What kind of timeframe would there be for a fix?
Seeing this problem once a week now on Azure app service with the config described in #40350. The only solution for now is to use log monitor alerts and azure automation powershell scripts to scale down and up again, which isn't ideal.
I've been facing the same problem as you do.
Recently this problem has ocurred to one of my applications, then I've scaled up the ServicePlan and the application has back to life. Then I scaled it down and it still works.
Today I've faced the same problem with other application and I'm still trying to find a way to solve the problem.1 remaining item
Looks like this issue is causing significant customer pain and there is a known bug / fix here. Moving this in to 5.0 for bar check.
@pranavkm do you agree with @ackginger's assessment here? It looks like this behavior has been present since aspnet/FileSystem@c225155
Yes that is correct. Changing it so that
DOTNET_USE_POLLING_FILE_WATCHERexclusively uses polling should not only fix this issue, but is also something we'd wanted as an implementation. We'd tried to address this at some point but that PR got nixed because it happened right around the time repos got consolidated.Good point: today this uses a conjunction of both the FSW and polling to trigger the events. The suggested change will make it exclusively use polling when set.
I couldn't find that PR. Did you recall why it got nixed? Was there any push back on the behavior change?
Hmm, I thought I had the PR sitting in dotnet/extensions but I can't seem to find it either. I don't recall there being a push-back, it was just in the middle of a bunch of repo changes and it never went anywhere.
I have a PR ready for this but I’m not 100% confident it is low enough risk to take this late in 5.0. Will move to 6.0. Folks can still pick up the package and try it out on 5.0 / 3.x.
- ghost locked as resolved and limited conversation to collaborators
on Dec 12, 2020
