TMySQL57 - CQRLOG things that mariadb server is gone

37 posts / 0 new
Last post
do2hg
TMySQL57 - CQRLOG things that mariadb server is gone

Hi there,
I have an issue here on my 24/7 shack machine with mariadb & CQRLOG 2.4.0 & Ubuntu 20.04 LTS:

After some hours of no activity, when I click some action that triggers a db-request I get:
TMySQL57Connection : Error executing query: MySQL server has gone away.
Press OK to ignore and risk data corruption.
Press Abort to kill the program.

If I abort and restart everything's fine. The dbserver does not need any action from my side.

I'll try to log the whole thing tomorrow. - On my Laptop I had no problem during my OZ-Holiday when leaving CQRLOG open and putting the machine into standby (not hibernation) - CQRLOG was open many days without problems ... on similar hardware, install & config.

I'll post more details after a debug ...
73 and thanks
Stefan.

va7gp
TMySQL57 - CQRLOG things that mariadb server is gone

I have seen this too! I have seen this after using CQRLOG during the evening, leaving it running overnight, then the message appears the next day when I return to use it. I did not notice this during extended actual use (for example duration of Field Day). The idle (no activity) seems to be an important factor.

However, my configuration is a bit different - I use a separate MariaDB (virtual) server, over my LAN. I had not started to look closely at this, because there are a lot of parts involved - virtual-machine with KVM/QEMU, network-switches, SFP+ fiber-modules, workstation (idle) settings, TCP/IP settings everywhere... :-O

But now that you've identified this also, Stefan, I'll add my experience to this also!

CQRLOG version 2.3.0 compiled from (repository) source, on Gentoo
MariaDB version 10.3.23 installed via apt, on Debian

-Gord VA7GP

oh1kh
TMySQL57 - CQRLOG things that mariadb server is gone

Hi Gord and Stefan!

Gord, I assume a typo in version number 2.3.0. Am I right?
If it really is 2.3.0 you can expect all kinds of troubles.

When leaving cqrlog running does it have any function in use that would use database?
DXCluster, RBNmonitor, wsjt-remote, or is it just "standing by" waiting for new qso input and perhaps polling radio that is also on?

From earlier years I remember that Petr has adjusted (or created. I cant remenber) a database poll to keep mysql happy.
It indeed can have property that it disconnects user if there is no activity.

But this can also happen by network router or firewall if those find out unused connection in their routing tables.

If there is no database usage open DXCluster, RBNmonitor or leave wsjt remote running with CQ monitor and wsjt-x.

Then there is database usage all the time and you can see if that affects.

--
Saku
OH1KH

va7gp
TMySQL57 - CQRLOG things that mariadb server is gone



Saku wrote:
Gord, I assume a typo in version number 2.3.0. Am I right?

Saku, I am embarrassed to admit that I was using the "official" Gentoo version - 2.3.0 - which is all that's available through the Gentoo package-management. But that is not helpful to me, you, nor Stefan... so, I have now installed your latest 6-day-old Alpha 2.4.0(122) version. I will let it run as much as I can - hopefully overnight once or twice this upcoming weekend.

Saku wrote:
When leaving cqrlog running does it have any function in use that would use database?
DXCluster, RBNmonitor

Yes, I left both RBN and DXCluster running the entire time. I am interested to see if your Alpha version 2.4.0(122) with on-going database activity will change things - kindly allow me several days to see...

Thank-you for your reminder about my old version, and helpful suggestions for nudging the database-server.

-Gord VA7GP

do2hg
Hi Gord & Saku,

Hi Gord & Saku,
thanks for the information from your posts.
When I had the machine running in my holiday, I kept the DX-Cluster running. I switched that off yesterday for my overnight test, to have not so many debug messages ... and then both machines (the one in standby and the one running normally) hungup with the DB.

Here are the final lines from the log:
1
2
3
4
5
6
Closing DXCluster window
Closing TRXControl window
Closing GrayLine window
Closing dDXCC
WARNING: TBitBtn.Destroy with LCLRefCount>0. Hint: Maybe the component is processing an event?
Deleting config file: cqrlog.cfg
Deleting config file: 2cqrlog.cfg
Closing dData
Closing ini file ...
Closing dData
Note: GetTextBuf is overridden for:
Access violation
Killed

(NB: I had to kill manually, as the "Abort" did not fully end CQRLOG).

But If I get Saku right, just switching the Cluster or RBN on should insure DB-activity and hence avoid this problem. So I tried again lst night with DX-Cluster (Web), as this will not log me out after some time.However, on the machine left on (no standby), CQRLOG crashed again, here the final debug messages:

Closing DXCluster window
Closing TRXControl window
Closing GrayLine window
Closing ini file ...
Closing dDXCC
[FORMS.PP] ExceptionOccurred
Invalid file handle

On the other machine (DX-Cluster via telnet & standby) CQRLOG survived the night.
... this is really odd.

73 & Thanks
Stefan.

73
Stefan.

--
Stefan
DB4ST (ex DO2HG) --- German Ham Radio Station
D-32584 Löhne ----- Locator JO42IE

oh1kh
TMySQL57 - CQRLOG things that mariadb server is gone

Hi !

Just to check are you running alpha or official?

Is that error text really from crash, or does it come from trying to close stopped cqrlog?
I think that if cqrlog gets stuck it does not make "closing...." lines.

What I am after is that when cqrlog seems to be dead it is not (in the means that not all processes are dead, perhaps just ones that product screen update) and when you try to close it it still can do some closing operations but not up to final stage.
When you notice cqrlog is dead and you have debug messages on check what are the latest messages (without trying to close cqrlog) and does there appear any new debug lines after the main display(s) are not anymore updating.

--
Saku
OH1KH

va7gp
TMySQL57 - CQRLOG things that mariadb server is gone

I left CQRLOG running overnight, with RBN and HamQTH DXCluster running.
When I returned in the morning, I noticed that the BandMap is still updating, and the DXCluster is still running.
I then tried double-clicking on a BandMap entry - that's when I got the error

TMySQL57Connection : Error executing query: MySQL server has gone away.

Perhaps the attached screenshot will help. I did not start CQRLOG in a console, so I have no further debug information. I'll try console-launch later.

I was curious after receiving the MySQL error - I wanted to see "how much" of CQRLOG would continue to work. Using the TRX Control, I can change Modes, but I cannot change bands. Attempting to change bands also produces the MySQL error message.

For connection to my rig, I am using FLRig. I started FLRig in a console, and this displays no errors. FLRig continues to change rig frequency, mode, VFO, filter, etc. FLRig and also CQRLOG properly update the frequency when I manually tune.

I am running CQRLOG Alpha 2.4.0(122)

Thank-you, Saku,
-Gord VA7GP

File: 

oh1kh
TMySQL57 - CQRLOG things that mariadb server is gone

Thanks Gord!

First Google hit: https://matomo.org/faq/troubleshooting/faq_183/
Might be worth of trying that if cqrlog seems to be somehow still alive.

--
Saku
OH1KH

do2hg
Hi Saku,

Hi Saku,
... this reads really interesting.
Just added the wait_timeout = 28800 to the [mysqld] section of my config.
Looking forward, to what happens tomorrow ...

Thanks again & 73
Stefan.

--
Stefan
DB4ST (ex DO2HG) --- German Ham Radio Station
D-32584 Löhne ----- Locator JO42IE

va7gp
TMySQL57 - CQRLOG things that mariadb server is gone

Saku wrote:
Might be worth of trying that <...>

Good idea!

So, at my (remote/LAN) server, I find that the existing timeout is already what your article suggests:

MariaDB [(none)]> SHOW SESSION VARIABLES LIKE 'wait_timeout';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wait_timeout | 28800 |
+---------------+-------+

But the second suggestion may be useful, because my innodb_log_file_size is smaller:

MariaDB [(none)]> SHOW SESSION VARIABLES LIKE 'innodb_log_file_size';
+----------------------+----------+
| Variable_name | Value |
+----------------------+----------+
| innodb_log_file_size | 50331648 |
+----------------------+----------+

I added this line to my conf-file, re-started MariaDB and checked it:

innodb_log_file_size = 256MB

MariaDB [(none)]> SHOW SESSION VARIABLES LIKE 'innodb_log_file_size';
+----------------------+-----------+
| Variable_name | Value |
+----------------------+-----------+
| innodb_log_file_size | 268435456 |
+----------------------+-----------+

And the third suggestion - my max_allowed_packet is set at ~16MB:

MariaDB [(none)]> SHOW SESSION VARIABLES LIKE 'max_allowed_packet';

+--------------------+----------+
| Variable_name | Value |
+--------------------+----------+
| max_allowed_packet | 16777216 |
+--------------------+----------+

So I added this line to my conf-file and checked it:

max_allowed_packet = 128M

MariaDB [(none)]> SHOW SESSION VARIABLES LIKE 'max_allowed_packet';
+--------------------+-----------+
| Variable_name | Value |
+--------------------+-----------+
| max_allowed_packet | 134217728 |
+--------------------+-----------+

Let me see what happens now...

-Gord VA7GP

do2hg
Hi there,

Hi there,
I made another couple of tries.

No.1 - Laptop, all changes to mariadb config like described by Gord
When selecting QSO from QSO-list for "View" I got the message again, BUT CQRLOG closed clean when clicking "Abort".

Here's the log-tail from the end:
DX de F5EAN: 1296200.0 EA1UR IN96DKIN53TF 51 0928Z
Enter critical section On Receive
Leave critical section On Receive
Found - EA1UR
SELECT * FROM cqrlog_common.bands where (b_begin <=1296.2 AND b_end >=1296.2) ORDER BY b_begin

SELECT * FROM cqrlog_common.bands where (b_begin <=1296.2 AND b_end >=1296.2) ORDER BY b_begin

SELECT id_cqrlog_main FROM cqrlog002.cqrlog_main WHERE adif=281 AND band='23CM' AND ((qsl_r='Q') OR (lotw_qslr='L')) AND mode='SSB' LIMIT 1

SELECT id_cqrlog_main FROM cqrlog002.cqrlog_main WHERE adif=281 AND band='23CM' AND mode='SSB' LIMIT 1

SELECT id_cqrlog_main FROM cqrlog002.cqrlog_main WHERE adif=281 AND band='23CM' LIMIT 1

SELECT id_cqrlog_main FROM cqrlog002.cqrlog_main WHERE adif=281 LIMIT 1

dx_prefix:EA
dx_cont: EU
Freq: 1296.2
Call: EA1UR
Color: clBlack
Index_: 2
Cannot show this sport because of settings ...
Found - NX4TT
SELECT * FROM view_cqrlog_main_by_qsodate WHERE idcall = 'NX4TT' ORDER BY qsodate,time_on

DX de F5RJK: 18156.0 YU3AWA 59+ 0927Z
Enter critical section On Receive
Leave critical section On Receive
Found - YU3AWA
SELECT * FROM cqrlog_common.bands where (b_begin <=18.156 AND b_end >=18.156) ORDER BY b_begin

SELECT * FROM cqrlog_common.bands where (b_begin <=18.156 AND b_end >=18.156) ORDER BY b_begin

SELECT id_cqrlog_main FROM cqrlog002.cqrlog_main WHERE adif=296 AND band='17M' AND ((qsl_r='Q') OR (lotw_qslr='L')) AND mode='SSB' LIMIT 1

SELECT id_cqrlog_main FROM cqrlog002.cqrlog_main WHERE adif=296 AND band='17M' AND mode='SSB' LIMIT 1

SELECT id_cqrlog_main FROM cqrlog002.cqrlog_main WHERE adif=296 AND band='17M' LIMIT 1

dx_prefix:YU
dx_cont: EU
Freq: 18.156
Call: YU3AWA
Color: clBlack
Index_: 3
Color for xplanet:0xFFFFFF
2020-08-09 11:28:57 add to bandmap YU3AWA
Color: clFuchsia
Index_: 3
TelThread.Execute - before Synchronize(@frmDXCluster.SynTelnet)
TelThread.Execute - after Synchronize(@frmDXCluster.SynTelnet)
Deleted data on position:0
select id_cqrlog_main from cqrlog_main where (callsign= 'YU3AWA') and (band = '17M') and (mode = 'SSB') and (str_to_date(concat(qsodate,' ',time_on), '%Y-%m-%d %H:%i')) > str_to_date('2020-08-07 11:28', '%Y-%m-%d %H:%i')

DX de SQ9GIN: 3700.0 SP5XTY/P GRJ-050 0929Z JO90
Enter critical section On Receive
Leave critical section On Receive
NOT found - T20DX
SELECT * FROM cqrlog_common.bands where (b_begin <=3.7 AND b_end >=3.7) ORDER BY b_begin

SELECT * FROM cqrlog_common.bands where (b_begin <=3.7 AND b_end >=3.7) ORDER BY b_begin

SELECT id_cqrlog_main FROM cqrlog002.cqrlog_main WHERE adif=269 AND band='80M' AND ((qsl_r='Q') OR (lotw_qslr='L')) AND mode='SSB' LIMIT 1

dx_prefix:SP
dx_cont: EU
Freq: 3.7
Call: SP5XTY/P
Color: clBlack
Index_: 0
Color for xplanet:0xFFFFFF
2020-08-09 11:29:00 add to bandmap SP5XTY/P
Color: clBlack
Index_: 0
TelThread.Execute - before Synchronize(@frmDXCluster.SynTelnet)
TelThread.Execute - after Synchronize(@frmDXCluster.SynTelnet)
Deleted data on position:0
select id_cqrlog_main from cqrlog_main where (callsign= 'SP5XTY/P') and (band = '80M') and (mode = 'SSB') and (str_to_date(concat(qsodate,' ',time_on), '%Y-%m-%d %H:%i')) > str_to_date('2020-08-07 11:29', '%Y-%m-%d %H:%i')

DX de EC5A: 7060.0 EA4CT CME 0929Z IM98
Enter critical section On Receive
Leave critical section On Receive

Found - EA4CT
SELECT * FROM cqrlog_common.bands where (b_begin <=7.06 AND b_end >=7.06) ORDER BY b_begin

SELECT * FROM cqrlog_common.bands where (b_begin <=7.06 AND b_end >=7.06) ORDER BY b_begin

SELECT id_cqrlog_main FROM cqrlog002.cqrlog_main WHERE adif=281 AND band='40M' AND ((qsl_r='Q') OR (lotw_qslr='L')) AND mode='SSB' LIMIT 1

dx_prefix:EA
dx_cont: EU
Freq: 7.06
Call: EA4CT
Color: clBlack
Index_: 0
Color for xplanet:0xFFFFFF
2020-08-09 11:29:05 add to bandmap EA4CT
Color: clBlack
Index_: 0
TelThread.Execute - before Synchronize(@frmDXCluster.SynTelnet)
TelThread.Execute - after Synchronize(@frmDXCluster.SynTelnet)
Deleted data on position:0
select id_cqrlog_main from cqrlog_main where (callsign= 'EA4CT') and (band = '40M') and (mode = 'SSB') and (str_to_date(concat(qsodate,' ',time_on), '%Y-%m-%d %H:%i')) > str_to_date('2020-08-07 11:29', '%Y-%m-%d %H:%i')

DX de SV1RRV: 18079.0 HA50KHW 50 Anniversary of Radio Sport 0929Z
Enter critical section On Receive
Leave critical section On Receive
Found - HA50KHW
SELECT * FROM cqrlog_common.bands where (b_begin <=18.079 AND b_end >=18.079) ORDER BY b_begin

SELECT * FROM cqrlog_common.bands where (b_begin <=18.079 AND b_end >=18.079) ORDER BY b_begin

SELECT id_cqrlog_main FROM cqrlog002.cqrlog_main WHERE adif=239 AND band='17M' AND ((qsl_r='Q') OR (lotw_qslr='L')) AND mode='CW' LIMIT 1

