Firstly, I understand that nobody is a fan of rc.local ... However, other major distributions ship a non-executable template file that can be used with the systemd rc-local service. On Debian, the initscripts package installs a /etc/rc.local file with comments about how you really don't want to use it, and how it requires enabling x bits to run it (to prevent unnecessary delay in startup). [1] On RHEL/centos, after bug #968401 systemd shipis a dummy /etc/rc.d/rc.local file with similar contents [2]. This is symlinked by the spec at /etc/rc.local, which makes it compatible with Debian/Ubuntu [3]. It would be good if Fedora shipped this same dummy file and symlink to maximise compatibility across all these platforms. It's quite easy to get a lot of this wrong -- putting the file directly in /etc/rc.local will just do nothing on Fedora (systemd's rc-local service is only looking in /etc/rc.d/), obviously forgetting permissions makes it fail (at least a file comment tries to help you), also you need the right selinux context on the script with initrc_exec_t or even as root stuff goes wrong (which will be right if the package installs the dummy file). Thanks [1] https://sources.debian.net/src/sysvinit/2.88dsf-59.8/debian/initscripts.postinst/#L266 [2] https://git.centos.org/blob/rpms!systemd.git/fa0155282c6f7e120deb6d463ce81800e8d2e31f/SOURCES!rc.local [3] https://git.centos.org/blob/rpms!systemd.git/fa0155282c6f7e120deb6d463ce81800e8d2e31f/SPECS!systemd.spec
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.