[Bug 1080818] Re: Sanitize and decouple dependencies - cover all scenarios

[Launchpad Bug Tracker]

[Expired for upstart (Ubuntu) because there has been no activity for 60
days.]

** Changed in: upstart (Ubuntu)
       Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to upstart in Ubuntu.
https://bugs.launchpad.net/bugs/1080818

Title:
  Sanitize and decouple dependencies - cover all scenarios

Status in “upstart” package in Ubuntu:
  Expired

Bug description:
  Scenario:

  Trying a lot of different ways to disable plymouth, I find system
  shutdown to print "umount: / busy" on reboot/shutdown, with a
  subsequent forced fsck at boot.

  Current status of disable project is adding plymouth.enable=0 to
  GRUB_CMDLINE_LINUX in /etc/default/grub and mv'ing every
  plymouth*.conf to plymouth*.conf.disabled in /etc/init/

  Adding /usr/bin/lsof / to the relevant method in
  /etc/init.d/umountroot tells me that dhclient and dnsmasq still use /

  This sounds like the works of NetworkManager.

  /etc/init/network-manager has a clause to start (among others) and
  stop on dbus. I assume that starting dbus fails when plymouth (by not
  being enabled) fails to start early, and I assume that this means that
  the dbus upstart job doesn't have a relevant PID to stop it later,
  which means that it fails to take down NetworkManager, which fails to
  take down the dhclient and dnsmasq instances, prompting those to keep
  running, thus preventing / to be umounted (problem could, however,
  also be the clause "respawn" in /etc/init/network-manager.conf).

  In any event, at shutdown, dhclient and dnsmasq are active, leading to
  unclean umount of /.

  Now, disabling plymouth is a common use case, and the convoluted and
  non-documented interdependencies of upstart scripts makes this a
  nightmare that has, does and will cause data loss to users.

  Adding /usr/bin/killall dnsmasq and /usr/bin/killall dhclient to the
  relevant method in /etc/init.d/umountroot will fix this crudely, but
  any acceptable fix will involve decoupling upstart scripts (and
  /etc/init.d/umountroot) to a sufficient degree to make sure that the
  system is actually "shut-downable". A suggestion could be a cursory
  attendance at a "Systems Architecture 101" at some suitable online
  course purveyor.

  I am not all that familiar with systemd, but if the goal is to ditch
  sysv init, one might want to go with something designed by
  professionals instead of raving madmen...

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1080818/+subscriptions