SELECT id_cqrlog_main FROM cqrlog002.cqrlog_main WHERE adif=239 AND band='17M' AND mode='CW' LIMIT 1

SELECT id_cqrlog_main FROM cqrlog002.cqrlog_main WHERE adif=239 AND band='17M' LIMIT 1

dx_prefix:HA
dx_cont: EU
Freq: 18.079
Call: HA50KHW
Color: clBlack
Index_: 3
1
2
3
4
5
6
Closing DXCluster window
Closing TRXControl window
Closing GrayLine window
Closing dDXCC
Deleting config file: 2cqrlog.cfg
Deleting config file: cqrlog.cfg
Closing dData
Closing ini file ...
Closing dData
[FORMS.PP] ExceptionOccurred
[FORMS.PP] ExceptionOccurred

But I cannot see anything enlightning in there ...

No.2 - Shack-PC, only timeout-changes made to mariadb config
When selecting QSO from QSO-list for "View" I got the message again, when clicking "Abort", CQRLOG hangs in the shutdown process. After a bit clicking around, I get a system dialog "CQRLOG does not answer. - Kill or wait?" then I clicked kill.
Here the log-tail:

Reconnected as DB4ST at 37.201.144.13, this instance is disconnected

SELECT * FROM profiles WHERE visible > 0 ORDER BY nr

1
2
3
4
5
6
Closing DXCluster window
Closing TRXControl window
Closing GrayLine window
Closing ini file ...
Closing dDXCC
[FORMS.PP] ExceptionOccurred
Invalid file handle
Getötet

The first line is the loss of the telnet-connection to the cluster.
The second line is the select of the qso, when cqrlog goes tits-up.

The [FORMS.PP] ExceptionOccurred seems to be the interesting message ...

Hope this helps.
73
Stefan.

--
Stefan
DB4ST (ex DO2HG) --- German Ham Radio Station
D-32584 Löhne ----- Locator JO42IE

do2hg
Hi Saku,

Hi Saku,
I think my version is "official" - it comes with Ubuntu 20.04 and reads
2.4.0 (001) 2019-10-27

I'll have another go with the debug info later.
The last 4 hours I set the shack PC to standby. - CQRLOG apparently survived this while being connected to the cluster with telnet (though the telnet-connection died on the way).

73
Stefan

--
Stefan
DB4ST (ex DO2HG) --- German Ham Radio Station
D-32584 Löhne ----- Locator JO42IE

va7gp
TMySQL57 - CQRLOG things that mariadb server is gone

I invoked CQRLOG with debug=1 but that didn't seem to provide helpful information :-(

