/etc/rc.local is a thing of the past.
/etc/rc.local dates from the time of 4BSD, Seventh Edition Unix, and before.
It came about so that system administrators could make "local" modifications to the bootstrap process without (as they had had to) editing the
/etc/rc.local just over halfway through.
Of course, editing
/etc/rc.local was just as fraught with the same dangers, and people had war stories about it such as Steve Simmons' tale of putting it under version control, for example.
It was superseded by
/etc/inittab and a runlevel-based
rc in AT&T Unix System 3 in 1983 (and with a slightly different
/etc/inittab in AT&T Unix System 5).
rc system allowed multiple individual scripts to be dropped into script directories organized by run-levels, rather than needing administrators to edit the startup commands for each new piece of local software into a single
Even those (
/etc/inittab and run-levels both) are now things of the past.
In NetBSD and FreeBSD,
/etc/rc.local is a backwards compatibility mechanism, and not a native part of the system.
/etc/rc no longer runs it.
Instead, it is run by a Mewburn
rc service named
This reflects the FreeBSD manual's own advice to not use
/etc/rc.local but to use the Mewburn
rc system directly, placing Mewburn
rc scripts for whatever "local" thing that one wants to do in the
(This has been the advice for quite a while, Mewburn
rc having been introduced by NetBSD 1.5 in 2000 and added to FreeBSD in 2002.
In the older FreeBSD
/etc/rc, before Mewburn
rc, it had been labelled "obsolete" in 1995 and it had been deleted in 1998.)
In the Linux operating system world,
/etc/rc.local is at best similarly a backwards compatibility mechanism that is invoked by native mechanisms rather than directly employed.
systemd runs it from a systemd service (generated by a service generator, named
systemd-rc-local-generator, when an
/etc/rc.local file is discovered to exist at bootstrap).
rc (the clone of AT&T System 5
rc) runs it from a van Smoorenburg
Other system and service management toolsets do not run it at all, and it is simply a superfluous file in
/etc that is ignored.
Indeed, some operating systems have already eliminated these backwards compatibility features from systemd, too.
This is the case for Arch Linux, for example.
On Arch, the systemd
rc-local.service file is present simply because the backwards compatibility flag does not cover it.
(This is probably an oversight on the systemd people's parts.)
The service is no use without the
systemd-rc-local-generator though, which is what enables the service on the fly; and that is not built or included in systemd on Arch.
Even where they exist, these backward compatibility mechanisms can be surprising.
They don't run
/etc/rc.local in the quite the same way, in quite the same place in the bootstrap, as it used to be in the old Seventh Edition Unix system.
(Even that can be surprising, as
/etc/rc.local did not, in fact, run last in the old system, as the OpenBSD manual still points out.)
Things set up in
/etc/rc.local can, depending from the service ordering that happens to take place, end up completely undone by the likes of new udev rules, NetworkManager, systemd-logind, systemd-resolved, or various "Kit"s.
From back in the 1980s when editing services into
/etc/rc.local was first superseded by drop-in file mechanisms, the recommendation has been to create proper native service definitions for one's service management system; whether that be a service bundle for the nosh toolset's
/etc/rc.d/ script for Mewburn
rc, a service unit file for systemd, an
/etc/init/ job file for Upstart, a service directory for runit/s6/daemontools-encore, a service bundle for Solaris SMF, a plist for MacOS launchd, an
/etc/init.d/ script for van Smoorenburg
/etc/rc.local.d/ script for FreeBSD's drop-in file mechanism from 1995, or even (as Peter da Silva did in the 1980s and early 1990s) an honest-to-goodness script for AT&T System 5