Increase file descriptor limit in NativeAOT app process

[akoeplinger]

CoreCLR and soon Mono (after #82429) call a function that will increase the maximum open file descriptors via a function like this, should NativeAOT do the same?

runtime/src/coreclr/pal/src/init/pal.cpp

Lines 1087 to 1093 in 2bdc3cb

	/*++
	Function:
	INIT_IncreaseDescriptorLimit [internal]
	Abstract:
	Calls setrlimit(2) to increase the maximum number of file descriptors
	this process can open.

/cc @dotnet/ilc-contrib

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Both CoreCLR and Mono call a function that will increase the maximum open file descriptors via a function like this, should NativeAOT do the same?

runtime/src/coreclr/pal/src/init/pal.cpp

Lines 1087 to 1093 in 2bdc3cb

	/*++
	Function:
	INIT_IncreaseDescriptorLimit [internal]
	Abstract:
	Calls setrlimit(2) to increase the maximum number of file descriptors
	this process can open.

/cc @dotnet/ilc-contrib

Author:	akoeplinger
Assignees:	-
Labels:	area-NativeAOT-coreclr
Milestone:	-

[VSadov]

It probably makes sense, just for parity purposes.
I am curious - are there specific reasons for this in CoreCLR/Mono or is it "just in case"? Any interesting history for why the call was introduced?

[jkotas]

FWIW, this is disabled on Alpine and nobody ever complained about it there:

runtime/src/coreclr/pal/src/CMakeLists.txt

Lines 95 to 96 in e9b9489

	# Setting RLIMIT_NOFILE breaks debugging of coreclr on Alpine Linux for some reason
	add_definitions(-DDONT_SET_RLIMIT_NOFILE)

[akoeplinger]

I don't know about the historical context (the function was already part of the initial CoreCLR github commit) but we recently saw issues if this isn't done during NuGet restore: #82428

[jkotas]

historical context

This was part of the original Rotor PAL: https://github.com/SSCLI/sscli_20021101/blob/77d46e0f04f52052a12ac40ce2cf96712c934b3c/pal/unix/init/pal.c#L629 .

[VSadov]

I remember there was a bug fix for when we could temporarily have too many fd's. I'll try finding details.

[VSadov]

Maybe it was to compensate for #47859 ?
(Assembly.Load opens /dev/zero in linux and does not close it)

It was fixed in #48140

[VSadov]

At the time of Rotor using /dev/zero for anonymous memory mapping was likely the "right" way.

[akoeplinger]

Given we're seeing #82428 when the limit is not increased I think it still makes sense to have it, though you could argue that with NativeAOT in library mode maybe the embedding application should have the final say.

[VSadov]

The scenario with NuGet looks real. The app has a scenario that may open 1K+ files and gets away with that on CorCLR, making this a compat issue.

I think we should increase the limit on NativeAOT and perhaps on Alpine too, unless the reason (debugging is broken) is still there.

[VSadov]

NativeAOT in library mode maybe the embedding application should have the final say.

No compat concerns in this case.
It might be strange if library does this, especially if dynamically loaded.

[agocke]

It seems reasonable to match the CoreCLR behavior here.