Unknown lvalue in irqbalance

Hey everyone!

Anyone else noticed the following error, Alma 8.7?

systemd[1]: /usr/lib/systemd/system/irqbalance.service:6: Unknown lvalue 'ConditionCPUs' in section 'Unit'

Thank you.

Now I’m looking for it, yes. It’s been there since at least November 21. I’m running a basic bare-metal desktop, updated as of yesterday, and it was reported both after the post-upgrade reboot and this morning.

Looking at /usr/lib/systemd/system/irqbalance.service line 6 is:

ConditionCPUs=>1

so as a first guess I’d assume that a parameter has been deprecated - mind, it is systemd so it’s anybody’s guess what is going on. :frowning_face:

Looking at man systemd.unit(5) there are a whole number of ConditionXYZ entries that can be put into the [UNIT] section of the service file. Unfortunately ConditionCPUs isn’t one of them. I think that irqbalance is simply trying to test that there are more than 1 CPUs present before running. Still investigating.

OK, problem found. irqbalance-1.9.0-3.el8.x86_64.rpm contains irqbalance.service that has the suspect line 6 in it. This needs to go back to either the packagers, or more likely RHEL.

Martin,
I have this same issue with irqbalance-1.9.0-3.el8.x86_64.rpm. As there hasn’t been an update to this package, I merely commented out line #6 to get rid of log message

My irqbalance.service file:

[Unit]
Description=irqbalance daemon
Documentation=man:irqbalance(1)
Documentation=GitHub - Irqbalance/irqbalance: The irqbalance source tree - The new official site for irqbalance
ConditionVirtualization=!container
#ConditionCPUs=>1

[Service]
EnvironmentFile=-/usr/lib/irqbalance/defaults.env
EnvironmentFile=-/etc/sysconfig/irqbalance
ExecStart=/usr/sbin/irqbalance --foreground $IRQBALANCE_ARGS
ReadOnlyPaths=/
ReadWritePaths=/proc/irq
RestrictAddressFamilies=AF_UNIX
RuntimeDirectory=irqbalance/

[Install]
WantedBy=multi-user.target

Then after editing the file:
‘systemctl daemon-reload’
‘systemctl restart irqbalance’

Thanks for getting back on this. I’m afraid I adopted the ostrich method - if the error message is not actually causing a problem and the cause is systemd I leave well alone, it was so much easier with init before that idiot Potty mucked it up. :slightly_frowning_face:

I’m the opposite, admittedly a bit anal I guess… Once I set up basic server/service, I run ‘sudo journalctl -p 3 -xb’ and chase down as many issues as possible.

Maybe I should abopt your philosphy a bit more…

Well I’ve just looked. In 11:37 uptime there is 506 error messages, most from pulseaudio and I’ve not been using sound today (yet). Life’s too short. I tend to rely on logwatch and the logfiles, though /var/log/messages is crudded up beyond belief by systemd. One of these days I’ll attack /etc/rsyslog.conf and try to get some sanity back - when I get the proverbial “round tuit”!

As similar FB 2115230 for RHEL8 shows, it is caused by configuration file for newer version of systemd (242 or newer) clashing with the system one (239).

RHEL FB: 2115230 – irqbalance.service: Unknown lvalue 'ConditionCPUs' in section 'Unit'

Systemd news announcing “ConditionCPUs” as feature in 242: systemd/NEWS at main · systemd/systemd · GitHub