Der Windows Prozessaktivierungsdienst funktioniert nicht in Containern: 'Systemfehler 6801 ist aufgetreten'

Refers to:

  • Plesk 11.0 for Windows
  • Plesk 12.0 for Windows
  • Plesk 12.5 for Windows

Created:

2016-11-16 12:59:48 UTC

Modified:

2016-12-21 19:43:13 UTC

0

Was this article helpful?


Have more questions?

Anfrage einreichen

Der Windows Prozessaktivierungsdienst funktioniert nicht in Containern: 'Systemfehler 6801 ist aufgetreten'

Kennzeichen

  1. Der Windows Prozessaktivierungsdienst (WAS) und abhängige Dienste (IIS und Plesk) funktionieren nicht in Containern.

  2. Beim Starten von WAS wird folgender Fehler angezeigt:

    C:\\Users\\Administrator>net start was
    The Windows Process Activation Service service is starting.
    The Windows Process Activation Service service could not be started.

    A system error has occurred.

    System error 6801 has occurred.

    Transaction support within the specified resource manager is not started or was
    shut down due to an error.

Ursache

Das Problem tritt auf, wenn das Systemtransaktionsprotokoll beschädigt wird.

Lösung

Es gibt verschiedene mögliche Lösungen. Wir empfehlen, diese in der nachfolgend gezeigten Reihenfolge anzuwenden. Das heißt, wenn die erste Lösung nicht funktioniert, fahren Sie mit der zweiten fort, dann mit der dritten und so weiter.

Erste Lösung

Wenden Sie die Lösung an, die in folgendem Microsoft Artikel beschrieben ist:

IIS-Dienste starten nicht: "Windows konnte den Prozessaktivierungsdienst nicht sarten - Fehler 6801: Die Transaktionsunterstützung im angegebenen Ressourcen-Manager wurde nicht gestartet oder aufgrund eines Fehlers heruntergefahren", wenn der WAS-Dienst gestartet wird (EN)

  1. Geben Sie folgenden Befehl in die Eingabeaufforderung des Containers ein

    fsutil resource setautoreset true c:\\

    Hinweis: Hier wird davon ausgegangen, dass "C:" das Systemlaufwerk ist

  2. Starten Sie den Container nach Ausführung des Befehls neu.

Zweite Lösung

Falls das Problem nach Befolgung der obigen Schritte dennoch bestehen bleibt, kann ein Klon-Container helfen.

HINWEIS: Fügen Sie in den unten stehenden Befehlen die tatsächlichen Container-IDs sowie den Speicherort des VZ-Ordners ein und führen Sie die Befehle in der Eingabeaufforderung aus:

  1. Halten Sie den Container an:

    vzctl stop 101
  2. Sichern Sie die originalen Konfigurationsdateien des Containers in einem Backup:

    copy E:\\vz\\private\\101\\.vza\\eid.conf 101.eid
    copy E:\\vz\\conf\\101.conf 101.conf
  3. Klonen Sie den Originalcontainer in einen anderen:

    vzmlocal -C 101:202
  4. Geben Sie eine andere Container-ID für den alten Container an:

    vzmlocal 101:100000
  5. Deaktivieren Sie den Autostart für den Originalcontainer:

    vzctl set 100000 --save --onboot no
  6. Löschen Sie die IP-Adresse vom Originalcontainer:

    vzctl set 100000 --save --ipdel all
  7. Legen Sie die alte Container-ID des alten Containers für den neuen Container fest:

    vzmlocal 202:101
  8. Beenden Sie den PVA Agent:

    net stop pvaagent

    (Jede Operation mit EID-Ersetzung muss bei angehaltenem PVA Agent durchgeführt werden.)

  9. Entfernen Sie die EID-Cache-Datei:

    del E:\\vz\\PVA\\Agent\\Data\\etc\\configs\\EID

    (Verwenden Sie den entsprechenden Laufwerkbuchstaben für die Dateien des PVA Agents.)

  10. Ersetzen Sie die EIDs:

    type E:\\vz\\private\\101\\.vza\\eid.conf > E:\\vz\\private\\100000\\.vza\\eid.conf
    type 101.eid > E:\\vz\\private\\101\\.vza\\eid.conf
  11. Starten Sie den PVA Agent, um die EID <-> CTID Bindungen erneut zu generieren:

    net start pvaagent
  12. Starten Sie den resultierenden Container:

    vzctl start 101

Nachdem Sie sich vergewissert haben, dass der neue Container ordnungsgemäß funktioniert, können Sie den alten Container gefahrlos löschen.

Dritte Lösung

Diese Lösung sollte angewendet werden, wenn die zweite Lösung (Klonen des Containers) nicht geholfen hat oder das Problem schon nach kurzer Zeit wieder aufgetreten ist. Dies passiert üblicherweise, wenn der Datenträger des Containers fragmentiert ist und der Container immer im Modus der Verletzung der gemeinsamen Nutzungsrechte ("sharing violation") startet:

C:\\Users\\Administrator>vzctl start 101

Starting container...

WARNING: (C:\\vz\\Private\\101\\root.efd, {971890c5-833d-4857-86f7-17cc762bfda3}) sharing violation, trying nonpaged mount
Container is mounted
Container was started

Zuerst müssen Sie den im Artikel 112842 erwähnten Patch installieren. Damit können Sie das Problem mit der "Verletzung der gemeinsamen Nutzungsrechte" angehen, das von einer hohen Fragmentierung des Datenträgers verursacht wird. Nachdem Sie den Patch installiert und den Node neu gestartet haben, kann es erforderlich sein, die zweite Lösung noch einmal durchzuführen.

Überprüfen Sie anschließend, ob Antivirensoftware auf einem Hardware Node installiert und korrekt konfiguriert ist. Manchmal kann eine Verletzung der gemeinsamen Nutzungsrechte ( sharing violation ) von einer auf einem Hardware Node installierten Antivirensoftware verursacht werden, wenn der private Bereich des Containers ( X:\\vz\\private\\ ) nicht von den Antivirenaktivitäten ausgeschlossen wurde. Die Antivirensoftware sperrt dann den Datenträger des Containers (die Datei root.efd ), sodass exklusives Sperren nicht mehr möglich ist. Dadurch werden die Container dazu gezwungen, im Modus der gemeinsamen Nutzung zu starten.

Um Probleme wie dieses zu vermeiden, müssen Sie X:\\vz\\private\\ aus allen Aktivitäten der Antivirensoftware ausschließen.

Weitere Informationen

WICHTIG:

  • Wenn der Container den MSSQL Server ausführt, lesen Sie bitte:

116218 MSSQL funktioniert nicht in einem geklonten Container oder nach einer c2v-Migration

  • Wenn der Container ein Mitglied des Active Directory (AD) ist, lesen Sie bitte:

119018 Vertrauensstellungsfehler bei Domain-Kunden nach Migration/Wiederherstellung eines Domain-Controllers

Haben Sie Fragen? Anfrage einreichen
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.