Skip to content

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

Merged
oe5sos merged 7 commits into
mainfrom
fix/cmdq-sicherung-und-daemons
Nov 11, 2026
Merged

oe5sos merged 7 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 5 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>
RigctldClient/RotctldClient::setTarget() merkte sich nur Host und Port.
Ein Anruf, der schon unterwegs war, ging beim ALTEN Ziel zu Ende, und ein
verbundener Klient blieb dort bis zum naechsten Abriss.
AppController::openDatabase() waehlt mit den Vorgaben 127.0.0.1:4532,
bevor setSettings() das eigentliche Ziel setzt -- ohne Ereignisschleife
dazwischen. Auf einem Rechner mit laufendem Longpath lauscht dort dessen
CAT-Server: test_seitenband_folgt_dem_band landete dort (Hamlib-Fehler
statt Antworten, Befehle beim fremden Dienst), und test_rigctld_supervision
/ test_cmdq_ohne_destruktor sahen nie einen gescheiterten Anruf, also nie
den eigenen rigctld. Dieselbe Reihenfolge erklaert "L KEYSPD 24" im
macOS-Lauf: der Klient war zuerst woanders verbunden.

Jetzt: bei geaendertem Ziel auflegen und beim neuen sofort waehlen; ohne
Ziel aufgelegt bleiben; dasselbe Ziel aendert nichts.

test_client_reconnect: drei Faelle (Rig: Ziel waehrend des Anrufs
gewechselt -- das alte bekommt kein Byte; Rig: verbunden, anderer Port --
Wechsel unter der Wiederwahl-Frist, gleiches Ziel bleibt, leeres Ziel legt
auf; Rotor: wie der erste). Gegenprobe mit dem alten setTarget: alle drei
rot. Lokal gruen: test_client_reconnect, test_seitenband_folgt_dem_band,
test_rigctld_supervision, test_cmdq_ohne_destruktor, test_rigctldprotocol
(vorher drei davon rot, solange Longpath lief).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@oe5sos
oe5sos merged commit 5dc0c99 into main Nov 11, 2026
6 checks passed
oe5sos added a commit to oe5sos/Longpath that referenced this pull request Nov 12, 2026
)

* TS-590: Bedienfeld, Zustand vom Geraet, Warnung am Transverter

Longpath liest vom TS-590S Antennenwege, Vorverstaerker, Daempfung, RF-Gain,
AGC, NB, NR, Filter, Leistung, S-Meter und beim Senden das SWR. Neues
Applet CAT Rig stellt Preamp, ATT, RF-Gain, AGC, NB und NR. Filter gehen
in beide Richtungen, S-Meter und ON AIR kommen vom Geraet.

Ist der Transverter eingeschaltet und RX ANT oder DRV aus, warnt Longpath.
Es stellt daran nichts um. Ts590Cat ist eine geschlossene Liste ohne
Sendebefehl; die Leistung wird nur roh gelesen, weil `l RFPOWER` sie in
Hamlib 4.7 auf 5 W stellt.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Profilwechsel: Plaetze und Stapelung wie beim Start

Die Fenster bekamen ihre Groesse, bevor Combined seinen Inhalt zurueckhatte,
und das leere Feld fiel zusammen. Ausserdem hob show() die Applets ueber
den Panadapter, der beim Start zuletzt kommt und oben liegt.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Beenden: das Logbuch geht vor den schwebenden Fenstern zu

Ein Log-Panel in Combined starb mit seinem Gehaeuse, und ~MainWindow des
Logbuchs griff in das tote Feld. Seit dem 4.11. acht Abstuerze beim
Beenden, jeweils vor der letzten Sicherung. Das Logbuch holt seine Panels
jetzt zurueck und schliesst, bevor closeEvent die Fenster loescht. Der
Pruefstand laeuft ohne die Behebung in denselben SIGSEGV.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Contestprogramm: Abbau ohne Neustart von rigctld

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>

* TS-590: Betriebsart wartet nicht auf die ganze Abfrageliste

Sie kam nur nach allen Rohabfragen dran, rund alle anderthalb Sekunden, auf
dem CI-Laeufer laenger als der Pruefstand wartete.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* TS-590: das CAT-Feld geht beim Verbinden wirklich auf

Im Profil CONTEST ist die Appletspalte nicht zu sehen. setVisible stieg aus,
weil der gemerkte Zustand schon sichtbar sagte, und das Feld war nicht zu
erreichen. Jetzt ensureVisible und bringAppletToFront, wie beim FT8-Panel.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* TS-590: AGC wirkt am Gerät, Tasten springen nicht zurück

