Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot change IRQ %d affinity: Read-only file system #308

Closed
blu3bird opened this issue Apr 1, 2024 · 2 comments
Closed

Cannot change IRQ %d affinity: Read-only file system #308

blu3bird opened this issue Apr 1, 2024 · 2 comments

Comments

@blu3bird
Copy link

blu3bird commented Apr 1, 2024

After updating to 1.9.4 irqbalance stopped working.

Upon starting it I see a lot of errors like these:

Apr 01 10:45:24 Anteaus systemd[1]: Started irqbalance daemon.
Apr 01 10:45:34 Anteaus irqbalance[14264]: Cannot change IRQ 70 affinity: Read-only file system
Apr 01 10:45:34 Anteaus irqbalance[14264]: IRQ 70 affinity is now unmanaged
Apr 01 10:45:34 Anteaus irqbalance[14264]: Cannot change IRQ 83 affinity: Read-only file system
Apr 01 10:45:34 Anteaus irqbalance[14264]: IRQ 83 affinity is now unmanaged
Apr 01 10:45:34 Anteaus irqbalance[14264]: Cannot change IRQ 73 affinity: Read-only file system
Apr 01 10:45:34 Anteaus irqbalance[14264]: IRQ 73 affinity is now unmanaged
Apr 01 10:45:34 Anteaus irqbalance[14264]: Cannot change IRQ 91 affinity: Read-only file system
Apr 01 10:45:34 Anteaus irqbalance[14264]: IRQ 91 affinity is now unmanaged
Apr 01 10:45:34 Anteaus irqbalance[14264]: Cannot change IRQ 81 affinity: Read-only file system
Apr 01 10:45:34 Anteaus irqbalance[14264]: IRQ 81 affinity is now unmanaged
Apr 01 10:45:34 Anteaus irqbalance[14264]: Cannot change IRQ 71 affinity: Read-only file system
...

The error repeats for all manageable IRQs in my system. All of the IRQs it's complaining about can be manage from a root shell via the proc filesystem, eg. echo 5-7 > /proc/irq/70/smp_affinity_list.

This issue did not occur with 1.9.3.

I noticed that 1.9.4 sets ProtectKernelTunables=yes in it's systemd unit. After removing that restriction via override.conf

# /etc/systemd/system/irqbalance.service.d/override.conf
[Service]
ProtectKernelTunables=no

irqbalance does not output these errors any more. Checking /proc/irq/*/smp_affinity_list confirms that IRQs are managed as intended.

I am using systemd 255.4. Kernel version is 6.8.2.

I believe ProtectKernelTunables=yes should be removed from irqbalance's systemd unit file. The man page, systemd.exec(5), confirms that it is supposed to restrict access to /proc/irq:

   ProtectKernelTunables=
       Takes a boolean argument. If true, kernel variables accessible through /proc/sys/, /sys/, /proc/sysrq-trigger, /proc/latency_stats, /proc/acpi, /proc/timer_stats, /proc/fs
       and /proc/irq will be made read-only to all processes of the unit. Usually, tunable kernel variables should be initialized only at boot-time, for example with the
       sysctl.d(5) mechanism. Few services need to write to these at runtime; it is hence recommended to turn this on for most services. For this setting the same restrictions
       regarding mount propagation and privileges apply as for ReadOnlyPaths= and related calls, see above. Defaults to off. Note that this option does not prevent indirect changes
       to kernel tunables effected by IPC calls to other processes. However, InaccessiblePaths= may be used to make relevant IPC file system objects inaccessible. If
       ProtectKernelTunables= is set, MountAPIVFS=yes is implied.

       This option is only available for system services, or for services running in per-user instances of the service manager in which case PrivateUsers= is implicitly enabled
       (requires unprivileged user namespaces support to be enabled in the kernel via the "kernel.unprivileged_userns_clone=" sysctl).

       Added in version 232.
@nhorman
Copy link
Member

nhorman commented Apr 1, 2024

yeah, that should be removed, will fix

@nhorman
Copy link
Member

nhorman commented Apr 1, 2024

fixed in f2c8309

@nhorman nhorman closed this as completed Apr 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants