App Service Linux Does NOT Properly Handle Application Lifecycle

## The Problem

Azure App Service for Linux does not properly integrate with .NET application lifecycle hooks when stopping or restarting applications. Specifically:

**`az webapp stop` does NOT:**
- Send SIGTERM to the running container
- Trigger `IHostApplicationLifetime.ApplicationStopping`
- Call `BackgroundService.StopAsync()` methods
- Allow any graceful shutdown whatsoever

The application process is simply killed at the infrastructure level without any notification to the application code.

## Why This Matters

Modern .NET applications use built-in lifecycle hooks for critical cleanup operations:
- Completing in-flight work
- Releasing database connections
- Flushing logs and telemetry
- Releasing distributed locks
- Gracefully stopping background services
- Preventing data corruption

**These are not "nice-to-have" features - they are core patterns in ASP.NET Core that Microsoft itself promotes and documents extensively.**

## The Disconnect

Microsoft provides:
- Comprehensive documentation on graceful shutdown in .NET
- `IHostApplicationLifetime` APIs specifically for shutdown hooks
- `BackgroundService` base class with `StopAsync()` methods
- App Service as a managed hosting platform for .NET

**But Azure App Service doesn't actually honor these lifecycle contracts when you stop or restart the service.**

## Current "Solutions" Are Inadequate

**Deployment Slots:** Not viable when your application cannot have multiple instances running simultaneously (exclusive locks, singleton processing, queue consumers, etc.)

**Manual Workarounds:** Developers are forced to:
- Call Kudu APIs to manually kill processes
- Implement custom shutdown endpoints
- Add complex orchestration logic to GitHub Actions
- Hope that deployment triggers proper shutdown (it often doesn't)

**This is unacceptable for a Microsoft hosting platform running Microsoft frameworks.**

## Impact on Developer Experience

This creates:
- **Frustration and wasted time** troubleshooting why "standard" .NET patterns don't work
- **Loss of confidence** in Azure as a reliable platform
- **Production issues** from incomplete shutdown (data loss, corruption, orphaned resources)
- **Complexity** - developers forced to implement workarounds for basic functionality that should "just work"
- **Bad impressions** of Azure compared to competitors where lifecycle management works correctly

## What Should Happen

When a developer runs `az webapp stop` or `az webapp restart`:

1. Azure should send SIGTERM to the container (standard Docker practice)
2. The .NET runtime should receive this and trigger `ApplicationStopping`
3. Background services should have their `StopAsync()` methods called
4. The application should have time (configurable via `WEBSITES_CONTAINER_STOP_TIME_LIMIT`) to complete shutdown
5. Only then should the process be forcefully killed if needed

**This is how Docker containers work. This is how Kubernetes works. This is how every other container platform works. Azure App Service should work this way too.**

## The Ask

Microsoft needs to:

1. **Fix the integration** between App Service infrastructure commands and container lifecycle
2. **Document the current behavior** honestly - don't pretend graceful shutdown works when it doesn't
3. **Provide a supported solution** for single-instance applications that need graceful shutdown
4. **Test these scenarios** - clearly this workflow was never properly tested with real .NET applications

## Conclusion

It is utterly ridiculous that deploying a .NET application to Microsoft's own managed hosting platform requires custom workarounds to achieve basic lifecycle management that works correctly on every other container platform.

This is not about "fancy bumpless parallelism" or zero-downtime deployments. This is about **basic application lifecycle management** - starting and stopping an application cleanly. Microsoft promotes these patterns in .NET, documents them extensively, and then their own hosting platform doesn't support them.

This severely impacts impressions of Azure's usability and maturity as a platform. When developers can't rely on fundamental contracts between the framework and the hosting environment, trust in the entire ecosystem is damaged.

---

**TL;DR:** `az webapp stop` should trigger graceful shutdown in .NET applications. It doesn't. This is a critical gap that forces developers into hacky workarounds for basic functionality that should work out of the box on a Microsoft platform hosting Microsoft frameworks.