Hamlib 4.7.2 meldet bei L AGC RPRT 0, das Gerät bleibt aber stehen. Jetzt
W GC1; 0, die Antwort darauf ist nur ein Nullbyte. Nach jedem Stellbefehl wird
die Abfrageliste sofort nachgelesen, sonst sprang das Feld bis zu zwei Sekunden
auf den alten Stand zurück. Alle Tasten des Feldes am TS-590S nachgelesen.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* TS-590: das CAT-Feld liegt nach dem Verbinden nicht unter den Fenstern

Die Prüfung auf Verdeckung lief, während die schwebenden Fenster hinter der
Maske versteckt waren. Danach lag die Spalte mit dem Feld wieder darunter und
war nicht zu erreichen. Jetzt wird erst geprüft, wenn die Fenster zurück sind,
und ein neu abgelöstes Feld kommt auf einen freien Platz, wenn es einen gibt.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Jeder Klick holt das Fenster nach vorne

Die Regel saß nur in ToolWindow und AppletFloatingWindow, Panadapter und
Contest-Fenster hatten sie nicht. Sie gilt jetzt für alle Werkzeugfenster. Ein
verdecktes Applet in der Spalte hat kein Fenster zum Heben: der Klick löst es
als eigenes Fenster ab und schaltet dabei nichts.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* TS-590: Ziehen an der Bandbreite stapelt keine Befehle

Zum Gerät geht nur der letzte Stand, und nur die Kante, die sich geändert hat.
Nach der Frist gleicht die Anzeige sich mit dem Gerät ab, sonst blieb sie auf
dem verlangten Wert stehen, obwohl das Gerät auf seine Tabelle gerundet hatte.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* TS-590: Bandbreite wirkt am Gerät, dazu CW-Breite und Filter A/B

Hamlib 4.7.2 lehnt L SLOPE in LSB mit RPRT -1 ab, die Filtertasten hätten dort
nichts bewirkt. Jetzt die Gerätebefehle SL und SH. In CW stellt die Brücke die
Breite über FW, die Lage bleibt der Scheibe. Das CAT-Feld hat eine Taste für
Filter A und B. Alles am TS-590S in LSB und CW nachgelesen.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* TS-590-Prüfstand hält langsame Läufer aus

Die macOS-CI brauchte für eine Abfragerunde über sieben Sekunden, und die Frist
von 400 ms lief ab, bevor die Meldung kam, die sie abfangen sollte. Die Frist
ist im Prüfstand jetzt lang, und das Nachlesen wird bei langsamer Abfrage
geprüft statt gegen die Uhr.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* TS-590: Abstimmweg abgesichert, Logbuch startet in Longpath keinen rigctld

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* TS-590: Filtertasten behalten die Breite

Die Tasten halten die Mitte fest, eine Kante lag dann jenseits des Trägers. Die
Brücke nahm die Beträge, und aus 2.9k wurden am Gerät 2400 Hz. Jetzt zählt die
Breite ab der unteren Kante des Geräts.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* TS-590: eine Eingabe auf 2 m landet auf der ZF

Der Trockenlauf am Gerät fand es: Bandtaste oder Eingabe auf 144,300 MHz gingen
unverändert zum 590 und kamen dort nicht an. Die Brücke rechnet jetzt auf die
ZF um und stellt die Scheibe mit. Der Handlauf LONGPATH_CAT_TROCKEN fährt die
Anzeige, die Warnung und den Weg vom Logbuch ohne Konverter.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* TS-590: eine Meldung in der Frist geht nicht mehr verloren

Client und Zustand melden nur Änderungen. Drehte man am Gerät kurz nach einem
Befehl von Longpath, fiel die Meldung in die Frist und kam nie wieder, die
Anzeige blieb auf dem alten Stand. Nach der Frist wird jetzt abgeglichen. Der
langsame CI-Läufer traf genau dieses Fenster.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Fehlender Sicherungs-Stick fällt in Longpath auf

Eigenständig zeigt das Logbuch es in seiner Statuszeile, die es in Longpath
nicht gibt. Am 07.11. stand es so stundenlang nur im Protokoll. Jetzt kommt es
in Longpaths Hinweiszeile, und zwar schon beim Öffnen des Logbuchs, nicht erst
beim ersten QSO.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Startcheck des Logbuchs aus Longpath erreichbar

