rc.local should require network-online.target

Bug #1451797 reported by Dr. Jens Harbott
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
systemd (Ubuntu)
Fix Released
Low
Martin Pitt

Bug Description

The current definition in `/lib/systemd/system/rc-local.service` uses `After=network.target`, which is pretty useless, as `network.target` according to http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ only has relevance during shutdown, which never happens for rc.local.

The result is that tasks in rc.local may get started before the network is properly setup, which may cause them to fail, as this is a significant change from the old SysV init behaviour.

The solution would be to change the dependency to

Wants=network-online.target
After=network-online.target

see also the notes in http://www.freedesktop.org/software/systemd/man/systemd.special.html for that.

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: systemd 219-7ubuntu4 [modified: lib/systemd/system/rc-local.service]
ProcVersionSignature: Ubuntu 3.19.0-16.16-generic 3.19.3
Uname: Linux 3.19.0-16-generic x86_64
ApportVersion: 2.17.2-0ubuntu1
Architecture: amd64
Date: Tue May 5 11:40:42 2015
Lsusb:
 Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 001 Device 003: ID 0557:2221 ATEN International Co., Ltd Winbond Hermon
 Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: Supermicro X9DRT
ProcEnviron:
 LANGUAGE=en_US:
 TERM=screen
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.19.0-16-generic root=/dev/mapper/hostname--vg-root ro quiet splash vt.handoff=7
SourcePackage: systemd
UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 05/04/2012
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 1.0c
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: X9DRT
dmi.board.vendor: Supermicro
dmi.board.version: 1.21
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: Supermicro
dmi.chassis.version: 0123456789
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1.0c:bd05/04/2012:svnSupermicro:pnX9DRT:pvr0123456789:rvnSupermicro:rnX9DRT:rvr1.21:cvnSupermicro:ct3:cvr0123456789:
dmi.product.name: X9DRT
dmi.product.version: 0123456789
dmi.sys.vendor: Supermicro

Revision history for this message
Dr. Jens Harbott (j-harbott) wrote :
Revision history for this message
dino99 (9d9) wrote :

Confirmed by lp:1442044 which also have dupe

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in systemd (Ubuntu):
status: New → Confirmed
Revision history for this message
Martin Pitt (pitti) wrote :

The LSB (http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/facilname.html) has never required to wait with calling rc.local until the network is up. After all, that might very well be "never", and this would both diminish the usefulness of rc.local as well as change existing behaviour. Or did you see some documentation which says otherwise?

If you need to run something after getting online, I suggest putting it into /etc/network/ifup.d/.

Changed in systemd (Ubuntu):
importance: Undecided → Wishlist
status: Confirmed → Incomplete
Revision history for this message
Dr. Jens Harbott (j-harbott) wrote :

While I agree that this may never have been guaranteed, it has been working with all previous init systems. For me, the implied policy of using rc.local is: Run after all other init stuff has finished.

For example, https://github.com/puppetlabs/razor-server uses modifying rc.local in order to trigger some post installation actions to happen once the node has rebooted after being installed. This works pretty well with Precise and Trusty and also seems to be fine with most other distros.

Also, having a server with no network connectivity ever will also not be very useful. This is certainly different for desktop systems, but then, why would you have the

After=network.target

at all?

Changed in systemd (Ubuntu):
status: Incomplete → New
Martin Pitt (pitti)
Changed in systemd (Ubuntu):
status: New → Triaged
importance: Wishlist → Low
Revision history for this message
Martin Pitt (pitti) wrote :
Changed in systemd (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
status: Triaged → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (10.7 KiB)

This bug was fixed in the package systemd - 220-5ubuntu2

---------------
systemd (220-5ubuntu2) wily; urgency=medium

  * boot-and-services: Drop expectedFailure from NSpawn.test_boot() test, this
    seems to work properly now.

systemd (220-5ubuntu1) wily; urgency=medium

  * Merge with Debian unstable. Remaining Ubuntu changes:
    - Hack to support system-image read-only /etc, and modify files in
      /etc/writable/ instead.
    - Keep our much simpler udev maintainer scripts (all platforms must
      support udev, no debconf).
    - initramfs init-top: Drop scsi_wait_scan and udevadm settle, we do that
      in a more sensible way with wait-for-root.
    - initramfs init-bottom: If LVM is installed, settle udev,
      otherwise we get missing LV symlinks. Workaround for LP #1185394.
    - Add debian/udev.lvm2.init: Dummy SysV init script to satisfy insserv
      dependencies to "lvm2" which is handled with udev rules in Ubuntu.
    - Add debian/udev.lvm2.service to avoid running the dummy lvm2 init
      script.
    - Provide shutdown fallback for upstart. (LP: #1370329)
    - debian/extra/ifup@.service: Additionally run for "auto" class. We don't
      really support "allow-hotplug" in Ubuntu at the moment, so we need to
      deal with "auto" devices appearing after "/etc/init.d/networking start"
      already ran. (LP: #1374521) Also run ifup in the background during boot,
      to avoid blocking network.target. (LP: #1425376)
    - ifup@.service: Drop dependency on networking.service (i. e.
      /etc/init.d/networking), and merely ensure that /run/network exists.
      This avoids unnecessary dependencies/waiting during boot and dependency
      cycles if hooks wait for other interfaces to come up (like ifenslave
      with bonding interfaces). (LP: #1414544)
    - Add Get-RTC-is-in-local-time-setting-from-etc-default-rc.patch: In
      Ubuntu we currently keep the setting whether the RTC is in local or UTC
      time in /etc/default/rcS "UTC=yes|no", instead of /etc/adjtime.
      (LP: #1377258)
    - Put session scopes into all cgroup controllers. This makes unprivileged
      user LXC containers work under systemd. (LP: #1346734)
    - systemctl: Don't forward telinit u to upstart. This works around
      upstart's Restart() always reexec'ing /sbin/init on Restart(), even if
      that changes to point to systemd during the upgrade. This avoids running
      systemd during a dist-upgrade. (LP: #1430479)
    - Drop hwdb-update dependency from udev-trigger.service, which got
      introduced in v219-stable. This causes udev and plymouth to start too
      late and isn't really needed in Ubuntu yet as we don't support stateless
      systems yet and handle hwdb.bin updates through dpkg triggers. This can
      be dropped again with initramfs-tools 0.117.
    - Lower Breaks: to plymouth version which has the udev inotify fix in
      Ubuntu.
    - Lower apparmor Breaks: to the Ubuntu version that dropped $remote_fs.
    - Change systemd-sysv's conflicts to upstart-sysv. (LP: #1422681)
    - Make failure of boot-and-services NSpawn.test_boot non-fatal for now.
      This currently fails when being triggered by Jenkins, but is totall...

Changed in systemd (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Steve Dodd (anarchetic) wrote :

This commit actually didn't reliably fix this bug, but given the length of time here, I've opened a new bug #1950906

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.