Randomly getting error on Azure Linux App Service: "The directory name '/home/site/wwwroot/wwwroot/' does not exist. (Parameter 'path')"

Question

I have a Linux App Service and I am randomly getting the error:

The directory name '/home/site/wwwroot/wwwroot/' does not exist. (Parameter 'path')

The error doesn't happen all the time, it has happened 131 times since the app was deployed 7 months ago, and the site has received 216 million page requests during that time. Is this a common issue with Azure App Services with a Linux OS? Is it related to having multiple instances? Per health recommendations I added 2 instances for redundancy. I never had this problem with the previous website that was running on Windows App Service (.net Framework). The application is up to date as of yesterday (All DLLs updated to newest versions).

This issue seems very random, as it happens mostly at night, not the same day or time and seems to go in waves. One month I might get it happening once or twice that month, other months it might happen every week. This last month it has happened more than other months, so I would like to solve this issue.

Here are the app service details:

• Pricing plan: P0v3
• Instance count: 2
• App(s) / Slots: 2 / 2 (prod/dev apps, 2 instances per app)
• Operating System: Linux
• Zone redundant: Disabled

Here is the application deployment Details:

• Target Framework: net8.0 (Razor Pages)
• Deployment Mode: Framework-dependent
• Target Runtime: linux-x64

Error Details:

• Category: Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware
• Timestamp: 09/26/2024 04:24:56UTC
• Message: An unhandled exception has occurred while executing the request.
• ExceptionType: System.ArgumentException
• ExceptionMessage: The directory name '/home/site/wwwroot/wwwroot/' does not exist. (Parameter 'path')
• ExceptionStackTrace: at System.IO.FileSystemWatcher.CheckPathValidity(String path) at System.IO.FileSystemWatcher..ctor(String path) at Microsoft.Extensions.FileProviders.PhysicalFileProvider.CreateFileWatcher() at System.Threading.LazyInitializer.EnsureInitializedCoreT at Microsoft.Extensions.FileProviders.PhysicalFileProvider.Watch(String filter) at Microsoft.AspNetCore.Mvc.Razor.Infrastructure.DefaultFileVersionProvider.AddFileVersionToPath(PathString requestPathBase, String path) at Microsoft.AspNetCore.Mvc.TagHelpers.LinkTagHelper.Process(TagHelperContext context, TagHelperOutput output) at Microsoft.AspNetCore.Razor.TagHelpers.TagHelper.ProcessAsync(TagHelperContext context, TagHelperOutput output) at Microsoft.AspNetCore.Razor.Runtime.TagHelpers.TagHelperRunner.RunAsync(TagHelperExecutionContext executionContext) at Application.Web.Pages.Shared.Pages_Shared__Layout.<>c__DisplayClass29_0.<b__0>d.MoveNext() --- End of stack trace from previous location --- at Microsoft.AspNetCore.Razor.Runtime.TagHelpers.TagHelperExecutionContext.SetOutputContentAsync() at Application.Web.Pages.Shared.Pages_Shared__Layout.ExecuteAsync() at Microsoft.AspNetCore.Mvc.Razor.RazorView.RenderPageCoreAsync(IRazorPage page, ViewContext context) at Microsoft.AspNetCore.Mvc.Razor.RazorView.RenderPageAsync(IRazorPage page, ViewContext context, Boolean invokeViewStarts) at Microsoft.AspNetCore.Mvc.Razor.RazorView.RenderLayoutAsync(ViewContext context, ViewBufferTextWriter bodyWriter) at Microsoft.AspNetCore.Mvc.Razor.RazorView.RenderAsync(ViewContext context) at Microsoft.AspNetCore.Mvc.ViewFeatures.ViewExecutor.ExecuteAsync(ViewContext viewContext, String contentType, Nullable1 statusCode) at Microsoft.AspNetCore.Mvc.ViewFeatures.ViewExecutor.ExecuteAsync(ViewContext viewContext, String contentType, Nullable`1 statusCode) at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.g__Logged|22_0(ResourceInvoker invoker, IActionResult result) at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.g__Awaited|30_0TFilter,TFilterAsync at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Rethrow(ResultExecutedContextSealed context) at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.ResultNextTFilter,TFilterAsync at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.InvokeResultFilters() --- End of stack trace from previous location --- at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.g__Awaited|25_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted) at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Rethrow(ResourceExecutedContextSealed context) at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted) at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.InvokeFilterPipelineAsync() --- End of stack trace from previous location --- at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.g__Logged|17_1(ResourceInvoker invoker) at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.g__Logged|17_1(ResourceInvoker invoker) at Microsoft.AspNetCore.Routing.EndpointMiddleware.g__AwaitRequestTask|7_0(Endpoint endpoint, Task requestTask, ILogger logger) at Application.Web.Program.<>c.<b__0_9>d.MoveNext() --- End of stack trace from previous location --- at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context) at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context) at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddlewareImpl.g__Awaited|10_0(ExceptionHandlerMiddlewareImpl middleware, HttpContext context, Task task)

Contents of wwwroot/wwwroot:

• css/
• Identity/
• Images/
• js/
• lib/
• _content/
• Application.Web.styles.css
• robots.txt
• sitemap.xml

Any suggestions or ideas would be a great help. I have been hunting for an answer for a long time now and seems that posts with this error online assume the site is not working, whereas I am up and online 99.9% of the time. When the issue does occur, it is only for a short time, maybe a second or two. It appears to be when trying to process frontend items, since its always an error with the wwwroot/wwwroot directory. I've been looking through azure logs and application logs, but haven't found any answer yet what's going on, and how to stop it.

Thanks!

Answer 1

@Jason Hargrave Since you have health checks enabled, it appears the system is detecting issues with some of your instances. To manage and route traffic more effectively during these failures, consider using Azure Traffic Manager or Azure Front Door.

You can deploy Azure Front Door or Azure Traffic Manager to intercept traffic before they hit your site. They help in routing & distributing traffic between your instances/regions. In the event that a catastrophic incident happens in one of the Azure Datacenters, you can still guarantee that your app will run and serve requests by investing in one of them. There are additional benefits to using Front Door or Traffic Manager, such as routing incoming requests based the customers’ geography to provide the shortest respond time to customers and distribute the load among your instances in order not to overload one of them with requests.

Learn More

• Controlling Azure App Service traffic with Azure Traffic Manager
• Quickstart: Create a Front Door for a highly available global web application

Also, you can use Application Initialization which ensures that your app instances have fully started before they are added to they start serving requests. Application Initialization is used during site restarts, auto scaling, and manual scaling. This is a critical feature where hitting the site’s root path is not sufficient to start the application. For this purpose a warm-up path must be created on the app which should be unauthenticated and App Init should be configured to use this url path.

Try to make sure that the method implemented by the warm-up url takes care of touching the functions of all important routes and it returns a response only when warm-up is complete. The site will be put into production only when it returns a response (success or failure) and app initialization will assume “everything is fine with the app”.

App Initialization can be configured for your app within web.config file.

Learn More

• How to warm up Azure Web App during deployment slots swap

For more information, see: Robust Apps for the Cloud.

In response to the question, “Is it the process of one of the service instances becoming bad, and then switching over?” –

I suggest reviewing this article on using Health Check in the Azure portal to monitor App Service instances. Health checks improve your application's availability by rerouting requests away from unhealthy instances and replacing them if they remain unresponsive. The service pings your web application every minute on a path you define.

Also, It seems your application failed to respond to multiple HTTP health checks, which could mean it crashed, finished unexpectedly, or failed to expose the correct TCP port.

Azure App Service pings your container every second to ensure the HTTP server is running. If there’s no response within the default 230-second timeout, the system times out.

To resolve this, you can increase the timeout using the WEBSITES_CONTAINER_START_TIME_LIMIT app setting. Additionally, enabling application logs will help you identify any exceptions or errors that may provide clues to the underlying issue.

For more information, refer to these articles:

• What's the difference between PORT and WEBSITES_PORT?
• Troubleshooting intermittent outbound connection errors in Azure App Service

Please let us know if further query.