Im Menü der Contest-Panels: Start check (ready?). Er stand nur im Menü des
eigenständigen Logbuchs, das es in Longpath nicht gibt. Er nennt unter anderem
den fehlenden Stick, CAT, Transverter, Rotor und die Uhr.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Meldungen des Logbuchs kommen in Longpath an

Eingebettet ist die Statuszeile des Logbuchs nicht zu sehen. Darin steht aber,
was der Betreiber wissen muss: Exchange unvollständig, Band nicht im Contest,
Journal nicht geschrieben, gelöschtes QSO mit Strg+Z, Sked-Vorschläge, Fehler
von rigctld und rotctld. Sie kommen jetzt als Hinweis, ohne das Dauerrauschen
wie Frequenzecho und QSO-Zähler.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* TS-590: Befunde der Durchsicht

- Die Kenwood-Zeilen gehen nur an den TS-590S (Modell 2031), auch über die
  Brücke. Vorher bekam jedes CAT-Gerät die Tabellen des 590.
- Eine Betriebsart, die das Gerät nicht kennt (SAM, DSB), kippt nach der Frist
  nicht mehr auf die des Geräts.
- RF Gain kommt auch über Mausrad und Tasten beim Gerät an.
- Eine Null, die nach ihrer Rohantwort in einem eigenen Paket kommt, wird der
  nächsten Antwort nicht mehr vorangestellt.
- Die Wegewarnung fragt active(), nicht nur enabled.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* TS-590: RIT, Auto-Notch, NB/NR-Pegel und ALC im Feld CAT Rig

RIT ein/aus mit -/+ 10 Hz und Null, Versatz aus IF; gelesen. Auto-Notch
(NT10/NT00). NB-Pegel (NL, nur bei NB an) und NR-Pegel (RL, nur bei NR1)
als Schieber, gesendet beim Loslassen. Beim Senden steht ALC neben SWR.
Alles am echten 590 am 12.11. ausgemessen; Prüfstand mit Doppel.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* 590 aus/USB weg: rigctld wird neu gestartet, bis das Geraet wieder antwortet

Bisher blieb Longpath danach stumm: rigctld stand mit totem Anschluss
oder hatte sich beendet, der Client verband sich endlos neu. Jetzt
schaut eine Wache alle 2 s nach einer frischen Frequenz; nach rund 6 s
Stille (und 8 s Anlauf nach jedem Start) startet sie den eigenen
rigctld neu. Gesagt wird es einmal beim Ausfall, einmal beim
Wiederkommen. Pruefstand mit echtem rigctld am Hamlib-Dummy: SIGKILL
und SIGSTOP, Gegenprobe ohne Wache rot.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Sprachspeicher über den TS-590: abgesichert, Vorgabe aus

F1…F10 tasten den 590 mit TX1 (DATA SEND) und spielen die Ansage an
seinen USB-Toneingang (Menü 63 = USB); RX beendet. Die eine Ausnahme von
„Longpath tastet kein fremdes Gerät“, und nur wenn alles stimmt:
Setup → Companion rig eingeschaltet, Transverter eingestellt und nicht
„nur Empfang“, DRV am Gerät an, Leistung gelesen und höchstens 5 W,
USB/LSB/FM/AM. Fällt eine Bedingung während der Sendung, geht der Sender
sofort aus; nach 30 s auf jeden Fall. Ohne Taste liegt kein Ton am 590.
MOX bleibt abgewiesen.

Prüfstand am Doppel: jede Sperre einzeln, Ton kommt an, DRV fällt
während der Sendung, Höchstzeit, ganzer Weg über den Spieler. Gegenprobe
ohne DRV-Sperre rot. Am echten Gerät nicht gesendet.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* tst_cat_funkgeraet: Zeitgrenze 300 s

Auf dem macOS-Läufer lief der Prüfstand mit seinen rund 40 Fällen gegen
das rigctld-Doppel schon am 08.11. in die 120 s (lokal ~60 s). Nur für
diesen Prüfstand angehoben.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Zeitgrenze nur setzen, wo der Prüfstand existiert

Linux teilt die Prüfstände auf vier Läufer; in drei davon gibt es
tst_cat_funkgeraet nicht, und set_tests_properties brach das
Konfigurieren ab. Lokal mit allen vier Aufteilungen konfiguriert.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

---------

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