Bug#858677: No /etc/rc.local file provided

[Daniel Richard G.]

On Sat, 2017 Mar 25 13:25+0100, Martin Pitt wrote:
>
> Right. This is part of the SysV backwards compatibility stuff, but
> that doesn't mean that rc.local should be created and eternally
> handled by systemd itself.

As far as I'm concerned, rc.local stands on its own merits,
independently of SysV.

If I want to "just" add a small startup task---e.g. call setterm(1) to
disable console blanking---without figuring out the intricacies of the
init system du jour, then that's where I go.

> In fact it very much should not, as the precise semantics of rc.local
> are not well defined and it has caused several bug reports and
> confusion already (e. g. "does it wait for the network to be up?",
> which is a question which itself is not well-defined any more in a
> world of hotplug devices, wifi, and roaming).

If the semantics are not well-defined, then the solution is to flesh
them out. Disappearing the file altogether is a non-sequitur,
especially given that all the systemd machinery to execute rc.local
remains in place.

As concerns networking, I would add a note to the file about it, and
perhaps a pointer to the .service file where the dependency can be
tweaked. Choose a reasonable default, and let the user deal with the
hard cases.

> Therefore I close this. The proper way to add your custom jobs to the
> service manager is through systemd units.

Writing a custom systemd unit, and fully integrating with the init
system, is orders of magnitude harder than just adding a line or three
to an existing shell script. Harder, even, than it was to add a custom
SysV init.d script, which was evidently not good enough a solution to
make rc.local unnecessary.

Please remember that not everyone is as familiar with systemd as you
are, and while rc.local is an imperfect solution, it is one that many
users have found helpful---and that continues to be so regardless of the
underlying init system.