RichardandClaude Opus 5
ad94f8c373
Erster Befund aus dem Linux-Lauf auf der Test-VM (Roadmap A4a): Ohne konfigurierte Datenbank startete die Anwendung los und starb erst tief im DI-Aufbau mit einer unbehandelten ArgumentException und rund 50 Zeilen Stacktrace - "The string argument 'connectionString' cannot be empty", geworfen aus dem EF-Kern. Exitcode 134 (SIGABRT). Fuer den Serverbetrieb ist das gleich doppelt schlecht: Der Betreiber sieht nicht, was fehlt, und systemd startet den Dienst wegen Restart=on-failure alle zehn Sekunden neu. Im Journal stehen dann endlose Startversuche statt der Ursache. Genau dieser Zustand ist bei einer Erstinstallation der wahrscheinlichste - Software liegt da, Zugangsdaten sind noch nicht gesetzt. Behoben an drei Stellen: - Program.Main prueft die Verbindung, bevor der Host gebaut wird, und gibt aus, welcher Schluessel in welcher Datei erwartet wird, samt Beispiel und dem Hinweis, dass das Schema per "dotnet ef database update" angelegt wird (die Anwendung migriert nicht selbst). - Rueckgabewert 78 (EX_CONFIG aus den BSD-sysexits) statt eines Absturzes. - deploy/polytrader.service traegt RestartPreventExitStatus=78 - ein Konfigurationsfehler repariert sich durch Neustarts nicht, er wird dadurch nur unsichtbar. - AddCorePersistence wirft als zweite Verteidigungslinie eine InvalidOperationException mit derselben Aussage, falls jemand die Methode direkt aufruft. Der Connection-String wird dabei ueber dieselben Dateien und denselben Schluessel gelesen wie spaeter im Host, damit beide Wege nicht auseinanderlaufen koennen. Build gruen, 476 Tests gruen (Windows und Linux). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
45 lines
2.1 KiB
Desktop File
45 lines
2.1 KiB
Desktop File
# systemd-Unit für den kopflosen Linux-Betrieb (--headless, Stufe L2 der Linux-Portierung).
|
|
# Der Deploymentcenter-Installer legt selbst keinen Dienst an (siehe SETUP_INTEGRATION_GUIDE §7,
|
|
# "Dienstregistrierung fehlt") - diese Datei ist unser Ersatz dafür.
|
|
#
|
|
# Einrichtung:
|
|
# sudo cp deploy/polytrader.service /etc/systemd/system/polytrader.service
|
|
# sudo systemctl daemon-reload
|
|
# sudo systemctl enable --now polytrader
|
|
#
|
|
# WICHTIG (D-11 aus dem Umsetzungsplan): server_settings.xml wird relativ zum Arbeitsverzeichnis
|
|
# geladen, master.key dagegen relativ zur ausführbaren Datei (AppContext.BaseDirectory). Beides
|
|
# fällt nur zusammen, wenn WorkingDirectory exakt das Installationsverzeichnis ist - deshalb hier
|
|
# ausdrücklich gesetzt statt dem systemd-Standard (Root des Dienstbenutzers) überlassen. Eine
|
|
# abweichende WorkingDirectory liest server_settings.xml aus dem falschen Ordner, ohne dass das
|
|
# irgendwo auffällt (ServerSettings.Load() legt bei fehlender Datei kommentarlos eine neue an).
|
|
|
|
[Unit]
|
|
Description=PolyTrader (Trading- und Analyse-Suite fuer Polymarket)
|
|
After=network-online.target mysql.service
|
|
Wants=network-online.target
|
|
|
|
[Service]
|
|
Type=simple
|
|
# Anpassen: Installationsverzeichnis und Dienstkonto. Nicht als root betreiben - das
|
|
# Installationsverzeichnis (inkl. master.key, server_settings.xml, data.db) gehört diesem Konto.
|
|
User=polytrader
|
|
Group=polytrader
|
|
WorkingDirectory=/opt/polytrader
|
|
ExecStart=/opt/polytrader/PolyTrader.App.Avalonia --headless
|
|
Restart=on-failure
|
|
RestartSec=10
|
|
# Exit 78 (EX_CONFIG) meldet einen Konfigurationsfehler - etwa einen fehlenden
|
|
# Connection-String. Ein Neustart repariert das nicht, er verdeckt es nur: der Dienst
|
|
# liefe im Zehn-Sekunden-Takt an und wieder aus, und im Journal saehe man endlose
|
|
# Startversuche statt der eigentlichen Ursache. Deshalb hier bewusst nicht neu starten.
|
|
RestartPreventExitStatus=78
|
|
|
|
# Absturz vom sauberen Beenden unterscheiden: SIGTERM statt SIGKILL, mit Frist fuer den
|
|
# geordneten Shutdown-Pfad (offene Positionen, Watchdog-"stopped_graceful", DB-Flush).
|
|
KillSignal=SIGTERM
|
|
TimeoutStopSec=45
|
|
|
|
[Install]
|
|
WantedBy=multi-user.target
|