[mythtv-users] today's mythtv update for v31 failed

Stephen Worthington stephen_agent at jsw.gen.nz
Fri Feb 4 16:32:54 UTC 2022

On Fri, 4 Feb 2022 09:39:05 -0600, you wrote:

>On 2/4/22 05:38, Jim Abernathy wrote:
>> On 2/3/22 23:56, Stephen Worthington wrote:
>>> On Thu, 3 Feb 2022 14:16:41 -0500, you wrote:
>>>> On Thu, Feb 3, 2022 at 1:21 PM Mike Perkins <mikep at randomtraveller.org.uk>
>>>> wrote:
>>>>> That wasn't what I meant. I wondered if your *version* of python had
>>>>> changed recently, as the result
>>>>> of an update.
>>>>> However, if you can run it by hand then that would likely be a no.
>>>>> -- 
>>>>> Mike Perkins
>>>> The system in Ubuntu 21.10 and python3 is all there is. I'm pretty sure
>>>> there was a permissions issue on the hdhr_discovery.log file. Either  that
>>>> or somebody is running around and changing the ownership of files in
>>>> /var/log/mythtv during an update.
>>>> Jim A
>>> Manually running the HDHR Python program will change the ownership of
>>> the log file to whoever it was run from.  A permanent fix for this
>>> would be to touch the log file from the mythtv-backend service before
>>> running the Python program.  So try adding something like these lines
>>> to your override.conf file before the one that runs the Python
>>> program:
>>> ExecStartPre=-/bin/rm /var/log/mythtv/hdhr_discovery.log
>>> ExecStartPre=-/usr/bin/touch /var/log/mythtv/hdhr_discovery.log
>>> ExecStartPre=-/bin/chown mythtv:mythtv
>>> /var/log/mythtv/hdhr_discovery.log
>>> ExecStartPre=-/bin/chmod a=rw /var/log/mythtv/hdhr_discovery.log
>>> Note: These 4 ExecStartPre lines are each all one line - my email
>>> client wraps long lines.
>> The hdhr_discovery.log file ownership is not being changed by the hdhomerun_check.py I set the ownership to mythtv:mythtv yesterday and
>> mythtv-backend.service has been run several times since then. I think the reason is that the python3 program only appends to an existing file.
>It's how logging is initiated, the lines here (filemode=a(ppend)):
>    logging.basicConfig(filename='/var/log/mythtv/hdhr_discovery.log',
>                        filemode='a',
>                        format='%(asctime)s %(levelname)s\t%(message)s',
>                        datefmt='%Y-%m-%d %H:%M:%S',
>                        level=logging.INFO)
>If something else (rsyslog) is changing the user:group, then you could change the filename=
>to /tmp/hdhr_discovery.log, for example. I suspect it's the configuration in rsyslog that
>changes from mythtv:mythtv. See: grep "^\$File" /etc/rsyslog.conf . I wouldn't change that!
>Not sure why I don't see the issue. But, I build from source, so no MythTV updates.

Syslog is not involved as the Python code is not set up to use syslog.
So the /etc/rsyslog.conf and /etc/rsyslog.d/*.conf files have no
effect on the hdhr_discovery.log file.  It is just a normal
ownership/permissions problem that happens all the time to programs
that create their own log files under /var/log.  It is very common to
have programs unable to create their /var/log/ log file, and usually
the easiest way to fix this is to just manually create the log file
with the right ownership and permissions and let the program open an
existing log file.  Sometimes even that does not work, depending on
the exact ownership and permissions on the files and the directories
in the path to the files.  And on how the program is set up to create
its log file.

It also does not help when the program gets run manually from a user
and then later gets run automatically from systemd using a different
user.  In this case, manually running hdhomerun_check.py from your
normal user prompt will create an hdhr_discovery.log file owned by
that user.  So in my case, my normal user is "stephen", so manually
running hdhomerun_check.py from user "stephen" will create a log file
with owner and group both set to "stephen".  Things run from the
mythtv-backend.service file (and any override files) are run from user
"mythtv". That is because of this line in


Since the group is not specifically set in mythtv-backend.service, I
think it will pick up the default group of user "mythtv", which is
group "mythtv".  But I am not sure about that.

You might hope that because user "stephen" is set up as a member of
group "mythtv" that a program running as "mythtv" would be able to
write to a file with stephen:stephen ownership, but that is not the
case.  If the file has a=w permission (any user can write to it), then
user "mythtv" should be able to write to it, but not otherwise.  And
create permissions are even more complicated, requiring directory
level permission in order to be able to create a new file under that

More information about the mythtv-users mailing list