On Sat, Jan 5, 2019 at 5:56 AM James Abernathy <jfabernathy@gmail.com>
wrote:
> In research other errors on the system I came across a lot of these errors.
>
> mythpreviewgen[22470]: E CoreContext main.cpp:81 (preview_helper)
> Setting priority failed. eno: Permission denied (13)
>
> Any idea if it's something that needs fixing?
>
> Jim A
>
>
This error message appears to be coming from mythpreviewgen/main.cpp line
81 (assuming you were using a mythtv build based on fixes/29 branch at the
time of your original post (Jan 5 2019). Here is the spot in the code
where this message originated from:
https://github.com/MythTV/mythtv/blob/fixes/29/mythtv/programs/mythpreviewgen/main.cpp#L79-L81 I was seeing this same message too, but from a different line number using
mythtv Ubuntu package versions based on fixes/31 branch (
2:31.0+fixes.202203040618.7e4ce1ba98~ubuntu20.04.1):
mythpreviewgen[2034369]: mythpreviewgen[2034369]: E CoreContext
main.cpp:77 (preview_helper) Setting priority failed.
eno: Permission denied (13)
The message comes from the same place in the code but it just moved line
numbers in the fixes/31 branch:
https://github.com/MythTV/mythtv/blob/fixes/31/mythtv/programs/mythpreviewgen/main.cpp#L75-L77 It turns out that this error message has to do with mythpreviewgen trying
to set its process priority (a.k.a. "nice level") and failing due to lack
of permissions. The comment in the code provides the reasoning behind why
it's doing this:
// Lower scheduling priority, to avoid problems with recordings.
This is not a fatal error, so the process continues onward regardless of
nice / process priority level. It appears safe to ignore, but depending on
your backend hardware's CPU speed and general load it may have performance
impacts on other processes deemed to have higher preferred priority such as
recordings. If you're seeing performance impacts, or just want to silence
this annoying error in the logs the solution is to grant the mythtv user or
the process the permission to set a nice level.
The Linux kernel capability which controls this is CAP_SYS_NICE.
The following references help to explain kernel capabilities and a few
different ways to grant them:
https://stackoverflow.com/q/7635515 https://linux.die.net/man/7/capabilities https://linux.die.net/man/8/setcap https://linux.die.net/man/3/cap_from_text https://linux.die.net/man/5/limits.conf https://linux.die.net/man/8/pam_limits For processes started by SystemD, look into the AmbientCapabilities
[Service] setting:
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#AmbientCapabilities= In this specific case, the process mythpreviewgen is started by mythbackend
usually as the mythtv user. Therefore, you have a few options to grant the
CAP_SYS_NICE capability. You can try to grant it to the mythpreviewgen
process itself via an extended file attribute called security.capability
(see the "File capabilities" section of man capabilities
<
https://www.mankier.com/7/capabilities#Description-File_capabilities>).
Alternatively you can try to give it to the mythbackend process and grant
it via inheritance to the launched mythpreviewgen sub-process (via either
file extended attribute security.capability or SystemD
AmbientCapabilities=CAP_SYS_NICE). Another option would be to give the
mythtv user this capability via pam_limits / limits.conf.
The option you choose will depend on your security stance and personal
preference. I'd suggest granting just the mythpreviewgen binary
CAP_SYS_NICE using file capabilities via the extended file attribute
security.capability. The reasoning for choosing this option is that
granting it to the mythtv user or mythbackend may give more broad
permissions to other processes that don't need this capability, while
granting it just to the mythpreviewgen process is a more granular approach
giving just this process that capability.
Ideally, this file capability extended attribute would be automatically
granted in the package manager's post-install hook (See the discussion of
this here <
https://stackoverflow.com/a/37528755>). However, it currently
appears not to be done in this way at least on Ubuntu/Mythbuntu. As such,
you'll probably have to re-run the setcap command each time mythtv packages
are upgraded on the system.
To set the file capability:
# Check the current extended attributes for /usr/bin/mythpreviewgen
# Default was that none were set
$ getcap /usr/bin/mythpreviewgen
$ getfattr -d -m - /usr/bin/mythpreviewgen
$ sudo setcap 'cap_sys_nice=eip' /usr/bin/mythpreviewgen
# Show the new extended attributes for /usr/bin/mythpreviewgen
# Now security.capability xattr is set to: "cap_sys_nice+eip"
$ getfattr -d -m - /usr/bin/mythpreviewgen
getfattr: Removing leading '/' from absolute path names
# file: usr/bin/mythpreviewgen
security.capability=0sAQAAAgAAgAAAAIAAAAAAAAAAAAA=
$ getcap /usr/bin/mythpreviewgen
/usr/bin/mythpreviewgen = cap_sys_nice+eip
That will allow mythpreviewgen to set nice level, and make those annoying
log messages go away. At least... until the mythtv-backend package is
updated on the system and overwrites /usr/bin/mythpreviewgen with the new
version.
This will be necessary to re-run each time after upgrading packages unless
this gets incorporated into both MythTV QMake post-build steps, and also
into Debian / RPM or other packaging post-install scripts.