0

We deploy our ASP.NET Core applications in Amazon Linux 2 using AWS Auto Scaling

When the linux services were created, the path for the dotnet binary was configured as: ExecStart=/usr/bin/dotnet ...

That path worked fine until some months ago, on new auto scaled instances the dotnet binary path randomly changed to /usr/bin/local/dotnet forcing to update the systemd service files with the new path.

Today one of our instances was refreshed with a new one by AWS and the services didn't start because the bin path changed again to /usr/bin/dotnet

I am unable to find in documentation or changelogs on why this binary path is being changed.

For reference, ASP.NET Core is being installed automatically on the instances by an install script containing:

sudo rpm -Uvh https://packages.microsoft.com/config/centos/7/packages-microsoft-prod.rpm
sudo yum install -y aspnetcore-runtime-5.0

We're in the process of updating our application to .NET 6 as .NET 5 will no longer be receiving support, but I don't think that would be the cause for this issue.

Any insights on why this path is being changed randomly?

If this can't be prevented, any way to specify in the .service file to use dotnet on whichever path it's found? I think that setting ExecStart=dotnet ... will not find the binary.

Emiliano Sandler
  • 44
  • 9

1 Answers1

0

Could you just figure it out in the installation script? Something like filling the path with --DOTNET_PATH--. Installing dotnet the normal way and then using which dotnet and replacing it.

The Service file

ExecStart=--DOTNET_PATH--

The installation script

sudo rpm -Uvh https://packages.microsoft.com/config/centos/7/packages-microsoft-prod.rpm
sudo yum install -y aspnetcore-runtime-5.0
sed -i "s/--DOTNET_PATH--/$(which dotnet)/" /path/to/servicefile

Alternatively, figuring it out which file exists and then symlinking one to the other would also work.

b2f
  • 196
  • 2
  • 10