On the other hand, my database server shows one helpful error, approaching 3am (perhaps after 7hrs of inactivity:

2020-08-09 2:56:14 41 [Warning] Aborted connection 41 to db: 'cqrlog001' user: 'cqrlog' host: '2001:470:1f05:be:5092:fd46:5a19:bded' (Got timeout rea
ding communication packets)

Although CQRLOG was running overnight, this is the only error.log entry from midnight (log-rollover) until 7am... (BTW - that IPv6 address is my ham-radio workstation, where CQRLOG / FLRig / etc are running. My DB server listens on all interfaces, and I don't specify anything more than server/port in CQRLOG. Somwhere, somehow my system "chooses" by itself to use IPv4 or IPv6... generally speaking, I prefer IPv6 for everything, because it's reachable from the world, with NAT/port-forwarding).

When I check the (non-error) log-file, I see "normal" entries like these, beginning at midnight (log rollover):

/usr/sbin/mysqld, Version: 10.3.23-MariaDB-0+deb10u1-log (Debian 10). started with:
Tcp port: 3306 Unix socket: /run/mysqld/mysqld.sock
Time Id Command Argument
46 Query flush local slow logs
46 Quit
200809 0:00:37 42 Query ROLLBACK
42 Query START TRANSACTION
42 Query SELECT * FROM cqrlog_common.bands where (b_begin =7.108) ORDER BY b_begin
42 Query START TRANSACTION
42 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=281 AND band='40M' AND ((qsl_r='Q') OR (lotw_qslr='L')) AN
D mode='SSB' LIMIT 1
42 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=281 AND band='40M' AND mode='SSB' LIMIT 1
42 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=281 AND band='40M' LIMIT 1
42 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=281 LIMIT 1
42 Query ROLLBACK
200809 0:00:45 42 Query ROLLBACK
42 Query START TRANSACTION
42 Query SELECT * FROM cqrlog_common.bands where (b_begin =7.178) ORDER BY b_begin
42 Query START TRANSACTION
42 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=248 AND band='40M' AND ((qsl_r='Q') OR (lotw_qslr='L')) AN
D mode='SSB' LIMIT 1

<...>

42 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=248 AND band='10M' AND mode='CW' LIMIT 1
42 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=248 AND band='10M' LIMIT 1
42 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=248 LIMIT 1
42 Query ROLLBACK
200809 6:44:07 42 Query ROLLBACK
200809 6:44:08 42 Query START TRANSACTION
42 Query SELECT * FROM cqrlog_common.bands where (b_begin =50.09) ORDER BY b_begin
42 Query START TRANSACTION
42 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=236 AND band='6M' AND ((qsl_r='Q') OR (lotw_qslr='L')) AND mode='CW' LIMIT 1
42 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=236 AND band='6M' AND mode='CW' LIMIT 1
42 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=236 AND band='6M' LIMIT 1
42 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=236 LIMIT 1
42 Query ROLLBACK
200809 6:44:25 42 Query ROLLBACK

At this point, I'm puzzled...? It sort of looks, to me, like the database did experience an error, but that CQRLOG continued to transact with it, but only failed when I arrived and double-clicked a BandMap spot...?

-Gord VA7GP

va7gp
TMySQL57 - CQRLOG things that mariadb server is gone

The MariaDB server-log below shows the final active-entry (from me, working Rarotonga!) at 8:30pm. About 50min later is the last BandMap update...??? At 6:30am when I arrived back in the shack, the BandMap was completely empty, yet the cqrlog-log (debug=4) shows continuing DX Cluster spots.

200809 20:30:13 57 Query START TRANSACTION
57 Query select id_notes from notes where callsign = 'E51JD' limit 1
57 Query COMMIT
57 Query START TRANSACTION
57 Query insert into cqrlog_main (qsodate,time_on,time_off,callsign,freq,mode,rst_s,rst_r,name,qth,qsl_s,qsl_r,qsl_via,iota,pwr,itu,waz,loc,my_loc,county,award,remarks,adif,idcall,state,qso_dxcc,band,profile,cont,club_nr1,club_nr2,club_nr3,club_nr4,club_nr5, prop_mode, satellite, rxfreq, srx, stx,srx_string, stx_string, contestname, dok) values('2020-08-10','03:30','03:30','E51JD',14.225,'SSB','59','59','Jim','Rarotonga, South Cook Islands','','','','','1500',63,32,'','CN89ne','','','',234,'E51JD','',0,'20M',-1,'OC','','','','','','','',null,'','','','','','')
57 Query COMMIT
200809 20:30:14 57 Query START TRANSACTION
57 Query SELECT * FROM profiles WHERE visible > 0 ORDER BY nr
57 Query ROLLBACK
57 Query START TRANSACTION
57 Query SELECT * FROM profiles WHERE nr = -1
57 Query ROLLBACK
200809 20:46:14 58 Query ROLLBACK
58 Query START TRANSACTION
58 Query SELECT * FROM cqrlog_common.bands where (b_begin =14.225) ORDER BY b_begin
58 Query START TRANSACTION
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=291 AND band='20M' AND ((qsl_r='Q') OR (lotw_qslr='L')) AND mode='SSB' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=291 AND band='20M' AND mode='SSB' LIMIT 1
58 Query ROLLBACK
200809 20:56:48 58 Query ROLLBACK
58 Query START TRANSACTION
58 Query SELECT * FROM cqrlog_common.bands where (b_begin =7.009) ORDER BY b_begin
58 Query START TRANSACTION
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=239 AND band='40M' AND ((qsl_r='Q') OR (lotw_qslr='L')) AND mode='CW' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=239 AND band='40M' AND mode='CW' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=239 AND band='40M' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=239 LIMIT 1
58 Query ROLLBACK
200809 20:57:09 58 Query ROLLBACK
58 Query START TRANSACTION
58 Query SELECT * FROM cqrlog_common.bands where (b_begin =7.015) ORDER BY b_begin
58 Query START TRANSACTION
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=212 AND band='40M' AND ((qsl_r='Q') OR (lotw_qslr='L')) AND mode='CW' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=212 AND band='40M' AND mode='CW' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=212 AND band='40M' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=212 LIMIT 1
58 Query ROLLBACK
200809 20:59:21 58 Query ROLLBACK
58 Query START TRANSACTION
58 Query SELECT * FROM cqrlog_common.bands where (b_begin =7.015) ORDER BY b_begin
58 Query START TRANSACTION
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=212 AND band='40M' AND ((qsl_r='Q') OR (lotw_qslr='L')) AND mode='CW' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=212 AND band='40M' AND mode='CW' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=212 AND band='40M' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=212 LIMIT 1
58 Query ROLLBACK
200809 21:02:50 58 Query ROLLBACK
58 Query START TRANSACTION
58 Query SELECT * FROM cqrlog_common.bands where (b_begin =7.18) ORDER BY b_begin
58 Query START TRANSACTION
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=291 AND band='40M' AND ((qsl_r='Q') OR (lotw_qslr='L')) AND mode='SSB' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=291 AND band='40M' AND mode='SSB' LIMIT 1
58 Query ROLLBACK
200809 21:03:24 58 Query ROLLBACK
58 Query START TRANSACTION
58 Query SELECT * FROM cqrlog_common.bands where (b_begin =7.177) ORDER BY b_begin
58 Query START TRANSACTION
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=248 AND band='40M' AND ((qsl_r='Q') OR (lotw_qslr='L')) AND mode='SSB' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=248 AND band='40M' AND mode='SSB' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=248 AND band='40M' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=248 LIMIT 1
58 Query ROLLBACK
200809 21:04:13 58 Query ROLLBACK
58 Query START TRANSACTION
58 Query SELECT * FROM cqrlog_common.bands where (b_begin =7.012) ORDER BY b_begin
58 Query START TRANSACTION
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=21 AND band='40M' AND ((qsl_r='Q') OR (lotw_qslr='L')) AND mode='CW' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=21 AND band='40M' AND mode='CW' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=21 AND band='40M' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=21 LIMIT 1
58 Query ROLLBACK
200809 21:19:05 58 Query ROLLBACK
58 Query START TRANSACTION
58 Query SELECT * FROM cqrlog_common.bands where (b_begin =3.842) ORDER BY b_begin
58 Query START TRANSACTION
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=291 AND band='80M' AND ((qsl_r='Q') OR (lotw_qslr='L')) AND mode='SSB' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=291 AND band='80M' AND mode='SSB' LIMIT 1
58 Query SELECT id_cqrlog_main FROM cqrlog001.cqrlog_main WHERE adif=291 AND band='80M' LIMIT 1
58 Query ROLLBACK
200810 0:01:15 62 Connect root@localhost as anonymous on
62 Query flush local error logs
62 Query flush local engine logs
62 Query flush local general logs

1) I wonder why CQRLOG ceases to communicate with the MariaDB server?
2) I wonder if the 1:15am "housekeeping" log-rollover may be affecting CQRLOG?

