search

MythTV / mythtv

The official MythTV repository
https://www.mythtv.org
GNU General Public License v2.0
708 stars 346 forks source link

Silent appending of logging options causes mythtv-backend to fail with external recorders #571

Open dlasher opened 2 years ago

dlasher commented 2 years ago

Platform

root@backend1:~# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04.4 LTS Release: 20.04 Codename: focal

root@backend1:~# uname -a Linux backend1 5.11.22-5-pve #1 SMP PVE 5.11.22-10 (Tue, 28 Sep 2021 08:15:41 +0200) x86_64 x86_64 x86_64 GNU/Linux

MythTV Version : v31.0+fixes.202203040618.7e4ce1ba98~ubuntu20.04.1 MythTV Branch : fixes/31 Network Protocol : 91 Library API : 31.20200101-1

Component:

mythtv-backend

What steps will reproduce the bug?

Enable an external "blackbox" recorder, like mythhdhrrecorder, and set a syslog level in the CLI Invocation ** Example : /usr/local/bin/mythhdhrrecorder --hdhr 10.4.11.204 --devicename cc204a --verbose general --syslog daemon

Now when you start the backend with "--syslog local7", it will fail to initialize the tuner, like so:

May 25 10:31:14 backend3 mythbackend: mythbackend[6742]: W CoreContext recorders/ExternalStreamHandler.cpp:1323 (ProcessVer1) ExternSH[71](/usr/local/bin/mythhdhrrecorder --hdhr 10.4.11.204 --devicename cc204aa --verbose all --syslog daemon --queuesize 256): External Recorder invalid response to 'APIVersion?': 'Traceback (most recent call last):'

Only if you debug all do you see the actual error message:

2022-05-25 10:53:07.925035 I ExternSH[73](/usr/local/bin/mythhdhrrecorder --hdhr 10.4.11.204 --devicename cc204cc --verbose most --syslog daemon --queuesize 256): MythTV.exceptions.MythError: Error: These logging options are mutually exclusive: 'logfile', 'logpath', 'syslog' or 'systemd-journal'!

If you remove "--syslog daemon" from the CLI command, the backend starts fine.

Looking at what is passed to the "blackbox" recoder, it appears we're appending several fields to the end of the invocation, ("--verbose general --loglevel info --quiet --syslog local7 --inputid 76") which is what caused the failure.

May 25 11:05:09 backend4 mythhdhrrecorder[3714]: Recorder starting, args: --hdhr 10.4.11.206 --devicename cc206c --verbose most --queuesize 256 --verbose general --loglevel info --quiet --syslog local7 --inputid 76

What is the expected behaviour?

mythtv-backend starts without failure, or dumps a meaningful log message

I see a couple of fixes/options

  1. include an option to NOT add anything to the end of the CLI invocation
  2. parse the CLI invocation for commands we know we're going to append, and either remove them, or prevent them from being entered?
  3. something else smarter?

What do you see instead?

mythtv-backend repeatedly failing to start

garybuhrmaster commented 2 years ago

I see a couple of fixes/options

  1. include an option to NOT add anything to the end of the CLI invocation
  2. parse the CLI invocation for commands we know we're going to append, and either remove them, or prevent them from being entered?
  3. something else smarter?
  1. Change MythTV command line processing to use the last specification rather than reject conflicting ones (especially for logging)?
    • I am not really sure that is a good idea (fail early is the historic MythTV way).
    • I have no idea how hard or easy that would be to accomplish.

Personally, IRT logging, I have just moved all my MythTV (pretty much all apps) usage to systemd-journald (which, of course, is the way Mr. Poettering probably wishes you to go). A combined journal, with display selection capability, tends to work better for my workflows.

dlasher commented 2 years ago

FWIW, something changed between v29 and v31, because I have logs from a different issue I posted that look like this:

Feb 24 13:00:00 backend1 mythhdhrrecorder[920006]: Recorder starting, args: --hdhr 10.4.11.206 --devicename Comcast2c -v general --syslog daemon --verbose general --loglevel info --quiet --syslog local7

This was when the backend was still running 29.1+fixes.201909121531.4c432df~ubuntu18.04.1 - and that used to.. not fail?

garybuhrmaster commented 2 years ago

FWIW, something changed between v29 and v31, because I have logs from a different issue I posted that look like this:

That particular 3rd party recorder was written in python3, and while it did a try: on importing the official MythTV python logging functions, the import would fail in pre-v31 because the project did not (at that time) support/ship python3 libraries, and that 3rd party recorder would then fall back to its internal minimal logging implementation (intended to be mostly compatible, but not identical), that was likely more permissive in its interpretation of the options. With v31, the MythTV project itself shipped python3 libraries, and the import will now typically succeed (as long as you have installed the MythTV python libs), and you are getting the official, formal, supported, logging functionality (including any/all of its checks and balances).

rcrdnalor commented 2 years ago

Yes, the checks for selecting the logging path and mechanism are now more restrictive within the MythTV Python Bindings: Providing multiple logging paths result now in an error. AFAIK, this was requested by a user who complained not seeing the logs he had defined.

linuxdude42 commented 1 year ago

Is this still a problem?