I think this issue has been addressed before, but can't seem to find any definitive resolution to the problem.
The problem is as follows:
Cqrlog starts and operates normally. When there is user interaction, cqrlog remains functional. If cqrlog is left for a short period of time with no user input, then cqrlog hangs and requires a forcible shutdown (kill) to close it.
On occasion, cqrlog will also cause the remote database server to hang. Restarting the service (systemctl restart mysql.service) will restore the database to working condition.
The problem occurs often enough to make me look for alternatives. Is there a definitive resolution to this issue?
Client side:
k4vbb@montech:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.6 LTS
Release: 20.04
Codename: focal
Cqrlog version: Cqrlog Ver:2.5.2 (001) Gtk2 Date:2022-02-21
Server side:
k4vbb@flou18xinfnms10:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.6 LTS
Release: 20.04
Codename: focal
No GUI is installed, and the server only runs the mysql database. Nothing else.
MySQL version:
k4vbb@flou18xinfnms10:~$ mysql -V
mysql Ver 8.0.35-0ubuntu0.20.04.1 for Linux on x86_64 ((Ubuntu))
Network:
1Gbps connection through Alcatel-Lucent OS-645024X to core. Core is Alcatel-Lucent OS6900-40X at 10Gbps. Connection to server is 10Gbps.
HI,
I am also using external sql server, Mariadb running in Fedora 37.
I do not run Cqrlog 27/7, but several hours a day. I have not noticed server connection drops or Cqrlog freezing.
Have you just NewQso window open?
I do have Dxcluster and Rbn monitor open at least. That causes continuous traffic to sql server.
I'm using Alpha 2.6.0(120) and I know at least one local user here running it nearly 24/7 without reporting similar problem you have.
Have you tried to make debug dumps to file?
cqrlog --debug=1 > /tmp/debug.txt
Maybe the lockup situation happens always same way and could be found from debug.
--
Saku
OH1KH
Here is a truncated copy of the log output:
[DEBUG] Name com.canonical.AppMenu.Registrar does not exist on the session bus
Cqrlog Ver:2.5.2 (001) Gtk2 Date:2022-02-21
**** DEBUG LEVEL 0 ****
**** CHANGE WITH --debug=NR PARAMETER ****
*** Parameter -h or --help for details ***
OS:
Linux version 5.15.4-051504-lowlatency (kernel@sita) (gcc (Ubuntu 11.2.0-12ubuntu1) 11.2.0, GNU ld (GNU Binutils for Ubuntu) 2.37) #202111211331 SMP PREEMPT Sun Nov 21 13:59:29 UTC 2021
Settings:
-----------------------------------------------------
RigCtldPath:/usr/local/bin/rigctld
RigCtldArgs:-m 2 -r localhost -t 4532
RunRigCtld: FALSE
RigDevice: localhost
RigCtldPort:4532
RigCtldHost:localhost
RigPoll: 500
RigSendCWR: FALSE
RigChkVfo TRUE
RigId: 2
Not started rigctld process. (Run is set FALSE)
Connected to rigctld @ localhost:4532
Poll Sending: \chk_vfo
Msg from rig: 0
"--vfo" checked:0
WARNING: TGtk2WidgetSet.InvalidateRect refused invalidating during paint message: TStringGrid
Poll Sending: +f +m +v
Msg from rig: GET_FREQ:
FREQUENCY: 7003935
RPRT 0
Msg from rig: GET_MODE:
MODE: CWR
PASSBAND: 480
RPRT 0
GET_VFO:
VFO: VFOA
RPRT 0
Poll Sending: +f +m +v
Msg from rig: GET_VFO:
VFO: VFOA
RPRT 0
Poll Sending: +f +m +v
Poll Sending: +f +m +v
Poll Sending: +f +m +v
Poll Sending: +f +m +v
Poll Sending: +f +m +v
Poll Sending: +f +m +v
Poll Sending: +f +m +v
Poll Sending: +f +m +v
Poll Sending: +f +m +v
Msg from rig: GET_FREQ:
FREQUENCY: 7003935
RPRT 0
Msg from rig: GET_FREQ:
FREQUENCY: 7003935
RPRT 0
Msg from rig: GET_MODE:
MODE: CWR
PASSBAND: 480
RPRT 0
GET_VFO:
VFO: VFOA
RPRT 0
Msg from rig: GET_VFO:
VFO: VFOA
RPRT 0
Poll Sending: +f +m +v
Msg from rig: GET_FREQ:
FREQUENCY: 7038940
RPRT 0
Msg from rig: GET_MODE:
MODE: CWR
PASSBAND: 350
RPRT 0
Msg from rig: GET_VFO:
VFO: VFOA
RPRT 0
Poll Sending: +f +m +v
~~~~~~~~~~~~~~~~~~~~~~~~~~~~TRUNCATED
Msg from rig: GET_FREQ:
FREQUENCY: 7038940
RPRT 0
GET_MODE:
MODE: CWR
PASSBAND: 350
RPRT 0
Msg from rig: GET_VFO:
VFO: VFOA
RPRT 0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~TRUNCATED
Poll Sending: +f +m +v
Poll Sending: +f +m +v
Poll Sending: +f +m +v
Poll Sending: +f +m +v
Poll Sending: +f +m +v
Poll Sending: +f +m +v
Poll Sending: +f +m +v
Poll Sending: +f +m +v
Poll Sending: +f +m +v
~~~~~~~~~~~~~~~~~~~~~~~~~~~~TRUNCATED
Msg from rig: GET_FREQ:
FREQUENCY: 7038940
RPRT 0
GET_MODE:
MODE: CWR
PASSBAND: 350
RPRT 0
Msg from rig: GET_VFO:
VFO: VFOA
RPRT 0
[FORMS.PP] ExceptionOccurred
[FORMS.PP] ExceptionOccurred
Hi.
Cant se anything special there.
Forms.pp erros happen with gtk2 versions time to time but they does not tell anything.
Have you tried to run "save log data to local machine" when Cqrlog starts new thread to run another sql server in .config/cqrlog/database folder?
Then also Qt5 version could be worth of testing. But there is no ready compiled 2.5.2 with Qt5 widgets.
--
Saku
OH1KH
I didn't see anything special either.
When the database is local to the system I do not see any issues. From what I can tell this only happens when the database is remote.
Is there a newer version of CQRLog I can try?
HI!
There is an Alpha version, ready compiled with update script in https://github.com/OH1KH/cqrlog/tree/loc_testing/compiled
Official Cqrlog has also version that is based on Alpha 2.6.0(119), but that is only source. You have to compule it. https://github.com/ok2cqr/cqrlog
--
Saku
OH1KH
You can try upgrading CQRLOG to the latest version to see if the issue is fixed. Additionally, you might also consider installing a script to perform small interactive operations in CQRLOG after a certain period of time without user interaction, such as executing a query Large spatial SQL or send an HTTP time calculator request to the CQRLOG server. This can keep the app running and avoid crashes.
Kanecharles,
I recently DID upgrade to the latest version. However, not only did it NOT fix the issue, the new version introduced a new problem for me. Going to downgrade and see what happens.
The new issue is that with the latest version, CQRLog and hamlib will "lock up" my Ten Tec Orion II. While the rig will still RX, it will not respond to button presses until it is restarted. Once powered off and back on, CQRLog and hamlib appear to work normally.
Issues like this really highlight the need to keep logs somewhere other than the computer I'm using. It's saved my bacon a few times already. Since my data is stored somewhere else, it'll be easy to remove the current version and install an older one.