Command in rc.local not executed?

[gc-user]

I have, beside other commands, the following commands in rc.local

rfkill block bluetooth
rfkill block wlan

I just noticed that those commands apparently aren't executed as both wlan and bluetooth are enabled. If I run those commands manually or via a script at login through the DE's session management both are disabled - as expected.

What might be wrong that those commands don't work when put in /etc/rc.local ? The file is marked executable.

Edit:

I just booted a few snapshots. It seems like sometime between end of 2024 and mid March 2025 this stopped working.

[Duncaen]

/etc/runit/2:[ -x /etc/rc.local ] && /etc/rc.local

The only it could possible happen to not run is if it isn't executable and that hasn't changed in 11 years.

[gc-user]

Thanks for your reply.

I downgraded runit and runit-void to the respective versions from December 2024, but that didn't help. The runit process even hung for a few seconds at boot, I think it was "stage 2". So, there must be another factor.

I ran

sudo /etc/runit/2 && /etc/rc.local

and

sudo /etc/rc.local

Both commands work and execute the commands in rc.local.
So, apparently rc.local isn't executed / run at boot anymore, I guess, for whatever reason.

[gc-user]

Some more findings:

It might have something to do with the kernel.

I just installed v6.6(.90). With that, rc.local gets executed. With v6.12(.25) it doesn't.

But as zfs has also changed since December 2024, that might also be in the mix as it has to be adjusted for new kernel versions.

[Duncaen]

There is no way this has anything to do with the kernel.

$ ls -l /etc/rc.local 
-rwxr-xr-x 1 root root 685 Apr 22 18:17 /etc/rc.local
# chmod +x /etc/rc.local

[classabbyamp]

if anything, this is probably just the devices not being ready to be blocked at the point rc.local is executed

[gc-user]

Thanks for your input, that makes sense.
Is there a way to delay this step in order to test this hypothesis?

[gc-user]

This issue seems to have been fixed by one of the recent updates.

I don't know which one, but my guess is either the downgrade of linux-firmware or one of the packages that was rebuilt to "fix pc: provides", like e.g. zfs. The former can only be the reason if changing that package has effect without reboot / relogin because I checked for the rfkill stuff (by chance immediately) after that package was downgraded..

[Duncaen]

Those updates are 100% unrelated.