Bug 1876905
| Summary: | rc.local is never executed despite existing and being executable | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Lukáš Czerner <lczerner> |
| Component: | systemd | Assignee: | systemd-maint |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 32 | CC: | ariaanbruinsma, fedora, filbranden, flepied, lnykryn, msekleta, ppywlkiqletw, ssahani, s, systemd-maint, yuwatana, zbyszek, z |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | systemd-245.8-2.fc32 systemd-243.9-1.fc31 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-09-23 17:12:50 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Do you have both /etc/rc.d/rc.local and /etc/rc.local? (In reply to Zbigniew Jędrzejewski-Szmek from comment #1) > Do you have both /etc/rc.d/rc.local and /etc/rc.local? I tried every combination, only /etc/rc.local, only /etc/rc.d/rc.local and both. None works. -Lukas (In reply to Lukáš Czerner from comment #2) > (In reply to Zbigniew Jędrzejewski-Szmek from comment #1) > > Do you have both /etc/rc.d/rc.local and /etc/rc.local? > > I tried every combination, only /etc/rc.local, only /etc/rc.d/rc.local and > both. None works. > > -Lukas On Fedora the file name is /etc/rc.d/rc.local and NOT /etc/rc.local. man systemd-rc-local-generator should be corrected for the actual name of rc.local. Also, the error messages says that /etc/rc.d/rc.local is not executable. (In reply to Villy Kruse from comment #3) > (In reply to Lukáš Czerner from comment #2) > > (In reply to Zbigniew Jędrzejewski-Szmek from comment #1) > > > Do you have both /etc/rc.d/rc.local and /etc/rc.local? > > > > I tried every combination, only /etc/rc.local, only /etc/rc.d/rc.local and > > both. None works. > > > > -Lukas > > On Fedora the file name is /etc/rc.d/rc.local and NOT /etc/rc.local. > > man systemd-rc-local-generator should be corrected for the actual name of > rc.local. > > Also, the error messages says that /etc/rc.d/rc.local is not executable. As I said in comment 2 I did try every combination, none of which works. However after disabling selinux it works fine. -Lukas (In reply to Lukáš Czerner from comment #4) > > As I said in comment 2 I did try every combination, none of which works. > However after disabling selinux it works fine. > > -Lukas rc.local works fine with SELinux, as long it is labeled correctly: $ ls -lZ /etc/rc.d/rc.local -rwxr-xr-x. 1 root root system_u:object_r:initrc_exec_t:s0 474 Feb 8 2015 /etc/rc.d/rc.local $ It has worked perfectly since 2015 with SELinux enabled. If you can, change the bug description to fix the manual page referring to /etc/rc.d/rc.local instead pf /etc/rc.local. Villy, thanks. See https://github.com/systemd/systemd/pull/17067. Lukáš: please verify that it works correctly if the selinux label is set. (In reply to Zbigniew Jędrzejewski-Szmek from comment #6) > Villy, thanks. See https://github.com/systemd/systemd/pull/17067. > > Lukáš: please verify that it works correctly if the selinux label is set. Just remember, that whenever SELinux has been disabled, you must re-enable it in permisive mode and relabel everything. (In reply to Zbigniew Jędrzejewski-Szmek from comment #6) > Villy, thanks. See https://github.com/systemd/systemd/pull/17067. > > Lukáš: please verify that it works correctly if the selinux label is set. Yes, it is working correctly. -Lukas Thanks for checking. Once the documentation patch is applied, we can consider this resolved. FEDORA-2020-0d29e88946 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-0d29e88946 FEDORA-2020-dc4f0fb907 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-dc4f0fb907 FEDORA-2020-0d29e88946 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-0d29e88946` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-0d29e88946 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-dc4f0fb907 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-dc4f0fb907` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-dc4f0fb907 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-0d29e88946 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-0d29e88946 FEDORA-2020-0d29e88946 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-0d29e88946` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-0d29e88946 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-0d29e88946 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2020-dc4f0fb907 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report. Hopefully this will help As far as I know, I've always had this issue. Fedora Linux 38 (Server Edition) This is what Cockpit shows me: Service logs August 25, 2023 6:02 PM Failed to start rc-local.service - /etc/rc.d/rc.local Compatibility. systemd 6:02 PM rc-local.service: Failed with result 'exit-code'. systemd 6:02 PM rc-local.service: Control process exited, code=exited, status=203/EXEC systemd 6:02 PM rc-local.service: Failed at step EXEC spawning /etc/rc.d/rc.local: Exec format error (rc.local) 6:02 PM rc-local.service: Failed to execute /etc/rc.d/rc.local: Exec format error (rc.local) 6:02 PM Starting rc-local.service - /etc/rc.d/rc.local Compatibility... systemd |
Description of problem: /etc/rc.local is never executed despite file existing and being executable. This is how I understand it from man systemd-rc-local-generator the only requisite to run rc.local during boot. # ls -la /etc/rc.local -rwxr-xr-x. 1 root root 74 Sep 8 13:08 /etc/rc.local Yet, the script is not executed Version-Release number of selected component (if applicable): Name : systemd Version : 245.7 Release : 1.fc32 Steps to Reproduce: 1. Create a script to run during boot 2. Copy the script to /etc/rc.local 3. chmod 755 /etc/rc.local Actual results: The /etc/rc.local script is never run. Expected results: The /etc/rc.local is run during boot. Additional information: # systemctl status rc-local ● rc-local.service - /etc/rc.d/rc.local Compatibility Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static; vendor p> Active: inactive (dead) Docs: man:systemd-rc-local-generator(8) # systemctl enable rc-local [ 951.624470] systemd-rc-local-generator[952]: /etc/rc.d/rc.local is not marked executable, skipping. The unit files have no installation config (WantedBy=, RequiredBy=, Also=, Alias= settings in the [Install] section, and DefaultInstance= for template units). This means they are not meant to be enabled using systemctl. Possible reasons for having this kind of units are: A unit may be statically enabled by being symlinked from another unit's .wants/ or .requires/ directory. A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...). In case of template units, the unit is meant to be enabled with some instance name specified.