Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
'systemd' recently - perhaps after last updates - started constantly spitting:
...
daemon:info : [47856.092753] systemd-rc-local-generator[19204]: /etc/rc.d/rc.local is not marked executable, skipping.
daemon:info : [47856.251846] systemd-rc-local-generator[19229]: /etc/rc.d/rc.local is not marked executable, skipping.
daemon:info : [47917.794579] systemd-rc-local-generator[46433]: /etc/rc.d/rc.local is not marked executable, skipping.
daemon:info : [47917.970020] systemd-rc-local-generator[46459]: /etc/rc.d/rc.local is not marked executable, skipping....
Version-Release number of selected component (if applicable):
systemd-250-4.el9.x86_64
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
After boot, generators are run only on systemd reload or reexec. That means that something on your system is issuing "systemctl daemon-reload", "systemctl daemon-reexec", or their D-Bus equivalents. E.g., reload is called by rpm macros during update if any service has been updated. In any case, this is not a bug (and the same message has been issued by systemd-rc-local-generator under the same conditions for years).
Btw, there was a span of time when no default /etc/rc.local was being installed; in that case systemd-rc-local-generator would only log at debug priority, so there wouldn't be any message in the journal with the default settings. But this was changed with bug 1978707, which is pre-beta, so I wouldn't call that a recent change...
That said, it makes sense to me to demote the message's priority to debug on RHEL, as it's us who create the non-executable /etc/rc.local.
I've thought about this a bit more and I think we have the following options to get rid of the message:
1. Don't install default rc.local.
But we want to inform users that rc.local is considered legacy and that they should move away from it. A comment in a default rc.local is the simplest and most focused way to do this.
2. Make the default rc.local executable.
But we don't want it to be run unless an admin actually uses it.
3. Demote the message priority to debug (as I suggested in comment 1).
But the message is a useful diagnostic for admins who add something to rc.local without reading the comment (perhaps using some automation) and then want to know why it's not being run.
Neither of those options is good. Before 9.0 beta, I'd be inclined towards 1. At this point, though, IMHO the best thing is to do nothing. (An additional consideration is that the message is only at priority info; there are many more like that in the log.) I'm closing this hence.