# Chrome Renderer schlägt bei kaltem Start im Azure App Service Linux fehl
Dieses Problem tritt im Azure App Service Linux auf, wenn das zugrunde liegende Oryx/Ubuntu-Basis-Image von Azure aktualisiert wird, wodurch gemeinsam genutzte Bibliotheken entfernt werden, von denen IronPDFs Chrome-Renderer abhängt. Beim nächsten kalten Start muss IronPDF diese nativen Chrome-Abhängigkeiten von Grund auf neu installieren, ein Vorgang, der bis zu 5 Minuten dauern kann. Wenn das Timeout für den Anwendungsstart zu kurz ist, wird die Installation unterbrochen und der Renderer schlägt fehl.
Der Fehler erscheint typischerweise als:
```txt
libnss3.so: cannot open shared object file: No such file or directory
```
Azure aktualisiert regelmäßig das Basis-Image, das von App Service Linux-Umgebungen verwendet wird. Diese Updates können gemeinsam genutzte Bibliotheken wie `libnss3.so` entfernen, die Chrome benötigt. Wenn dies passiert, versucht IronPDFs `LinuxAndDockerDependenciesAutoConfig`-Mechanismus, die erforderlichen Pakete beim Start neu zu installieren. Wenn das Dienst-Timeout kürzer ist als die Zeit, die für die Installation benötigt wird, wird der Prozess abgebrochen, bevor Chrome einsatzbereit ist.
Dieses Problem wurde in der folgenden Umgebung bestätigt:
- **Affected version:** IronPDF 2026.4.1
- **Unaffected version:** IronPDF 2026.5.2
- **Hosting:** Azure App Service P0v3-Plan, Region Norwegen Ost
- **Laufzeit:** .NET 10
## Lösung
### Lösung 1: Initialisierungseinstellungen anwenden und Startup-Timeout erhöhen
Fügen Sie den folgenden Initialisierungscode beim Anwendungsstart hinzu, bevor PDF-Darstellungsaufrufe erfolgen:
```csharp
Logger.LoggingMode = Logger.LoggingModes.All;
Installation.LinuxAndDockerDependenciesAutoConfig = true;
Installation.ChromeGpuMode = IronPdf.Engines.Chrome.ChromeGpuModes.Disabled;
Installation.Initialize();
```
Das Festlegen von `LinuxAndDockerDependenciesAutoConfig` auf `true` weist IronPDF an, fehlende Linux-Abhängigkeiten automatisch zu erkennen und zu installieren. Das Festlegen von `ChromeGpuMode` auf `IronPdf.Engines.Chrome.ChromeGpuModes.Disabled` deaktiviert die GPU-Beschleunigung, die in Azure App Service Linux-Umgebungen nicht verfügbar ist. Die Aktivierung des vollständigen Loggings hilft dabei, Fehler während des Abhängigkeitsinstallationsschritts zu erfassen.
Erhöhen Sie als Nächstes das Azure App Service-Startup-Timeout auf mindestens 10 Minuten. Dies gibt IronPDF genügend Zeit, die Abhängigkeitsinstallation während eines kalten Starts nach einem Azure-Basis-Image-Update abzuschließen. Siehe den [Azure-Bereitstellungsleitfaden](/get-started/azure/) für Anweisungen zur Anpassung der Startzeitlimits in den App Service-Konfigurationseinstellungen.
### Lösung 2: Upgrade auf IronPDF 2026.5.2 oder später
Ein Upgrade auf IronPDF 2026.5.2 oder eine spätere Version behebt dieses Problem. Die nicht betroffene Version behandelt den Fall, dass Azure-Basis-Image-Updates gemeinsame Bibliotheken entfernen, ohne dabei einen Kaltstartfehler zu verursachen.
[[n:(Dieses Problem wurde in IronPDF 2026.5.2 behoben. Wenn Sie diese Version oder eine spätere verwenden, sind die Workarounds in Lösung 1 nicht mehr erforderlich.)]]
Dieses Problem tritt im Azure App Service Linux auf, wenn das zugrunde liegende Oryx/Ubuntu-Basis-Image von Azure aktualisiert wird, wodurch gemeinsam genutzte Bibliotheken entfernt werden, von denen IronPDFs Chrome-Renderer abhängt. Beim nächsten kalten Start muss IronPDF diese nativen Chrome-Abhängigkeiten von Grund auf neu installieren, ein Vorgang, der bis zu 5 Minuten dauern kann. Wenn das Timeout für den Anwendungsstart zu kurz ist, wird die Installation unterbrochen und der Renderer schlägt fehl.
Der Fehler erscheint typischerweise als:
libnss3.so: cannot open shared object file: No such file or directory
libnss3.so: cannot open shared object file: No such file or directory
Text
Azure aktualisiert regelmäßig das Basis-Image, das von App Service Linux-Umgebungen verwendet wird. Diese Updates können gemeinsam genutzte Bibliotheken wie libnss3.so entfernen, die Chrome benötigt. Wenn dies passiert, versucht IronPDFs LinuxAndDockerDependenciesAutoConfig-Mechanismus, die erforderlichen Pakete beim Start neu zu installieren. Wenn das Dienst-Timeout kürzer ist als die Zeit, die für die Installation benötigt wird, wird der Prozess abgebrochen, bevor Chrome einsatzbereit ist.
Dieses Problem wurde in der folgenden Umgebung bestätigt:
Affected version: IronPDF 2026.4.1
Unaffected version: IronPDF 2026.5.2
Hosting: Azure App Service P0v3-Plan, Region Norwegen Ost
Laufzeit: .NET 10
Lösung
Lösung 1: Initialisierungseinstellungen anwenden und Startup-Timeout erhöhen
Fügen Sie den folgenden Initialisierungscode beim Anwendungsstart hinzu, bevor PDF-Darstellungsaufrufe erfolgen:
Option Strict On
Option Infer On
Logger.LoggingMode = Logger.LoggingModes.All
Installation.LinuxAndDockerDependenciesAutoConfig = True
Installation.ChromeGpuMode = IronPdf.Engines.Chrome.ChromeGpuModes.Disabled
Installation.Initialize()
Das Festlegen von LinuxAndDockerDependenciesAutoConfig auf true weist IronPDF an, fehlende Linux-Abhängigkeiten automatisch zu erkennen und zu installieren. Das Festlegen von ChromeGpuMode auf IronPdf.Engines.Chrome.ChromeGpuModes.Disabled deaktiviert die GPU-Beschleunigung, die in Azure App Service Linux-Umgebungen nicht verfügbar ist. Die Aktivierung des vollständigen Loggings hilft dabei, Fehler während des Abhängigkeitsinstallationsschritts zu erfassen.
Erhöhen Sie als Nächstes das Azure App Service-Startup-Timeout auf mindestens 10 Minuten. Dies gibt IronPDF genügend Zeit, die Abhängigkeitsinstallation während eines kalten Starts nach einem Azure-Basis-Image-Update abzuschließen. Siehe den Azure-Bereitstellungsleitfaden für Anweisungen zur Anpassung der Startzeitlimits in den App Service-Konfigurationseinstellungen.
Lösung 2: Upgrade auf IronPDF 2026.5.2 oder später
Ein Upgrade auf IronPDF 2026.5.2 oder eine spätere Version behebt dieses Problem. Die nicht betroffene Version behandelt den Fall, dass Azure-Basis-Image-Updates gemeinsame Bibliotheken entfernen, ohne dabei einen Kaltstartfehler zu verursachen.
Wichtig: Dieses Problem wurde in IronPDF 2026.5.2 behoben. Wenn Sie diese Version oder eine spätere verwenden, sind die Workarounds in Lösung 1 nicht mehr erforderlich.
Curtis Chau hat einen Bachelor-Abschluss in Informatik von der Carleton University und ist spezialisiert auf Frontend-Entwicklung mit Expertise in Node.js, TypeScript, JavaScript und React. Leidenschaftlich widmet er sich der Erstellung intuitiver und ästhetisch ansprechender Benutzerschnittstellen und arbeitet gerne mit modernen Frameworks sowie der Erstellung gut strukturierter, optisch ansprechender Handbücher.
