Linux "dotnet run" fails with Win32Exception when launching at low process priority

[Foritus]

Hello, this has recently regressed and caused my build system to fall over. We manually invoke dotnet build with nice -n20 ionice -c3 to ensure the machine remains responsive during a large build, but this now causes msbuild to crash in recent builds.

It looks like the bug is here: https://github.com/microsoft/msbuild/blob/236f48ecb51e413c13a16d55b6712df4d0a3ca9f/src/MSBuild/XMake.cs#L630
MSBuild needs to store the process' current priority instead of assuming it is running at "Normal".

Commit that introduced the regression: b111470#diff-3099880c51224257bef6905bc2dfbf3d

Steps to reproduce

dotnet new webapi
nice -n20 dotnet build

Observe crash.
MSBUILD : error MSB1025: An internal failure occurred while running MSBuild.
System.ComponentModel.Win32Exception (13): Permission denied
at System.Diagnostics.Process.set_PriorityClassCore(ProcessPriorityClass value)
at System.Diagnostics.Process.set_PriorityClass(ProcessPriorityClass value)
at Microsoft.Build.CommandLine.MSBuildApp.Execute(String[] commandLine)
Unhandled exception. System.ComponentModel.Win32Exception (13): Permission denied
at System.Diagnostics.Process.set_PriorityClassCore(ProcessPriorityClass value)
at System.Diagnostics.Process.set_PriorityClass(ProcessPriorityClass value)
at Microsoft.Build.CommandLine.MSBuildApp.Execute(String[] commandLine)
at Microsoft.Build.CommandLine.MSBuildApp.Main(String[] args)

Expected behavior

MSBuild doesn't crash.

Actual behavior

It crashes.

Environment data

dotnet --version
3.1.300

OS info:
Ubuntu Server 18 lts

[Foritus]

I made a small change on a fork to see what the fix might look like: master...Foritus:master It would be simpler to change the "lowPriority" priority to "Idle" but I assume someone cared enough to use BelowNormal rather than Idle, so I preserved the behaviour.

[cbricart]

related: #5365

[rainersigwald]

Thanks for the report! @Forgind, can you look at this? I think it might be more complete than #5365.

[rainersigwald]

Duplicate of #5365

[Forgind]

It would be simpler to change the "lowPriority" priority to "Idle" but I assume someone cared enough to use BelowNormal rather than Idle, so I preserved the behaviour.

I went with @bgianfo's design. In his words:

The process priority documentation https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.processpriorityclass?view=netcore-3.1
seems to state that idle would end up starving the build of any real scheduler time slice if you are actually using your machine at all.
The idea was to give UI/interactive processes priority, so they remain responsive, but to still make progress in the background.