Reputation: 4702
We have several Azure app services live and I've ran into a consistent problem when restarting any of them.
We've right-click -> Published from Visual Studio upto an existing instance of an App Service which brings it online and functional immediately, we can update and republish new code without a problem, but restarting to app service from Azure Portal doesn't launch dotnet.exe
.
When restarting or stopping/starting, the thread count instantly drops to 0 and continues to do nothing.
I have to manually publish from VS again to reboot dotnet.exe
.
I can see that dotnet.exe
isn't an active process via Kudu -> Process Explorer
, and manually publishing up to the App Service and then refreshing the Process Explorer
list again shows that dotnet.exe
is now an active process and the App Service begins to function as expected.
Is there a way to prevent this, or at the very least debug why it's happening?
Upvotes: 4
Views: 1090
Reputation: 4702
As it turns out this is being caused by silent failures, outside of error handling I'd put in place. IIS would spin up the associated processes but dotnet
would throw and error and "silently" die.
I use quotes because I'd failed to utilise Azure's indepth logging, which hid the error message from plain view until switched on.
For some basic debugging steps:
Open up your Kudu
console (Advanced Tools -> Go -> Debug Console) and navigate to LogFiles
, open up eventlog.xml
, the latest events are listed at the bottom.
Run dotnet myDll.dll
against your debug
folder locally, where myDll.dll
is the main dll
in your project. This will typically throw the error causing dotnet
to exit out, which wasn't obvious at design time.
Ensure that your server-side appsettings.json
(or the associated appsettings.[development/release].json
contains the connection strings you're attempting to access.
The errors that were occuring we'ren't due to design-time bugs, it generally fell over when trying to access run-time resources (such as appsettings
).
Upvotes: 2