[mythtv-users] sql connection question

[Stephen Worthington]

On Thu, 23 Jan 2020 18:53:05 +0000, you wrote:

>
> ---- On Mon, 13 Jan 2020 03:36:27 +0000 Stephen Worthington <stephen_agent at jsw.gen.nz> wrote ----
> > On Sun, 12 Jan 2020 14:37:48 +0000, you wrote:
> > 
> > > ---- On Sun, 12 Jan 2020 12:14:21 +0000 Stephen Worthington <stephen_agent at jsw.gen.nz> wrote ----
> > > > On Sun, 12 Jan 2020 10:51:09 +0000, you wrote:
> > > > 
> > > > >with recent mariadb upgrades i've been seeing this appear in the logs reasonably often. i think it's just a change of default logging level with the more recent versions.
> > > > >While i do have my Primary FE dropping frames for 20-30secs periodically i cant see how that is a sql issue. mythtv appears to work correctly other than that and uses the typical mythconverg & mythtv user.
> > > > >
> > > > >while it's clear the connection closed normally from the sql side, what in mythtv could cause it to attempt connection as unconnected/unauthenticated? Have I not configured something correctly?
> > > > >The IP is my laptop running mythBE&FE, rolled a new sql server for testing (seeing the same entries on my main mariadb server) so 100% sure it's mythtv causing this.
> > > > >
> > > > >2020-01-12 10:28:25 433 [Warning] Aborted connection 433 to db: 'unconnected' user: 'unauthenticated' host: '192.168.1.63' (This connection closed normally without authentication)
> > > > 
> > > > How often is this happening?  If it is happening reasonably often or
> > > > you can provoke it to happen, you could run Wireshark and capture the
> > > > SQL port traffic and see exactly what is happening.
> > >
> > >roughly 3 times in a 1hour period. although have seen it higher. maybe 10-15times/hour.
> > >I didn think about packet capturing - i'll probably go server side capture with tcpdump rather than wireshark. be able to run it in a screen session and come back to later in the day when it's got a decent set of results.
> > 
> > Personally, I prefer to use tshark instead of tcpdump.  With the right
> > options (-P and -w) you can output to a file at the same time as still
> > getting the packets displayed in real time.
>
>
>in the interest of not leaving things hanging, i'm onto something.
>i vaguely remember posing a number of months ago reguarding mysql 5.x to later version. turned out i was running v5 for no specific reason so i upgraded to latest current keeping my.cnf.
>
>I reinstalled my server (attempted centos8 upgrade, but had to roll back to centos7) which meant a new my.cnf file with all the current settings.
>with the new my.cnf file, There was a change of log_warning level which added visibility of these connection errors (why didn't ddg/google find this, i dont know) https://mariadb.com/kb/en/error-log/#configuring-the-error-log-verbosity. from 1 to 2, but my docker image seems to be running at level 3.
>while i'm waiting for a log entry to occur once the new timeout is met, changing wait_timeout from 600 to 12000 has stopped the log entries so i'm at least down the right path with the cause.

Is there any particular reason you are still using MySQL instead of
MariaDB?  MySQL updates recently seem to have been breaking things,
where MariaDB seems to be better at maintaining compatibility.  I
changed to MariaDB some time ago when MySQL stopped using the readline
library and broke my command line history matching in all its command
line programs.  I have not regretted the change at all.