[mythtv-users] backend still running old user job command line after I changed it

Stephen Worthington stephen_agent at jsw.gen.nz
Mon May 14 15:36:05 UTC 2018


On Mon, 14 May 2018 10:29:19 -0400, you wrote:

>On Sun, May 13, 2018, 11:11 PM Stephen Worthington <stephen_agent at jsw.gen.nz>
>wrote:
>
>> On Sun, 13 May 2018 20:41:49 -0500, you wrote:
>>
>> >On 05/13/2018 07:39 PM, Ian Evans wrote:
>> >> Was having a problem with mythvidexport.py not exporting one recording.
>> >>
>> >> I decided to increase the logging and changed my user job command line
>> from:
>> >>
>> >> /usr/share/mythtv/mythvidexport.py --delete %VERBOSEMODE% %JOBID%
>> >>
>> >> to:
>> >>
>> >> /usr/share/mythtv/mythvidexport.py --delete --syslog local7 --loglevel
>> >> debug
>> >> --verbose all %JOBID%
>> >>
>> >> I restarted the backend and restarted the frontend and ran the job
>> again.
>> >> However, the log showed it was running the old command line:
>> >>
>> >> May 13 20:31:54 buster mythbackend: mythbackend[1385]: E UserJob_56023
>> >> jobqueue.cpp:2445 (DoUserJobThread) JobQueue: User Job
>> >> '/usr/share/mythtv/mythvidexport.py --delete  --verbose general
>> --loglevel
>> >> info --quiet --syslog local7 56023' failed.
>> >>
>> >>
>> >> Running setup again, I could see the command line was the new one I had
>> put
>> >> in. So why would the logs show it running the old one?
>> >
>> >Without seeing the actual commands and output, I can only guess that the
>> initial
>> >restart of the backend didn't take.
>> >
>> >The settings are cached, so you can really get by with just doing a:
>> >mythutil --clearcache [-q -q] rather that restarting the BE.
>> >
>> >Or, your original command line is fine. Just do: mythbackend --setverbose
>> all.
>> >Then when the backend starts your UserJob, the options will be passed. I'd
>> >suggest adding ,norefcount to cut down on the noise from all.
>>
>> How are you starting and stopping mythbackend?  On a systemd system,
>> the old ways of doing that no longer work properly.  The correct
>> commands for a systemd system are:
>>
>> systemctl start mythtv-backend
>> systemclt stop mythtv-backend
>>
>> and restarting is:
>>
>> systemctl restart mythtv-backend
>>
>> To see what mythbackend's status is:
>>
>> systemctl status mythtv-backend
>>
>> I'm not running the command line to start and stop it. Running
>> mythtv-setup it asks to stop it and then asks if it can restart it.

Yes, but how does mythtv-setup stop and start mythbackend?  If you are
running Ubuntu, then mythtv-setup is a script, wrapped around
mythtv-setup.real.  That script uses the outdated and non-functional
commands, rather than the systemctl commands.  On some systems, the
old "service start" and "service stop" commands in the script do still
work, but they are unreliable.  They may work one time, and not the
next.  So you may assume that mythbackend will be running again, when
that has not happened.

If you are using mythtv-setup.real directly or a system that does not
use a wrapper script, then the commands being used will be the ones in
the database ("killall mythbackend" and "mythbackend"), which are
wrong in a different way - they do not run mythbackend as a daemon
properly.  The only safe way to stop and start mythbackend on a
systemd based system is via systemctl.  So until it is all fixed up,
you need to manually stop and start mythbackend from the command line
and not try to have the myth* programs stop and start it themselves.
They simply do not do it properly at the moment.

This could become a big problem when the time comes to upgrade to v30
- if mythbackend does not get shut down and the upgrade is attempted
with it still running.

I think the packages may need to be altered to include helper scripts
to start and stop mythbackend.  Then helper scripts would be added to
sudoers so they could run the systemctl commands without further
authorisation, and could be called whenever needed by the programs and
other scripts.  Directly replacing the existing commands with the
systemctl ones would cause things to wait for pop-up authorisation to
happen, preventing things from happening automatically.  Allowing
mythtv group users to directly use systemctl without authorisation
would be a big security hole.  Using helper scripts that can only be
modified by root access is a middle ground that allows systemctl to be
used for stopping and starting mythbackend only.


More information about the mythtv-users mailing list