etc/rc.local should Want or Require network-online.target

[Steve Dodd]

The fix for bug #1451797 introduced /lib/systemd/system/rc-local.service.d/debian.conf with the intent that rc.local would always run after the network was fully online. However, it only has an After= line, without actually pulling in network-online.target. Systemd docs say:

"Units that strictly require a configured network connection should pull in network-online.target (via a Wants= type dependency) and order themselves after it. ... Note the distinction between this unit and network.target. This unit is an active unit (i.e. pulled in by the consumer rather than the
provider of this functionality) ... Usually, network.target is part of the boot of most systems, while network-online.target is not ..."

TL;DR - need to add "Wants=network-online.target" to /lib/systemd/system/rc-local.service.d/debian.conf :)

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: systemd 245.4-4ubuntu3.13
ProcVersionSignature: Ubuntu 5.4.0-90.101-generic 5.4.148
Uname: Linux 5.4.0-90-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.21
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: Xpra
CurrentDmesg: Error: command ['dmesg'] failed with exit code 1: dmesg: read kernel buffer failed: Operation not permitted
Date: Sun Nov 14 17:22:54 2021
InstallationDate: Installed on 2017-01-08 (1771 days ago)
InstallationMedia: Xubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 003: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Lsusb-t:
 /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
 /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 480M
     |__ Port 9: Dev 3, If 0, Class=Vendor Specific Class, Driver=cp210x, 12M
MachineType: Dell Inc. OptiPlex 3040
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.4.0-90-generic root=/dev/mapper/lvg2-host ro rootflags=subvol=rootfs rw drm.edid_firmware=edid/toguard2.bin video=HDMI-A-1:1024x768@60D
SourcePackage: systemd
UpgradeStatus: Upgraded to focal on 2021-09-02 (73 days ago)
acpidump:

dmi.bios.date: 06/30/2016
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 1.4.6
dmi.board.name: 0TTDMJ
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 3
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr1.4.6:bd06/30/2016:svnDellInc.:pnOptiPlex3040:pvr:rvnDellInc.:rn0TTDMJ:rvrA00:cvnDellInc.:ct3:cvr:
dmi.product.name: OptiPlex 3040
dmi.product.sku: 06BB
dmi.sys.vendor: Dell Inc.
mtime.conffile..etc.systemd.logind.conf: 2019-03-03T09:57:30.814201

[Michael Tokarev (mjt+launchpad-tls)]

Hmm. Come on please. rc.local should NOT, in any way possible, depend on network-online *by default*. Enabling that After= directive was a mistake. Why do you think that any system not connected to the network but which uses anything in rc.local (like doing any *local* stuff) should not let the user to login? Is this a joke or what? Guys, come on, this is insane..

I come here after having a painful debugging session with my pc not letting me in. Because rc.local is waiting for the network which is not here.

If *your* rc.local modifications (rc.local is empty by default) require network, by all means, add a *local* config droplet like this. But never, ever, lock people out of their PCs.

*Shrug*.

[Steve Dodd (anarchetic)]

Valid point, though arguably a different bug. Looks like mimicking the old
sysvinit behaviour might be quite tricky. Maybe a comment in the stub
rc.local would do? Unless we can do something clever with unit run
conditions...

On Wed, 28 Dec 2022, 18:50 Michael Tokarev, <email address hidden>
wrote:

> Hmm. Come on please. rc.local should NOT, in any way possible, depend on
> network-online *by default*. Enabling that After= directive was a
> mistake. Why do you think that any system not connected to the network
> but which uses anything in rc.local (like doing any *local* stuff)
> should not let the user to login? Is this a joke or what? Guys, come
> on, this is insane..
>
> I come here after having a painful debugging session with my pc not
> letting me in. Because rc.local is waiting for the network which is not
> here.
>
> If *your* rc.local modifications (rc.local is empty by default) require
> network, by all means, add a *local* config droplet like this. But
> never, ever, lock people out of their PCs.
>
> *Shrug*.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1950906
>
> Title:
> etc/rc.local should Want or Require network-online.target
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1950906/+subscriptions
>
>

[Igel Kun (igelkun)]

I must agree with Michael Tokarev. I too decideed to do some local stuff using rc-local and now my bootup hangs unneccessarily for a few seconds each time waiting for NetworkManager to establish a connection.

Here's a crazy idea: why not have an rc-local-with-network in which one can dump all the local stuff that needs networking and everything else can go into the normal rc-local? I'll go configure this right now on my system :)