Bug#1027166: rc.local should NOT depend on network-online or anything else

[Michael Biebl]

Control: severity -1 wishlist
Control: tags -1 + wontfix

Hello

Am 28.12.22 um 19:55 schrieb Michael Tokarev:
> Package: systemd
> Version: 252.2-2~bpo11+1
> Severity: serious
> 
> I just come across a situation where my notebook does not let me in while
> I'm in a place where network is not available. This is entirely wrong.
> After a painful debugging session, I found the debian-shipped file
> /lib/systemd/system/rc-local.service.d/debian.conf , which adds dependency
> of rc.local for network-online.
> 
> Found the commit which introduced this:
> 
> commit 4a26840495a297e50283a1f8def090540d15042d
> Author: Martin Pitt <martinpitt at gnome.org>
> Date:   Mon Jun 1 15:56:45 2015 +0200
> 
>      Make rc-local.service wait for network-online.target (if it gets started)
>      
>      Add debian/extra/units/rc-local.service.d/wait-online.conf.
>      This not specified by LSB, but has been behaving that way in Debian under SysV
>      init and upstart.
>      
>      LP: #1451797
> 
> and found the original bugreport from 2015,
> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1451797
> (and a new one filed in 2021,
> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1950906 ).
> 
> On all systems, rc.local is empty by default (or doesn't exist), so it does
> not depend on anything at all.  Only the user who modifies this file *locally*
> knows which dependencies are required, and this user can add their own
> /etc/systemd/system/rc-local.d/whatever.conf with the right deps, if needed.
> 
> Adding *any* dependencies by default is entirely, utterly wrong. This way,
> you force completely innocent, unsuspecting people who used to put some
> quick thing into their rc.local to suffer from being unable to login.

There are a couple of misconceptions in this bug report. I'll try to 
address them individually

- rc.local does *not* add a dependency on network-online.target (which 
would be a Wants or Requires), but merely adds an ordering (After=) 
against network-online.target.
network-online.target is an active unit, i.e. it needs to be pulled in 
explicitly. If the target was active for you, then some other unit other 
then rc-local.service requested its start

The choice of not adding a "Wants=network-online.target" to 
rc-local.service is deliberate. We do not want to pull it in by ourselves.

- "does not let me in"
I assume you mean that you are not able to log in (on the console).
This is incorrect. What network-online.target does (or to be specific 
the services that hook into network-online.target) is to delay the start 
of this target until network is available. So at most, you should 
experience a delay until you can log in. E.g. in case of 
NetworkManager-wait-online.service it is 60s.
If you have a service that hooks into network-online.target that blocks 
indefinitely, then this is a bug in this service. It should have a timeout.

- The After=network-online.target ordering in rc-local.service was done, 
as users in the past often added stuff like "mount some network 
resource) or did other stuff that required network access.
By changing the behaviour of rc-local.service we would breaks all those 
exising rc-local scripts out in the wild. So we are not going to change 
its behaviour when it has been this way for over decades.

So marking the bug as wishlist (change of behaviour) + wontfix.

If you don't like the rc.local behaviour, my recommendation would be to 
simply not use it. It's a hack anyway and it is super easy to write a 
custom service unit. Alternatively, you can disable

/etc/rc.local hasn't been installed by default for a long time and 
hasn't been made executable for even longer.

Regards,
Michael



-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20221231/ccd77bf3/attachment-0001.sig>