-Gord VA7GP

oh1kh
TMySQL57 - CQRLOG things that mariadb server is gone

Hi Gord!

Good questions!
Yesterday evening I decided to leave cqrlog running to see what happens. Unfortunately without debug option.

In my setup I use Maridb database server running in same PC (the "real one" at port 3306) that is replicating with my server MariaDB via home LAN.
I left DXCluster, bandmap,Wsjt remote with wsjt-Map, TRxControl,Rotcontrol,GridMap,both propagations, Grayline and reminder open with wsjt-x. That is my usual setup.
In morning, after about 12 hours, wsjtx was still running and wsjt-Map was showing decodes. Reminder had alerted (afrer 45 mins). Everything seems o be ok BUT: DXCluster was stopped and also BandMap was empty.
Cqrlog was still in full control and after resetting Reminder and disconnecting and reconnecting DXCluster new spots started to flow and BandMap started to fill again.

So it seems that the problem lies somewhere in DXCLuster. There has been complains about DXCluster connect(spot flow stops) before.

When looking at source DXCLuster uses Lazarus'es own lnet unit to make connection. Wsjt remote uses synaptic telnet unit.
The difference between them is that lnet can produce event when there is something in RX buffer. Synaptic does not have that feature and it must be polled by the host program to see has something arrived to RX buffer.
On the other hand I think that you (or someone else) said that debug still shows spots arrive but never printed to DXCluster window. That would prove that lnet receiving side is working and producing events but spot handling has something that fails.
In that point the communication with MariaDB comes in.

But how we could catch the problem?

It might even be a very small issue in source. But it can also be problem in Lazarus sql unit.

--
Saku
OH1KH

oh1kh
TMySQL57 - CQRLOG things that mariadb server is gone

Hi!

Last night I had different setup.
I created a new log, imported settings from my regular log, except rig. I used #1 (dummy rig).
I left cqrlog runnig with only Band map and DXCluster open and connected. At this time with debug=1 and saving to file.
It has now run longer (over 12hours) than last test and it is still running.

DXCluster gets spots and band map is populated. Difference with Band map now is that it shows "all bands". At last time it was "current band".

This shows how difficult it is to catch the problem!

--
Saku
OH1KH

oh1kh
TMySQL57 - CQRLOG things that mariadb server is gone

Weeee!

Even when all looked ok and new spots arrived and populated Band map after writing my last message I decided to close cqrlog.
Then: " TMySQL57 connection: Error execuitng query: MySql server has gone away"

The splash is still on screen and I can see new spots coming and Band map populating on the background.

When looking at debug.txt some oddities can be found. Like memory buffer overflows. They are from time after getting the error splash to screen:

TelThread.Execute - afwhere (callsign=
Colllsign= 'R8XT')
TUS3ITU') and (band = '2M')
Color for xd = '2M') and (mode = 'SSB')

and finally when aborting

[FORMS.PP] ExceptionOccurred

But I think loosing Database connection at close has nothing to do with DXCluster spot flow stop.

This is proper close:

select count(*) from cqrlog009.cqrlog_config

Saving ini file to database
1
2
3
4
5
6
Closing DXCluster window
Closing TRXControl window
Closing GrayLine window
Closing dDXCC
Deleting config file: 9cqrlog.cfg
Deleting config file: cqrlog.cfg
Closing dData
Closing ini file ...

This is MySql server lost , close:
select count(*) from cqrlog009.cqrlog_config

Here should be: "Saving ini file to database" and "MySql server has gone" happens at this time
1
2
3
4
5
6
Closing DXCluster window
Closing TRXControl window
Closing GrayLine window
Closing dDXCC
Deleting config file: 9cqrlog.cfg
Closing dData
Closing ini file ...
Closing dData
[FORMS.PP] ExceptionOccurred

