Skip to content

Cmd+Q: letzte Sicherung und Ende von rigctld im closeEvent - #79

Open
oe5sos wants to merge 6 commits into
mainfrom
fix/cmdq-sicherung-und-daemons
Open

oe5sos wants to merge 6 commits into
mainfrom
fix/cmdq-sicherung-und-daemons

Conversation

@oe5sos

@oe5sos oe5sos commented Nov 7, 2026

Copy link
Copy Markdown
Owner

Anlass

In Longpath blieb rigctld nach dem Beenden als Waise zurück und hielt den Anschluss des TS-590 besetzt (oe5sos/Longpath#414). Das Contestprogramm ist gleich gebaut. Hier fiel zusätzlich die letzte Log-Sicherung aus.

Ursache

Gemessen mit einer kleinen Sonde (Qt 6.11, macOS):

Weg closeEvent exec() kehrt zurück Destruktor
Cmd+Q ja nein nein
quit() ja nein nein
Roter Punkt ja ja ja

~AppController schrieb die letzte Sicherung und beendete die Daemons. Bei Cmd+Q lief er nie. Die QSOs seit der letzten Minutensicherung fehlten dann in den Sicherungen und im zweiten Ordner, bis zur nächsten Sicherung im nächsten Lauf. In der Datenbank selbst stehen sie.

Änderung

Beides steht jetzt in AppController::vorDemBeenden(). Aufgerufen wird es aus MainWindow::closeEvent() und aus dem Destruktor, mehrfach ohne Schaden.

Geprüft

  • Neuer Prüfstand test_cmdq_ohne_destruktor: schließt das Fenster, ohne AppController zu zerstören. Rot ohne den Aufruf, grün mit ihm.
  • Voller Lauf lokal offscreen: 142 von 142 grün.
  • Mit echtem Cmd+Q am laufenden Programm noch nicht gefahren.

🤖 Generated with Claude Code

Unter macOS enden Cmd+Q und quit() in exit(), noch innerhalb von
closeEvent(). Der Destruktor von AppController lief auf diesen Wegen
nie: die letzte Log-Sicherung samt Kopie in den zweiten Ordner fiel aus,
und rigctld/rotctld blieben als Waisen zurueck und hielten den
seriellen Anschluss.

Beides steht jetzt in AppController::vorDemBeenden(), aufgerufen aus
closeEvent() und aus dem Destruktor.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Beim Abbau meldete sich die CAT-Verbindung ab, und die Aufsicht griff auf
das schon zerstoerte RigctldProcess zu. Die Leitungen werden jetzt zuerst
gekappt. Der Pruefstand laeuft ohne die Behebung in den SIGSEGV.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
oe5sos added a commit to oe5sos/Longpath that referenced this pull request Nov 7, 2026
Beim Abbau des Logbuchs startete die Aufsicht rigctld auf einem schon
zerstoerten Mitglied. Hebt das Submodul auf den Stand von
oe5sos/Contestprogramm#79.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
oe5sos and others added 4 commits November 7, 2026 17:29
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Kam der erste Anruf vor dem Server von Longpath, startete die Aufsicht einen
eigenen rigctld. Der nahm Longpath Anschluss und Port weg, oder er starb mit
Code 1, wenn Longpath den Anschluss schon hielt.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Longpath bettet das Logbuch ein und zeigt nur seine Panels; das Menü mit dem
Startcheck gibt es dort nicht. zeigeStartcheck() öffnet ihn, auf Wunsch als
Werkzeugfenster auf der Ebene der schwebenden Panels.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Seit dem 06.11. bricht GitHub jeden Lauf auf macos-14 nach null Sekunden ab,
ohne einen Schritt, in jedem PR. Longpath fordert macos-15 an und läuft.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant