[mythtv-users] sql connection question
Tim Draper
veehexx at zoho.com
Thu Jan 23 18:53:05 UTC 2020
---- 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.
More information about the mythtv-users
mailing list