tuned expects the config file in /etc/tuned

[Pointedstick]

Per https://www.man7.org/linux//man-pages/man7/file-hierarchy.7.html, /usr/share/factory/ is the expected location for vendor-supplied configuration data to live, while /etc is for local overrides. It specifically says:

System-specific configuration. This directory may or may not be read-only. Frequently, this directory is pre-populated with vendor-supplied configuration files, but applications should not make assumptions about this directory being fully populated or populated at all, and should fall back to defaults if configuration is missing.

(my emphasis)

Tuned does not adhere to this guideline, and requires its config data to live in /etc. This causes problems on operating systems where /usr/share/factory/ is deliberately used as the default location for vendor config data:

$ tuned-gui
Traceback (most recent call last):
  File "/usr/lib/python3.13/site-packages/tuned/utils/global_config.py", line 45, in load_config
    with open(file_name) as f:
         ~~~~^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: '/etc/tuned/tuned-main.conf'

The systemd service fails too.

[yarda]

Hmm, never ever heard about this directory. More software will probably have problem with it. Also it seems the factory directory isn't mentioned in the FHS 3.0 standard. It shouldn't be hard to add support for it, but I would rather have it mentioned in some standard (e.g. FHS).

[Pointedstick]

/usr/share/factory is a fairly new innovation made by Systemd, yeah.

[ryanabx]

For reference, it's in the systemd file hierarchy standard, which I believe was meant to be the progression of the original standard. https://www.freedesktop.org/software/systemd/man/latest/file-hierarchy.html#/usr/share/factory/etc/

EDIT: Looks like the link I shared is just a different source of the one Nate shared. My bad!

I could have sworn the default vendor configuration directory was something other than /usr/share/factory/etc, but alas, I learned something today.

Also see: https://github.com/uapi-group/specifications/issues/76

It looks like /usr/lib/tuned and /usr/lib/tuned.d might actually be better places for this data, based on what other people are doing with their vendor configurations.

I think /usr/share/factory/etc might be in compatibility cases where you overlay mount it onto /etc for applications that don't support hermetic usr

[JustSoup312]

I just wanted to pop in and clarify some stuff. /usr/share/factory/ shouldn't be read from by programs, that's where distributors put files (e.g. configs) that cannot be read from under /usr/. The correct place to put configs to respect the UAPI Config Spec is either /usr/share/<progname>/ or /usr/lib/<progname>/. Personally, the way to handle this is using libeconf, but you can also just define the distributor config directory as $datadir/<progname> and having a conf.d directory under that for overrides.

tl;dr configs should be read and overlayed in the order of

1. /etc/tuned/conf.d/<configs>
2. /etc/tuned/<configs>
3. /usr/share/tuned/conf.d/<configs>
4. /usr/share/tuned/<configs>

if adding config overlay reading is too much at first, just adding reading from /usr/share/tuned/<configs> after the configs in etc should be enough.

[ryanabx]

Yep, we just hashed this out in the kde linux chat. I'm going to make a PR to systemd's FHS docs to clarify this a bit.