And as said: despite the error splash spots were flowing at background.
I think that means we have two problems that may not be related:
- Why DXCluster spot flow stops ?
- Why MySql server connection breaks ? (and when? at 00:00 PC's time?)

--
Saku
OH1KH

oh1kh
TMySQL57 - CQRLOG things that mariadb server is gone

This is not new. See three last comments: https://www.cqrlog.com/comment/1034

--
Saku
OH1KH

oh1kh
TMySQL57 - CQRLOG things that mariadb server is gone

Found interesting things:
To keep database connection alive: https://mariadb.com/kb/en/mysql_ping/

Cqrlog actually have DBPingTimer that is enabled and running with period of 5 min (300 sec). But the ping procedure that should be run every 5mins is commented out. So there are no pings.

Instead there are settings like this:
MainCon.KeepConnection := True;

But when reading Lazarus/Freepascal definitions they say:

Description
KeepConnection is provided for Delphi compatibility, and is not used in the Free Pascal implementation of TDatabase.

If I understand this right there is no KeepConnection to happen, so ping is the way to keep it running.
I have now restored then out commented ping source and modified it a bit and will next test did it make any effect.

--
Saku
OH1KH

va7gp
TMySQL57 - CQRLOG things that mariadb server is gone

Hi, Saku:

Thank-you! I have downloaded / installed your latest 2.4.0(123) version. First comment: DXCluster seems to take a while (couple of minutes?) before any spots appear... I thought it was broken :-( but maybe this is a side-effect of the 5min ping change you made? But if I am patient during startup, eventually DXCluster spots appear.

I'll let things run a lot, over the weekend, and see how it goes...

best wishes,
-Gord VA7GP

ref (I used cqr2.zip for my 64-bit GTK2 system):
https://github.com/OH1KH/cqrlog/tree/loc_testing/compiled

do2hg
still stable?

Hi Gord,
... have been very busy the past fortnight, so I didn't manage to test anything.
Is the updated Version still running stable in the long run?

@Saku: Do you know, whether an official new release is planned in the near future, and will this feature be "in"?
I shy a bit away from manually installing stuff on my "productive" box ...

Cheers, and 73
Stefan.

--
Stefan
DB4ST (ex DO2HG) --- German Ham Radio Station
D-32584 Löhne ----- Locator JO42IE

oh1kh
still stable?

HI!
alpha 2.4.0(123) was not stable. At least here and at other ham near by who reported to me.
The ping causes (I believe so) several mysql database errors that were not there in (122).

I release (124) that has ping again disabled and it is up to date with official source (at date of last Friday)

I was away during weekend and now got new report that (124) has something with qsl label printing that (122) did not have. I have to look at it during next week.

I do not know release table. Depends how much Petr can spend time for cqrlog. Meanwhile we have to go with self compile from source or with alpha binary updates.

--
Saku
OH1KH

dl1mtg
dl1mtg's picture
still stable?

Hello Saku,

same issue here with 123 and 124 - loosing database connection!
Now I changed to self-compiled ok2cqr version (4cdbd2d) and all is stable again.

--
73 de Martin, DL1MTG

oh1kh
still stable?

Hi Martin!

Funny!
I do not remember there is any difference now with Petr's source and alpha when talking about DXCluster part.

But do you compare alpha binary and self-compiled ok2cqr version?
What about if you clone alpha source from GitHub and compile it? Could it make difference as the alpha binary is compiled with Fedora 31?

--
Saku
OH1KH

dl1mtg
dl1mtg's picture
still stable?

Hi Saku,

some time earlier I've had problems with the pre-compiled versions - all qt5 ones.
So I started to use self-compile cqrlog from source.

Today I compared v126 qt5 pre-compiled
with v126 qt5 self-compiled and debug=1:
=> pre-compiled: begins to start, cannot find sql-server (only one try) it aborts
=> self compiled: begins to start, cannot find sql-server (frist try)... next try: startup successful!

I'am using Linux Mint 20 Ulyana, 64Bit with Lazarus 2.0.6

--
73 de Martin, DL1MTG

oh1kh
still stable?

Ok Martin!

I nearly expected that!
As cqrlog does not use static libraries it may happen that precompiled does not start if differences are too big.

That's why we should have script that first checks and loads fpc, Lazarus and everything else needed and then launches make at cqrlog source directory.
Like for example HP printer software is installed, from script not from package.

--
Saku
OH1KH

SP2L
SP2L's picture
Deleting entry from log_list

Greetings.

Is there simplest way for deleting unwanted entry from log_list
other than tinkering directly in cqrlog_common database?

See attached picture log_list.png (SP2L-trash).

Take care.

File: 

Best regards.
Tom - SP2L
https://www.sp2l.ampr.org

SP2L
SP2L's picture
Deleting entry from log_list

[Edited]
Greetings.

Is there simplest way for deleting unwanted entry from log_list
other than tinkering directly in cqrlog_common database?

See attached picture log_list.png (SP2L-trash).
Forgot to mention that "Delete log" option
in CQRLog "Database connection" utility doesn't work.

Take care.

File: 

Best regards.
Tom - SP2L
https://www.sp2l.ampr.org

oh1kh
Deleting entry from log_list

Answer is no simple way.

Just use sql interface and remove it.
I have also one log that I have messed up. #5 It does not show on list, so no delete with delete button.
And a new log creation with #5 is impossible.

I know I could fix that manually from sql console but I have been too lazy to do it... I just change offered number 5 to another in new log creation.

--
Saku
OH1KH

SP2L
SP2L's picture
Deleting entry from log_list

Hello Saku.

Looked a while longer at issue in question.

"Delete log" item on "Database connection" window
doesn't say "Delete database"!

On previously attached picture "log_list.png"
there is _NO_ database named "cqrlog002"
but there is entry in MySQL log_list table:
id_log_list 2
log_nr 2
log_name "SP2L-trash"

As a consequence this is displayed on "Database connection" window,
whereas in reality MySQL database "cqrlog002" (log_name - SP2L-trash) doesn't exist!!!

So, no way to delete something simply non-existent, no doubt!
But from the other hand, on "Database connection" window
it is not plainly visible as there is "log_nr 2" "log_name SP2L-trash"...

At the moment I do not remember chronologically
how it happen that I do not have MySQL database "cqrlog002"
and still having "log_name SP2L-trash"...

Deleted entry "SP2L-trash" from MySQL database
thus clearing displayed log list in "Database connection" window
and dismissing minor issue, Hi!

Would it be feasible to equal MySQL database name
with CQRLog log_name?

Take care.

File: 

Best regards.
Tom - SP2L
https://www.sp2l.ampr.org

oh1kh
Deleting entry from log_list

Yes yes!

But be aware that it can happen also other way round:
There is no log number X, it offers the X when create a new log but you can not create it because X "is in use". But still there is no name on list with number X and no database in server.

So it is no wonder that you have name in list and it is pointing nowhere. It just the same thing. Opposite.

Naming databases as "cqrlogxxx" makes it easy to handle them inside the code. If databases have "wild names" source should be different.

For normal use this is insignificant. It works fine, so why touch to working code.
The mess up happens usually when cqrlog has died at critical section. Power failure, network breakdown (if database is at different machine) or unexpected behavior of user.

The code is not fool proof (it would be much bigger).
Some examples:
If you go from NewQSO to File/Open or create new database you can delete currently open log. Or you can import log settings there for currently open log.
Both are fatal and fixed now in latest source (but all package installs still carry these bugs).

And sure there are lot more things that user can do, but he should not and that is not expected to happen.

Just found that mark your logged qso as "Qsl sent", but then later mark it back to empty. qsl_s is empty, but qsl_sent_date still carry the date qsl was marked to be sent at first time.
How ever this is not fatal and needs no fix. Except for perfectionists.

--
Saku
OH1KH

sm0kbd
TMySQL57 - CQRLOG things that mariadb server is gone

I also have the famous "TMySQL57Connection : Error executing query: MySQL server has gone away." error. I see the same behaviour as seen by many, namely that it is in the morning after leaving WSJT-X and CQRLOG running over night this pop-up. In order to trace the problem I did first run CQRLOG in debug from the console. This revealed nothing more than mentioned above.

Then I started Wireshark checking all mysql traffic.

Some findings:

1) When CQRLOG crashed there were no traffic from the PC running CQRLOG to my generic MySQL server. Does this mean that it is not the server that times out the connection? I will try to do some further investigations on the matter.
2) When CQRLOG starts up there are actually FIVE different threads setup, i.e. there are five different logins and acknowledgements from the server back to the CQRLOG. Could it be so that not all of them have a keep alive timer? I have not seen any kind of re-connection / re-establishing over the MySQL connection when leaving CQRLOG it running for a long time, i.e. over night.

