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 <martinp...@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



Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to