Runaway inotify watches with HostApplicationBuilder

[Dash]

When using Microsoft.Extensions.Hosting v10.0.5 (other versions not checked), and leveraging CreateApplicationBuilder on Linux, all directories in the current working tree are iterated and inotify watches created.

This can create a startup performance delay, and additionally present a denial-of-service risk as inotify watches can be easily exhausted.

I have only checked this on openSUSE Leap 15.6 6.4.0-150600.23.87-default.

Steps to reproduce:

1. Create a project (dotnet new console)
2. Add Microsoft.Extensions.Hosting (dotnet package add)
3. Add the extensive code below:

_ = Host.CreateApplicationBuilder();

4. Build (optimisations don't seem to have an impact as I first noticed this on a aot single-file program)
5. Run from a suitably lofty parent working directory and check inotify watches

Helpful troubleshooting

Running your built program with 'strace' you should be able to see heaps of inotify_add_watch() function calls spewing forth.
Adding a Console.ReadLine() and then using a script to analyse inotify watches is another way of seeing the impact compared to the rest of your system.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-extensions-hosting
See info in area-owners.md if you want to be subscribed.

[svick]

This is a consequence of the default configuration watching for the appsettings.json and <appname>.settings.json files and using a FileSystemWatcher with IncludeSubdirectories == true for that.

Can you explain why you're running the application from the large parent directory as your working directory? Is this a problem in production or during development? How big is the delay you're seeing?

[Dash]

This was in development, I noticed it when working on packaging. Using standard Linux packaging approach (rpm etc), the built binary (aot single file) is being installed into /usr/sbin. As this is a long-running process, it is being started through a systemd unit file, running as a DynamicUser. Systemd defaults the working directory to the root of the file system - / - so watchers are attempted to be placed on the entire file system; I was getting 'inotify watch limit reached' errors, which led me down this rabbit hole.

Running a single binary from /usr/sbin doesn't really lend itself to an application with a specific working directory. And using DynamicUser= (security hardening) in systemd provides a runtime user without a standard home directory to enable an explicitly set WorkingDirectory.

The work around of course is, to create a directory specifically for the systemd unit, but this doesn't feel especially clean and is a solution specific to systemd for setting a working directory.

[svick]

Thanks for the information. I plan to take a look at resolving this.