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.

[caroe2014]

No description provided.

[stephentoub]

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 respect DOTNET_USE_POLLING_FILE_WATCHER as it is constructed with pollForChanges=true in that case (by PhysicalFileProvider), and proceeds to register PollingFileChangeTokens for use instead of watching the filesystem ... however TryEnableFileSystemWatcher is called regardless of the value of PollForChanges.

[adriend-advz]

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).

[adriend-advz]

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.

[adriend-advz]

My bad, thought I could be able to unblock you :(
Good luck!

[mike-jewell]

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.

[fsalmeida]

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.

[stephentoub]

This got moved to Future. Shouldn't this be fixed for 5.0? If the problem is what's described above (#37664 (comment)), this is also an issue with Microsoft.Extensions.
cc: @maryamariyan

[ericstj]

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.

[ghost]

Tagging subscribers to this area: @maryamariyan
See info in area-owners.md if you want to be subscribed.

[ericstj]

@pranavkm do you agree with @ackginger's assessment here? It looks like this behavior has been present since aspnet/FileSystem@c225155

[pranavkm]

Yes that is correct. Changing it so that DOTNET_USE_POLLING_FILE_WATCHER exclusively 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.

[ericstj]

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?

[pranavkm]

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.

[ericstj]

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.