I am using 2.4.0 (001) 2019-10-27 on a Linux Mint 20 Cinnamon and the MySQL server on a Debian 10 VM

/Thomas

---
Thomas
SM0KBD

oh1kh
TMySQL57 - CQRLOG things that mariadb server is gone

Hej Thomas!

Can you check that there was not linux autoupdate during the night?

I do not use autoupdates, but just two days ago I started update manually. Quite manu updates to various programs including MariaDB.
While update was running on one desktop I had cqrlog on other and worked with programming on third.

Suddenly I got that same splash "Maridb server has gone away".
At that time I switched to first desktop and saw that script had just run MariDB part of update.

Could it be same problem with your system, or does it happen so often that it can not be system update during night?

--
Saku
OH1KH

oh1kh
TMySQL57 - CQRLOG things that mariadb server is gone

Hej again!

As always, I forgot another thing.
If it happens always during night, could it be the time server system rotates it's daily logs? (and breaks the connection somehow)

If MariaDB server network connection disappears silently (at network's or server's side) cqrlog thinks it has still connection. Then next query will produce timeout.

Somehow I remember that freepascal/Lazarus SQL unit can not recover connection if it breaks. I'm not sure, it has some time since this was discussed.
Or was it so that there is SQL keepalive command to make Delphi compatibility, but actually it does not do anything in FPC?
That can be found by some Googling.

This kind of problem is very difficult to track.

--
Saku
OH1KH

sm0kbd
TMySQL57 - CQRLOG things that mariadb server is gone

Hi Saku,

thanks for your comments!

I am looking further into this problem. But as it take some time to get it to crash I might not have more info for some more days.

Anyhow:

1) It happens every night, at least until now. Which probably roll out the auto-update.
2) I have now disabled the logrotation for the mysql error.log. This could be a problem so lets see how the disabling impacts the crash.
3) There is no apparent communication via tcp using the mysql filter in wireshark when it crashes.
4) There is however one thing in the mysql error.log which I have not yet correlated to an action in cqrlog.
"020-11-19 16:16:38 8396 [Warning] Aborted connection 8396 to db: 'cqrlog001' user: 'cqrlog' host: 'xxxxxx' (Got timeout reading communication packets)"
5) The "Aborted_clients" status counter in mysql is incremented when it crashes.

That is all for now! :)

---
Thomas
SM0KBD

oh1kh
TMySQL57 - CQRLOG things that mariadb server is gone

Hi Thomas!

This is a very long thread and I tried to find earlier discussion about this subject without results. Just understanding that they all are in this thread.
I tried to do something in August, but that code was unstable and I did give up then.

I hope yo can find something new from this bug.

--
Saku
OH1KH

sm0kbd
New thread?

Shall we make a new thread out of it?

---
Thomas
SM0KBD