Bug 1386052
Summary: | RFE: Ship rc.local template file and symlink | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Ian Wienand <iwienand> |
Component: | systemd | Assignee: | systemd-maint |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | gfa, johannbg, jsynacek, lnykryn, msekleta, muadda, s, systemd-maint, zbyszek |
Target Milestone: | --- | Keywords: | FutureFeature |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-08-05 20:38:26 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: |
Description
Ian Wienand
2016-10-18 02:32:58 UTC
Actually, just to be clear, I was wrong above and the Debian version [1] is enabled by default (has 755 permissions) and just "exit 0". So I was wrong that you also need to enable permissions there. That said, it still simplifies things if you can assume /etc/rc.local exists This might be relevant on ancient outdated distributions like RHEL or distributions which support multiple initsystem like Debian and Gentoo but this is not relevant on Fedora or any modern distribution. We do ship systemd-rc-local-generator as part of the systemd package, so in principle rc.local is supported. I don't think there's anything particularly wrong with it, if one ignores the fact that under sysvinit it gets executed after runlevel changes, and under systemd it gets executed before multi-user.target. Yes, my main argument would be that it is supported (rc-local service is there) but not particularly well documented. Even on 3 distros that all use systemd, I had to read the unit files, dig through the git history of the centos spec and pull apart the debian initscripts package to understand why debian had an /etc/rc.local, centos had a symlinked version and fedora didn't have any. Though using rc.local to do something wouldn't be your first choice, I feel like creating the symlink to the dummy file, as centos does, would really help the next person trying to deal with portable code (that they're probably not in a position to modify too much) that uses rc.local by at least bringing consistency that /etc/rc.local exists in some way Was not the whole purpose of not having any, to prepare people for it being deprecated and implementing this now after all those years due to a single report claiming it's missing kinda defeats that purpose no? People should now ( and probably are when it comes to Fedora, Arch and probably OpenSuse as well ) just create their type oneshot service files and order them according to their needs ( as opposed to be bound to it being executed before multi-user.target ) . If anything thing should be done at this point, the support for rc.local should be entirely removed. I'd prefer technical arguments, rather than delving into history of what who said when and why. If I'm an admin who needs to do some quick job at boot, and I'm going to write a oneshot unit, I'll need to create the script, and also the unit file, and run 'systemctl enable'. In the end, I'll end up with an identical result to rc.local, except for a different name of the script and unit. rc.local is a terrible mechanism when used by the distro or add-on packages, but as a admin tool it's OK. Your claim for technical argument response makes no sense you can just well say what where the technical arguments migrating legacy sysv initscripts to type service units or cron jobs ( and some which should not be migrated et all but you can thank Red Hatters for that utter and total crap ) to type timer units etc. When these tools all work OK for administrators ( And effort which could have all been skipped if the distribution was not planning to gradually deprecate all this legacy crap which will do nothing but hinder adoption and progress in the long run as it already has been doing ). This is no more effort for the administrator to create his type oneshot unit(s) which he can then order as he sees fit then there is to add a single line in configuration tool which bound to be run that line/script before the multi-user target which render this far from being OK as an admin tool. This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. rc.local is very much legacy. We still have support, but we don't need to encourage people to use it. |