<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 4, 2022 at 11:33 AM Stephen Worthington <<a href="mailto:stephen_agent@jsw.gen.nz">stephen_agent@jsw.gen.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 4 Feb 2022 09:39:05 -0600, you wrote:<br>
<br>
>On 2/4/22 05:38, Jim Abernathy wrote:<br>
>> <br>
>> On 2/3/22 23:56, Stephen Worthington wrote:<br>
>>> On Thu, 3 Feb 2022 14:16:41 -0500, you wrote:<br>
>>><br>
>>>> On Thu, Feb 3, 2022 at 1:21 PM Mike Perkins <<a href="mailto:mikep@randomtraveller.org.uk" target="_blank">mikep@randomtraveller.org.uk</a>><br>
>>>> wrote:<br>
>>>><br>
>>>>> That wasn't what I meant. I wondered if your *version* of python had<br>
>>>>> changed recently, as the result<br>
>>>>> of an update.<br>
>>>>><br>
>>>>> However, if you can run it by hand then that would likely be a no.<br>
>>>>><br>
>>>>> -- <br>
>>>>><br>
>>>>> Mike Perkins<br>
>>>>><br>
>>>> The system in Ubuntu 21.10 and python3 is all there is. I'm pretty sure<br>
>>>> there was a permissions issue on the hdhr_discovery.log file. Either  that<br>
>>>> or somebody is running around and changing the ownership of files in<br>
>>>> /var/log/mythtv during an update.<br>
>>>><br>
>>>> Jim A<br>
>>> Manually running the HDHR Python program will change the ownership of<br>
>>> the log file to whoever it was run from.  A permanent fix for this<br>
>>> would be to touch the log file from the mythtv-backend service before<br>
>>> running the Python program.  So try adding something like these lines<br>
>>> to your override.conf file before the one that runs the Python<br>
>>> program:<br>
>>><br>
>>> ExecStartPre=-/bin/rm /var/log/mythtv/hdhr_discovery.log<br>
>>> ExecStartPre=-/usr/bin/touch /var/log/mythtv/hdhr_discovery.log<br>
>>> ExecStartPre=-/bin/chown mythtv:mythtv<br>
>>> /var/log/mythtv/hdhr_discovery.log<br>
>>> ExecStartPre=-/bin/chmod a=rw /var/log/mythtv/hdhr_discovery.log<br>
>>><br>
>>> Note: These 4 ExecStartPre lines are each all one line - my email<br>
>>> client wraps long lines.<br>
>> <br>
>> <br>
>> The hdhr_discovery.log file ownership is not being changed by the hdhomerun_check.py I set the ownership to mythtv:mythtv yesterday and<br>
>> 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.<br>
><br>
>It's how logging is initiated, the lines here (filemode=a(ppend)):<br>
><br>
>    logging.basicConfig(filename='/var/log/mythtv/hdhr_discovery.log',<br>
>                        filemode='a',<br>
>                        format='%(asctime)s %(levelname)s\t%(message)s',<br>
>                        datefmt='%Y-%m-%d %H:%M:%S',<br>
>                        level=logging.INFO)<br>
><br>
>If something else (rsyslog) is changing the user:group, then you could change the filename=<br>
>to /tmp/hdhr_discovery.log, for example. I suspect it's the configuration in rsyslog that<br>
>changes from mythtv:mythtv. See: grep "^\$File" /etc/rsyslog.conf . I wouldn't change that!<br>
><br>
>Not sure why I don't see the issue. But, I build from source, so no MythTV updates.<br>
<br>
Syslog is not involved as the Python code is not set up to use syslog.<br>
So the /etc/rsyslog.conf and /etc/rsyslog.d/*.conf files have no<br>
effect on the hdhr_discovery.log file.  It is just a normal<br>
ownership/permissions problem that happens all the time to programs<br>
that create their own log files under /var/log.  It is very common to<br>
have programs unable to create their /var/log/ log file, and usually<br>
the easiest way to fix this is to just manually create the log file<br>
with the right ownership and permissions and let the program open an<br>
existing log file.  Sometimes even that does not work, depending on<br>
the exact ownership and permissions on the files and the directories<br>
in the path to the files.  And on how the program is set up to create<br>
its log file.<br>
<br>
It also does not help when the program gets run manually from a user<br>
and then later gets run automatically from systemd using a different<br>
user.  In this case, manually running hdhomerun_check.py from your<br>
normal user prompt will create an hdhr_discovery.log file owned by<br>
that user.  So in my case, my normal user is "stephen", so manually<br>
running hdhomerun_check.py from user "stephen" will create a log file<br>
with owner and group both set to "stephen".  Things run from the<br>
mythtv-backend.service file (and any override files) are run from user<br>
"mythtv". That is because of this line in<br>
/lib/systemd/system/mythtv-backend.service:<br>
<br>
User=mythtv<br>
<br>
Since the group is not specifically set in mythtv-backend.service, I<br>
think it will pick up the default group of user "mythtv", which is<br>
group "mythtv".  But I am not sure about that.<br>
<br>
You might hope that because user "stephen" is set up as a member of<br>
group "mythtv" that a program running as "mythtv" would be able to<br>
write to a file with stephen:stephen ownership, but that is not the<br>
case.  If the file has a=w permission (any user can write to it), then<br>
user "mythtv" should be able to write to it, but not otherwise.  And<br>
create permissions are even more complicated, requiring directory<br>
level permission in order to be able to create a new file under that<br>
directory.<br></blockquote><div><br></div><div>At present, I have the permissions on the /var/log/mythtv/hdhr_discovery.log set to 'mythtv', and only the override.conf file causes the running of hdhomerun_check.py.</div><div><br></div><div>So I'm hoping the permissions keep working as they do now.  If I get another ubuntu mythtv update and the permissions change on all log files then I know where the problem is and I'll move the logging for hdhomerun_check.py to /tmp or somewhere. Once this function is set up, it is going to work unless the HDHR tuner is powered off or failing. That's the only time I'd every look at that log file.</div><div><br></div><div>JIm A</div><div><br></div></div></div>