Ubuntu
ifupdown package

umount of /var partition fails during shutdown, due to lingering dhclient

Bug #1089771 reported by Graham Waugh
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
ifupdown (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

The 'Unmounting local filesystems...' stage of shutdown fails, and reports that the /var partition is busy.
This occurs where /var is on its own separate partition.

I am using 64 bit Kubuntu 12.10 (quantal) but I was also able to reproduce this problem on a clean install of
xubuntu 12.10 i386 in virtualbox.

I added debugging messages to the script: /etc/init.d/umountfs
'fuser -m /var' shows that the only process with a file open on /var is dhclient, which has a dhcp lease file in /var/lib/dhcp/
Using 'fuser -k -m /var' in the umountfs script kills the offending process, allowing for a clean shutdown,
but that's not the right fix.

I'm not sure how to proceed from here.
dhclient is a child process of NetworkManager - should NetworkManager clean it up?
the /etc/init.d/sendsigs script, which kills other processes during shutdown, is specifically blocked from killing dhclient
by an entry in /run/sendsigs.omit.d/ so it is not clear to me what should be happening.

Apologies if I filed this in the wrong place.

Description: Ubuntu 12.10
Release: 12.10

upstart:
  Installed: 1.5-0ubuntu9
  Candidate: 1.5-0ubuntu9
  Version table:
 *** 1.5-0ubuntu9 0
        500 http://jp.archive.ubuntu.com/ubuntu/ quantal/main amd64 Packages
        100 /var/lib/dpkg/status

Graham Waugh (gureamu)
affects: upstart → upstart (Ubuntu)
Revision history for this message
Steve Langasek (vorlon) wrote :

> dhclient is a child process of NetworkManager - should
> NetworkManager clean it up?

Yes, it should.

affects: upstart (Ubuntu) → network-manager (Ubuntu)
Revision history for this message
Clint Byrum (clint-fewbar) wrote :

Actually I don't think this is network-manager's fault. By all rights, it should be *dead* by this point.

umountnfs.sh emits unmounted-remote-filesystems, which stops networking (stop on umounted-remote-filesystems), which emits deconfiguring-networking, which causes dbus to stop (stop on deconfiguring-networking), which causes network-manager to stop (stop on stopping dbus). So umountnfs.sh should not exit until network-manager (the upstart job) is considered *stopped*. This means that NetworkManager should be completely *dead*, even SIGKILL'd if it didn't die within 5 seconds.

/etc/init/networking.conf emits deconfiguring-networking in post-stop. If I'm reading the upstart state machine properly, job_finished() is not called until a job's state gets to JOB_WAITING, which would have to be after the post-stop. However, its possible post-stop had an error, which would still finish the stopping event for networking, but would not emit deconfiguring-networking. So, verbose logging would confirm this by showing that the networking post-stop failed.

If that shows true, I believe this would be resolved by changing dbus to

stop on stopping networking

affects: network-manager (Ubuntu) → ifupdown (Ubuntu)
Revision history for this message
Stéphane Graber (stgraber) wrote :

Can you attach a tarball of /var/log/upstart/ ?

Revision history for this message
Graham Waugh (gureamu) wrote :

> Can you attach a tarball of /var/log/upstart/ ?

Ok. These are from the xubuntu virtualbox install where I reproduced the bug.

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

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

Changed in ifupdown (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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