Runtime: Redhat Linux - serviced - Failed to create CoreCLR

[Steve0212a]

My application works perfectly under systemd in Ubuntu 18.04, but fails under systemd in RedHat EL 8.

I have a dotnet core 3.1 application that has been published using a target runtime of linux-x64 and is self-contained. I copied the files to the linux machine and set the execute bit on the main executable. I can then run the executable from my logged in user and everything works. I can also run the application with sudo (i.e. root) and it works.

Next, this is actually a continuously running ASP.NET Core service, so I wanted to schedule it to run via systemd using this systemd file.

[Unit]
Description = xxx
After = network.target 
StartLimitIntervalSec=0

[Service]
Type= simple
ExecStart = <full path to executable>
Restart=no
RestartSec=1
User=root
StartLimitInterval = 60
StartLimitBurst = 10
StartLimitAction=reboot
WorkingDirectory=<directory path that contains the executable>

[Install]
WantedBy = multi-user.target

When I start the systemd service, it fails with these messages:

Mar 05 17:22:14 RedHat.localdomain <process name>[38411]: Failed to create CoreCLR, HRESULT: 0x80004005
Mar 05 17:22:14 RedHat.localdomain systemd[1]: <process name>.service: Main process exited, code=exited, status=137/n/a
Mar 05 17:22:14 RedHat.localdomain systemd[1]: <process name>.service: Failed with result 'exit-code'.

Based on some googling, I tried adding these two environment variables to my systemd file, but I got the same error.

Environment=TMPDIR=/tmp
Environment=COMPlus_EnableDiagnostics=0

So, to sum it up, it works on Ubuntu 18.04 using systemd and it works on RedHat if I run it from my user id or with sudo. It fails when run systemd on RedHat EL 8.

Any ideas would be greatly appreciated.

Thanks.

[Dotnet-GitSync-Bot]

I couldn't add an area label to this Issue.

Checkout this page to find out which area owner to ping, or please add exactly one area label to help train me in the future.

[Steve0212a]

Appears like it should be labeled area-VM-coreclr from other similar issues

[jkotas]

@tmds Is this a known issue?

[tmds]

@jkotas not known to me.

@Steve0212a try disabling SELinux and see if that may be stopping the application.

There is a blog post about running ASP.NET Core as a service on RHEL7: https://swimburger.net/blog/dotnet/how-to-run-aspnet-core-as-a-service-on-linux. Maybe if you go through the steps on your RHEL8 machine, you'll encounter the root cause.

If that doesn't help, I'll look at reproducing the issue locally.

cc @omajid

[Steve0212a]

That was it - thank you so much. It was SELinux. Once disabled, it worked. However, we are creating a commercial application and not all end users may want to do that. After some googling, our team found this stack overflow article: https://serverfault.com/questions/957084/failed-at-step-exec-spawning-permission-denied

That article had this tidbit in it:

SELinux prevents you from running a system service where the binary is in a user's home directory, or in your case, the root user's home directory.

To fix the problem, copy the binary to a proper directory such as /usr/local/bin and call it from there.

We were putting our self signed application in "/usr/lib/company name/app name". We enabled SELinux again, but moved our application to "/usr/local/bin/company name/app name" and it worked - even with SELinux enabled.

We are pretty much Linux newbies. Thank you so much for pointing us in the right direction.