Network is brought down before network filesystems are unmounted (CIFS timeout at shutdown)

Is there anything in the logs about your connection?

Thanks
chuck

/var/log/messages from last startup

hamish@ht-laptop:~$ uname -r
2.6.24-15-generic

dmesg

look for"
[ 62.697883] CIFS VFS: Error connecting to IPv4 socket. Aborting operation
[ 62.697948] CIFS VFS: cifs_mount failed w/return code = -101

then after that wlan0 is configured

i think the timing of these operations is the problem

how do i get the shutting down logs so I can show you the errors there?

Hamish

...although I have included the error message in the original description above:

CIFS VFS: server not responding
CIFS VFS: no response for cmd 50 mid <this number changes>

eventually after 2-3 minutes this times out and the computer restarts, but it isn't really good enough

Hamish

lspci -vvnn

Do you get the same error when you mount the share using the command line?

chuck

Hi Chuck

I can umount and re- mount the shares using the command line (sudo umount -a and sudo mount -a) and it works successfully. I get nautilus sessions opening for each mounted drive every time I do this, which is very annoying!

I can do the following:
hamish@ht-laptop:~$ sudo mount -t cifs //192.168.73.10/<sharename> /home/hamish/nas_<sharename>
Password:

And it works successfully :-)

I *really* think that the problem is to do with the system attempting to read the /etc/fstab file and mount the drives *before* the network is up, and the reverse on the dismounts at shutdown/restart.

hamish@ht-laptop:/etc/rc2.d$ ls
README S12dbus S20powernowd S89cron
S01policykit S18avahi-daemon S20rsync S98usplash
S05vbesave S20apmd S24dhcdbd S99acpi-support
S10acpid S20apport S24hal S99laptop-mode
S10powernowd.early S20atieventsd S25pulseaudio S99rc.local
S10sysklogd S20cupsys S30gdm S99rmnologin
S10xserver-xorg-input-wacom S20hotkey-setup S89anacron S99stop-readahead
S11klogd S20nvidia-kernel S89atd

This works OK, as I get the drives mounted and then a separate nautilus session opens for each connected drive (which as I said previously is very annoying!), but we have the errors in the logs to prove that not all is good with this system of mounting drives.

hamish@ht-laptop:/etc/rc0.d$ ls
K01gdm K39ufw S20sendsigs
K01usplash K50alsa-utils S30urandom
K16dhcdbd K59mountoverflowtmp S31umountnfs.sh
K20apport K99laptop-mode S40umountfs
K20atieventsd README S60umountroot
K20avahi-daemon S01linux-restricted-modules-common S90halt
K25hwclock.sh S15wpa-ifupdown

hamish@ht-laptop:/etc/rc6.d$ ls
K01gdm K39ufw S20sendsigs
K01usplash K50alsa-utils S30urandom
K16dhcdbd K59mountoverflowtmp S31umountnfs.sh
K20apport K99laptop-mode S40umountfs
K20atieventsd README S60umountroot
K20avahi-daemon S01linux-restricted-modules-common S90reboot
K25hwclock.sh S15wpa-ifupdown

As you can see, S40umountfs is *after* S15wpa-ifupdown in both the above rc0.d and rc6.d. I *strongly* believe this is the problem.

Hope this helps

Hamish

The last part of this is a wpasupplicant bug. The ordering of the shutdown scripts is already well-established, and unmounting remote filesystems takes place at S31 (S31umountnfs.sh). wpasupplicant needs to be fixed to run its shutdown script later than this; probably at S35 or S36, which is the point in the runlevel sequence where networking as a whole is shut down in Debian.

Hi Steve

I have changed wpa-ifupdown to S41 for both rc0.d and rc6.d, but I still get the problem.

hamish@ht-laptop:/etc/rc0.d$ ls
K01gdm K30squid S30urandom
K01usplash K39ufw S31umountnfs.sh
K16dhcdbd K50alsa-utils S40umountfs
K20apport K59mountoverflowtmp S41wpa-ifupdown
K20atieventsd K99laptop-mode S60umountroot
K20avahi-daemon README S90halt
K20hddtemp S01linux-restricted-modules-common
K25hwclock.sh S20sendsigs

hamish@ht-laptop:/etc/rc6.d$ ls
K01gdm K30squid S30urandom
K01usplash K39ufw S31umountnfs.sh
K16dhcdbd K50alsa-utils S40umountfs
K20apport K59mountoverflowtmp S41wpa-ifupdown
K20atieventsd K99laptop-mode S60umountroot
K20avahi-daemon README S90reboot
K20hddtemp S01linux-restricted-modules-common
K25hwclock.sh S20sendsigs

Is there something else that needs to be changed?

Can this be escalated?

Hamish

I am commenting here to keep this thread alive, and wondering if any of the wpasupplicant team are looking at it? More than happy to keep experimenting and chatting about it! Thanks.

Hamish

I don't know if this bug is related to #212019, but the unmounting problem exists for me on a machine with no wifi-capabilities. I'm about to try http://ubuntuforums.org/showthread.php?t=293513 as a fix tonight, but that sounds like a workaround rather than a solutioni.

This bug occurred for me on 7.04. Yesterday I upgraded to 8.04 through 7.10, and the problem still exists. Haven't yet tried the workaround I mentioned, but I'm fairly sure it will work, since manual unmounting fixes/works around it. FYI, my reports are just for logging off, haven't seen any problems during startup.

This is a very old and well known problem. See also http://ubuntuforums.org/showthread.php?t=772774 and http://ubuntuforums.org/showthread.php?t=293513&highlight=cifs+vfs

I wonder why this bug is not fixed yet!

It has been proposed to change S31umountnfs.sh to K14umountnfs.sh in /etc/rc0.d and /etc/rc6.d. For me that works fine, but I am not shure that it can't create inconveniences in other cases. Please have a look at this simple workaround whether it can be recommended.

Please fix this perpetuating bug, there are quite a few solutions noted, the simplest being http://whereofwecannotspeak.wordpress.com/2007/12/25/unmount-samba-filesystems-before-shutdown-or-reboot/

I believe there are also duplicate bugs.

I agree with flaccid: This perpetuating and ennoying bug should be fixed as soon as possible!

That has even become more important with Hardy, since "smbfs" does not exist as a workaround any more, "smbmount" being nothing more than a wrapper for "mount.cifs".

The simple solution proposed in the link quoted by flaccid is the same as what I mentionned above, changing the shutdown-sequence. Would please an expert have a look at this to make sure it cannot cause other troubles!

I fix it on my system too changing the order umountnfs executes on inits 0 and 6 and think it may no have any problems as it says not root neither top levels mounts are unmount (the ones system need to continue shutdown properly):

# Short-Description: Unmount all network filesystems except the root file system.
# Description: Also unmounts all virtual filesystems (proc, devfs, devpts,
# usbfs, sysfs) that are not mounted at the top level.

I think the reason that moving S31umountnfs.sh to K14umountnfs.sh addresses the problem because there is now a dhcdbd script at K16dhcdbd which takes DHCP connections down much earlier than it should.

So I believe that in addition to the wpasupplicant bug, we have a bug in dhcdbd; both of these run stop scripts at a much earlier point in the shutdown than S31umountnfs.sh, and should be moved to S35 or S36 for consistency with existing behavior.

There is also definitely still a bug in samba, which should not take so long to time out on an unmount request when it's detectable that the network is down; but the init script bugs are rather easier to fix, and are bugs in their own right.

I don't think I have the problem on login, but I certainly do on shutdown - i.e. everything freezes with 3 bars left on the Ubuntu splash, then my whole screen goes white, and I have to force shutdown my laptop, (by holding down the power key for >5 secs) every single time.

Just migrated up to Intrepid, and the problem's still here.

Testing out Intrepid on my laptop here. I get this annoying pause every time I shutdown.

[462.892018] CIFS VFS: Server not responding
[462.892047] CIFS VFS: no response for cmd 50 mid 9

I do have a samba share automatically mount on boot up with /etc/fstab entry:

//192.168.1.2/Music /media/music_server smbfs credentials=/home/clickwir/.smbpasswd,uid=clickwir,gid=clickwir 0 0

And the share works fine. But shutting down is painful.

Again, this is Kubuntu Intrepid from a recent install of Alpha 5 cd. All updates applied as of this post.

clickwir@lappy:~$ uname -a
Linux lappy 2.6.27-4-generic #1 SMP Mon Sep 22 04:40:15 UTC 2008 x86_64 GNU/Linux

Anything I can do to help resolve this, I'm no expert but I'm willing to do what I can to help.

Same problem here

This annoying bug is known for a very long time now. I wonder why nothing has been done yet!

Another 'me to' running on Intrepid.

Been a problem since at least hardy. Fix doesn't seem hard (Just a change in the unmount order).

Possibly its also a upstart bug since its the init system?

I am experiencing this too with Intrepid. I use wireless connections from a laptop. Network Manager is dropping the network before the CIFS shares are unmounted causing multiple timeouts trying to unmount the during the shutdown process.

I'm not sure dhcdbd is affected because stopping it doesn't seem to bring down DHCP connections (at least not immediately).

So the solution to this bug could be to move S15wpa-ifupdown to S36wpa-ifupdown in wpasupplicant.

Could the people affected by this bug confirm that running the following commands fixes the issue without bringing in more problems than it solves :
$ sudo mv /etc/rc0.d/S15wpa-ifupdown /etc/rc0.d/S36wpa-ifupdown
$ sudo mv /etc/rc6.d/S15wpa-ifupdown /etc/rc6.d/S36wpa-ifupdown
(please keep umountnfs.sh at S31, where it belongs)

Maybe this helps (or complicates things).

I have a wired pc, desktop, no wireless at all.... same issue. Oh, and that one is on Hardy.

I tested the commands, Thierry, and there was no difference. I didn't really hold out a lot of hope, though, because I don't run the WPA supplicant. Everything works perfectly when I umount the CIFS filesystems before shutting down. I also found that Suspend and Hibernate modes work better too (as an aside).

Strange, umountnfs.sh (I double checked it for cifs) runs before networking so of course one would have to think everything would be okay. Does the logging off of the Gnome session, ending the Network Manager in the notification area, have something to do with it? I wonder what would happen if the networking was all static startup/shudown entries and network manager was never run (or even uninstalled).

Hm, so that might be related to user-level network configurations from NetworkManager being brought down at session logout (typically the NM wireless connection falls in that category).
It seems obvious this might not play well with network services (client or server) that expect network to be up very early (and very late). And that would not be as easy to fix as some think it is... as the "fix" would surely affect a feature that most people like.

confirming that "$ sudo mv /etc/rc6.d/S15wpa-ifupdown /etc/rc6.d/S36wpa-ifupdown" doesn't fix it.

Do people who were experiencing this bug with a wired connexion still have this issue in Intrepid fully up to date ? I had this issue on my desktop computer but it seems fixed now ?

I just tried wiring up my lappy, which is up to date with the distribution sources, and I have the same issue using Network Manager as I had with the wireless. An interesting test would be to code the activation of the wireless network connection into the local startup/shutdown process and remove Network Manager to see what happens. That wouldn't be a preferred solution, though, because the advantage to wireless is the ability to switch hot spots on the fly with NM. If I get time this weekend I can give it a try -- work has got me pretty out straight during the week (probably why they call it "work" and not "play" -- though they are both 4 letter words ;-)

still has the bug on fully updated intrepid (as at 29-Oct night); wired connection.

Yes, the whole network shutdown sequence needs to be revisited so as to work properly in the most common cases.
See also bug 41794 for a related issue: Network filesystems being unmounted after the VPN is closed.

I removed Network Manager with the Synaptic Package Manager (the network-manager and network-manager-gnome packages) and added my wireless startup information to /etc/rc.local like this:

ifconfig eth1 down
dhclient -r eth1
ifconfig eth1 up
iwconfig eth1 essid "MY ESSID"
iwconfig eth1 mode Managed
dhclient eth1

sleep 5

mount -a -t cifs

Everything now works perfectly as far as I have been able to tell. No delay in shutting down and the Suspend function seems to be working properly as well -- sorry I haven't tested Hibernate because I never really use that anyway. I mention the Suspend function because in the past with NM and cifs in the /etc/fstab file Suspend used to only work the first time, then every time after that the network would not reactivate and I had to reboot. Just in case anyone else is interested in that little tidbit of information.

This seems to definitely be a Network Manager induced condition.

I hope this helps.
--Gary

Fully up to date Intrepid +1.

I would really like to see this bug get fixed, the response time on this on makes me feel like I am on Windows again.

Yeah I would have to say that response with things in Ubuntu is pathetic.
A lot of the time its hard to get something fixed for the next release let alone in the current release where it should be fixed.
Its the good old 'have to upgrade to the next release to fix this problem, and then i get fresh new problems in the next release' (or continue to wait for a bug to be fixed and then it gets expired!).

Considering the people copied on bugs like this, its like they don't read their email..

So will somebody with authority like in Canonical get off their behind and sponsor one of the fixes that has been available for a very long time.

are there any up/down scripts for samba hooked into etc/network/if-up.d/ and /etc/network/if-down.d/ ? If not, we should try that as NM calls those scripts after network is up or before its downed.

flaccid <email address hidden> writes:

> So will somebody with authority like in Canonical get off their behind
> and sponsor one of the fixes that has been available for a very long
> time.

please attach a fix to this bug so that it can be reviewed, tested and
integrated into the package.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

@Reinhard Tartler:
I think flaccid has already pointed to a simple fix here: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/211631/comments/14

it worked for me.

I've used the following fix for months, as described in this duplicate: https://bugs.launchpad.net/bugs/184676

I would like to submit this for review. How would I "attach a fix to this bug" which involves only renaming files? Can you do it?

The fix is:
mv /etc/rc0.d/S31umountnfs.sh /etc/rc0.d/S14umountnfs.sh
mv /etc/rc6.d/S31umountnfs.sh /etc/rc6.d/S14umountnfs.sh

@Reinhard Tartler:
If you actually spent some time reading the bug and its related duplicates etc. you wouldn't need to ask that question.

The Upstart file I posted on #153 +autofs5 installed(very important) solves it for me on 10.10. over wifi. Autofs has to be installed, or the bug will stay. Today i found this is the working combo for me. You might want to try this with Natty, i was planning in the next few days, too tired today.

I have two machines running 11.04 with a wireless connection. I was able to get a clean shutdown on both by changing the link to /etc/init.d/umountnfs.sh in /etc/rc0.d and /etc/rc6.d from S31umountnfs.sh to K15umountnfs.sh. This is a workaround, not a fix, as it simply starts the cifs/nfs file unmounting script earlier in the shutdown process.

I got a desperate workaround, it's in this link: (http://hardc0l2e.wordpress.com/2011/06/30/ubuntu-11-04-shutdown-and-restart-problem-with-cifs/). It works, but not the best way to deal with this bug.

After months of attempts to fix this, I've finally found one that works for Kubuntu 11.04 (Natty). The problem is that Kubuntu (and I believe KDE more generally) starts the shutdown process in a way different than Gnome/Ubuntu, so even the dbus / netbase fixes, the fix above in #158, and using autofs all didn't work. I think KDE begins shutting down userspace functions like network manager first before the /etc/init scripts or /home/user/.kde/shutdown scripts are called upon. Just speculation on my part, but that'd be my guess.

But I apparently found the place where Kubuntu actually starts the shutdown process, or close to it - it's in the /usr/bin/starkde script. Immediately after the line saying "echo 'startkde: Shutting down...' 1>&2", I inserted a line saying "sudo umount -t cifs -a -f -l". Then, using visudo as root ("sudo visudo"), I edited the sudoers file to allow the sudo command to execute umount without a password by adding the line (at the bottom of the file) "username ALL=(root) NOPASSWD:/bin/umount". Worked like a charm.

found a better fix via /etc/init/dbus.conf

add the pre-stop script:

pre-stop script
    trap "TERM signal" TERM
     /bin/umount -a -t cifs -f -l
    trap - TERM
end script

It works for me and few tested notebooks and desktop PC.

@c0l2e : Wow, thanks man! I can confirm that your fix works great on all all systems as well (lucid).

Please read : on all *my* systems as well

@c0l2e: could you please provide a step-by-step explanation about how to make your solution work?
Where should I put that text?

@jonbonjovi, @c0l2e did say :)

Put it in /etc/init/dbus.conf. You'll probably find an existing pre-start/end script section in it (I did in mine). Just paste all the lines (including the pre-stop and end script lines) into that file, after the existing end script, or before the line that starts "exec" if you don't have a pre-start section in yours.

I found that it didn't work the first time I rebooted (maybe the script is read and cached somewhere before I changed it), but the next time I rebooted, it worked.

@ Steve Sutton:
done! it works!

Thanx!

I have the same problem:
on
# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 10.04.3 LTS
Release: 10.04
Codename: lucid

none of the these options worked for me, short:
- dbus.conf
- K14 links
- S31 earlier
- a modprobe option http://blog.dhampir.no/content/cifs-vfs-no-response-for-cmd-n-mid

the only option that seemed to work i found on
http://hardc0l2e.wordpress.com/2011/06/30/ubuntu-11-04-shutdown-and-restart-problem-with-cifs/

in short:
"
Rename the current shutdown, reboot and restart commands in /sbin.

#> mv /sbin/shutdown /sbin/shutdown2
#> mv /sbin/reboot /sbin/reboot2
#> mv /sbin/restart /sbin/restart2

2. Then create scripts with names of the previous commands in /sbin, which contains the following:

#!/bin/sh
umount -t cifs -a -f -l
/sbin/shutdown2 $@
exit 0

3. Make similar script for reboot and restart command which also points to /sbin/reboot2 and /sbin/restart2.
"
but i also had to change the two links under /sbin, halt and poweroff to point to reboot2 instead of reboot,
otherwise my machine would shutdown when isuing a shutdown -h now,
but just rebooted instead.

Could this be related to cifs getting mounted twice (when present in fstab)?

It took me quiet some time, to test, and find a solution.

more output:
i use cifs mount with a vpn connection (cisco),
after mount -a i then get
$mount
..
/dev/sdb1 on /media/terra type ext4 (rw,nosuid,nodev,uhelper=udisks)
//fas-gt-01/rt on /mnt/rt type cifs (rw,mand)
//fas-gt-02/brt on /mnt/brt_gt type cifs (rw,mand)
//fas-gt-02/EX on /mnt/Ex type cifs (ro,mand)
//fas-gt-02/EX on /mnt/Ex type cifs (ro,mand)
//fas-gt-02/GR on /mnt/gr type cifs (ro,mand)
//fas-gt-02/GR on /mnt/gr type cifs (ro,mand)

So the ro mount are mounted twide..? While the rw get mounted once..
fstab options rw mount:
cifs rw,noserverinfo,uid=1000,gid=1000,file_mode=0750,dir_mode=0750,credentials=/home/user/config/scripts/.cifs.credentials
fstab options rw mount:
cifs ro,noserverinfo,uid=1000,gid=1000,file_mode=0440,dir_mode=0440,credentials=/home/user/config/scripts/.cifs.credentials

i have attached cifs entries in syslog

hth,
G

Off topic, but the multiple mount can be caused if you miss trailing slashes off the mountpoint in fstab

/media/myfs < bad
/media/myfs/ < good

i'll try that,
but,
i have never putted trailing slashes in the mointpoints,
and the double moutings only occus for the cifs ro mounts

mvg,
G

On Mon, 2011-10-24 at 12:50 +0000, Steve Sutton wrote:
> Off topic, but the multiple mount can be caused if you miss trailing
> slashes off the mountpoint in fstab
>
> /media/myfs < bad
> /media/myfs/ < good
>

Since a week or so, the shutdown is delayed again (on Ubuntu 11.10), despite
the script in dbus.conf. Does anyone has a solution for this?

On Mon, Oct 24, 2011 at 16:03, Gonzals, S. <email address hidden>wrote:

> i'll try that,
> but,
> i have never putted trailing slashes in the mointpoints,
> and the double moutings only occus for the cifs ro mounts
>
> mvg,
> G
>
> On Mon, 2011-10-24 at 12:50 +0000, Steve Sutton wrote:
> > Off topic, but the multiple mount can be caused if you miss trailing
> > slashes off the mountpoint in fstab
> >
> > /media/myfs < bad
> > /media/myfs/ < good
> >
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (768506).
> https://bugs.launchpad.net/bugs/211631
>
> Title:
> Network is brought down before network filesystems are unmounted (CIFS
> timeout at shutdown)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/network-manager/+bug/211631/+subscriptions
>

On Wed, 2011-10-26 at 22:09 +0000, Ernst wrote:
> Since a week or so, the shutdown is delayed again (on Ubuntu 11.10), despite
> the script in dbus.conf. Does anyone has a solution for this?

the same on 10.4

also changing the shutdown, reboot (halt and poweroff) and restart
in /sbin
only works for the commandline,
not with gui (right upper corner gnome, choose shutdown),
the gui reboots instead of a shutdown

for now i manually umount before shutting down,
seems the only option without many surprises.

mvg,
G

>
> On Mon, Oct 24, 2011 at 16:03, Gonzals, S.
> <email address hidden>wrote:
>
> > i'll try that,
> > but,
> > i have never putted trailing slashes in the mointpoints,
> > and the double moutings only occus for the cifs ro mounts
> >
> > mvg,
> > G
> >
> > On Mon, 2011-10-24 at 12:50 +0000, Steve Sutton wrote:
> > > Off topic, but the multiple mount can be caused if you miss trailing
> > > slashes off the mountpoint in fstab
> > >
> > > /media/myfs < bad
> > > /media/myfs/ < good
> > >
> >
> > --
> > You received this bug notification because you are subscribed to a
> > duplicate bug report (768506).
> > https://bugs.launchpad.net/bugs/211631
> >
> > Title:
> > Network is brought down before network filesystems are unmounted (CIFS
> > timeout at shutdown)
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/network-manager/+bug/211631/+subscriptions
> >
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/211631
>
> Title:
> Network is brought down before network filesystems are unmounted (CIFS
> timeout at shutdown)
>
> Status in NetworkManager:
> New
> Status in NULL Project:
> Invalid
> Status in “dbus” package in Ubuntu:
> Fix Released
> Status in “dhcdbd” package in Ubuntu:
> Invalid
> Status in “netbase” package in Ubuntu:
> Fix Released
> Status in “network-manager” package in Ubuntu:
> Confirmed
> Status in “samba” package in Ubuntu:
> Invalid
> Status in “sysvinit” package in Ubuntu:
> Invalid
> Status in “wpasupplicant” package in Ubuntu:
> Confirmed
> Status in “dbus” source package in Lucid:
> New
> Status in “dhcdbd” source package in Lucid:
> Invalid
> Status in “netbase” source package in Lucid:
> New
> Status in “network-manager” source package in Lucid:
> New
> Status in “samba” source package in Lucid:
> New
> Status in “sysvinit” source package in Lucid:
> New
> Status in “wpasupplicant” source package in Lucid:
> New
> Status in “dbus” source package in Natty:
> New
> Status in “dhcdbd” source package in Natty:
> Invalid
> Status in “netbase” source package in Natty:
> New
> Status in “network-manager” source package in Natty:
> New
> Status in “samba” source package in Natty:
> New
> Status in “sysvinit” source package in Natty:
> New
> Status in “wpasupplicant” source package in Natty:
> New
> Status in “sysvinit” package in Debian:
> New
>
> Bug description:
> IMPORTANT: this bug has enough information; please don't post
> _anything_ unless a developer asks for specific feedback! By posting
> to this bug you only make it harder for a d...

Is the solution described in comment #143 and comment #147 really the correct one?

In short, that means dbus always stops on the event deconfiguring-networking, which is emitted when "/etc/init.d/networking stop" is called.

In other words, whenever "/etc/init.d/networking stop" is called, dbus gets killed.
That has a nasty effect: when dbus stops, gnome-settings-daemon crashes and that means the desktop theme is lost.

Please see bug #868095 [1] and my comment #3 on that bug.

VMware Tools does this all the time (calling networking stop) when suspending the machine. That means you are guaranteed to get a horrible looking (and not completely functional) desktop whenever you resume your VMware session.

That also happens if I simply restart the networking service:
    /etc/init.d/networking stop
    /etc/init.d/networking start

    (Of course, because this chain reaction that leads to gnome-settings-daemon death starts on "networking stop")

In conclusion, this seems to be a serious issue. I wonder if that is happening with more people besides myself and the other fella on bug #868095.

[1] https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/868095

On Sat, Oct 29, 2011 at 04:31:21PM -0000, Alonso Andres wrote:
> Is the solution described in comment #143 and comment #147 really the
> correct one?

No, it isn't; it just seems to be the best workaround anyone has proposed so
far.

> In short, that means dbus always stops on the event deconfiguring-
> networking, which is emitted when "/etc/init.d/networking stop" is
> called.

> In other words, whenever "/etc/init.d/networking stop" is called, dbus
> gets killed. That has a nasty effect: when dbus stops,
> gnome-settings-daemon crashes and that means the desktop theme is lost.

Yep, that's one of the side effects of this particular workaround.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

This bug is disappeared for me (it started reapppearing a week ago), with
the changes in /etc/init/dbus.conf still in effect.

Maybe this has to do with my reinstall of grub2; after that, my computer
shuts again. This possinly indicates it has to do with certain boot options?

another note:

The cifs mount are avalaible through vpn (in this case cisco vpn),
whenever the vpn connection is gone/disconnect,
but the remote drives still appear as mounted in mtab,
then
$umount --a -t cifs -l -f
takes a lot of time

HTH

On Wed, Nov 02, 2011 at 12:31:00PM -0000, Gonzals, S. wrote:
> The cifs mount are avalaible through vpn (in this case cisco vpn),
> whenever the vpn connection is gone/disconnect,
> but the remote drives still appear as mounted in mtab,
> then
> $umount --a -t cifs -l -f
> takes a lot of time

Yep, that's an understood failure mode: upstart is able to save
network-manager itself from being killed before umountnfs, but isn't
currently able to save the subprocesses (such as those for vpn handling)
that NM spawns.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Come on, a fix can't be done for this 4 years on? With all the various workarounds people have put in above comments, surely one of them can work for everyone?!

> Come on, a fix can't be done for this 4 years on?

In fact, between dbus and network-manager now waiting for the 'deconfiguring-networking' event before shutting down, and NM registering its child processes with /run/sendsigs.omit.d to fix bug #869635, I believe this should resolve the problem for the NM case in 12.04. Please test with the 12.04 beta and see if this isn't resolved for you.

> With all the various workarounds people have put in above comments,
> surely one of them can work for everyone?!

Nope. All of those workarounds are specific to one configuration or another.

wpasupplicant no longer includes an init script at all, so this task can also be considered fixed.

Steve Langasek - I have just tried to replicate in 12.04 beta and could not reproduce the issue any more. I had a mounted a SMB share using /etc/fstab which appeared to be successfully unmounted prior to shutdown (or at least, it didn't hang for a minute or so, it shut down immediately).

On vr, 2012-04-06 at 10:12 +0000, James wrote:
> Steve Langasek - I have just tried to replicate in 12.04 beta and could
> not reproduce the issue any more. I had a mounted a SMB share using
> /etc/fstab which appeared to be successfully unmounted prior to shutdown
> (or at least, it didn't hang for a minute or so, it shut down
> immediately).

did u also try cifs mount (using fstab) over a vpn connection,
thats the setup i use and have problems with on lucid (time-outs on
shutdown, which add about 2 minutes delay on the shutdown time)

mvg,
G

>

I have tried the cifs mount over VPN scenario and shutting down does still
take time. I think connected mounts at shutdown are fixed so they unmount,
but if the VPN is disconnected prior to shutdown the unmount will hang
still.

What type of VPN connection? If it is managed by NetworkManager, it should be brought down when network manager is brought down, *after* all network filesystems are brought down.

If not, that seems like a bug in whatever is running VPNs, but its probably not *this* bug. I would suggest reporting it separately with 'ubuntu-bug xxxx' where xxxx is the package which controls your VPN.

Well, that would normally be correct, but the VPN plugins depend on vpnc, pptp, openvpn, etc. to be running to establish and keep the VPN connection up for rekeying and such. Those don't get a pid file in /run/sendsigs.omit.d yet, and so they would get killed by the sendsigs script shortly before upstart jobs actually stop network-manager, and possibly before the remote storage is unmounted, depending on when that happens.

On Sat, Apr 21, 2012 at 04:47:40AM -0000, Mathieu Trudel-Lapierre wrote:
> Well, that would normally be correct, but the VPN plugins depend on
> vpnc, pptp, openvpn, etc. to be running to establish and keep the VPN
> connection up for rekeying and such. Those don't get a pid file in
> /run/sendsigs.omit.d yet, and so they would get killed by the sendsigs
> script shortly before upstart jobs actually stop network-manager, and
> possibly before the remote storage is unmounted, depending on when that
> happens.

Network storage is always unmounted after sendsigs, by design.

But it probably makes sense to track these other issues as a separate bug,
rather than continuing to use this single bug report for every problem
related to the symptom of slow unmounts on shutdown.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

only info:
the vpn seems to work fine,

mvg,
G

On za, 2012-04-21 at 04:28 +0000, Clint Byrum wrote:
> What type of VPN connection? If it is managed by NetworkManager, it
> should be brought down when network manager is brought down, *after* all
> network filesystems are brought down.
>
> If not, that seems like a bug in whatever is running VPNs, but its
> probably not *this* bug. I would suggest reporting it separately with
> 'ubuntu-bug xxxx' where xxxx is the package which controls your VPN.
>

I'll open a bug myself shortly for the VPN case; and reply here with the bug number.

Th e problems continues on precise pangolin and quantal quetzal

short info:
(cisco vpn, mount.cifs of drives, when shutting down it takes about 2 minutes because there a problem with the unmounting of the cifs drives; when manually unmounting before shutting down there is no problem, shutdown takes about 15 seconds)

It affects me too, but the last 20 times I clicked on this link ( This bug affects 119 people. Does this bug affect you? Edit ) since yesterday, it gives me a time out error, please try again in a few minutes

The problem is still there on a fresh Raring installation.

Here's a screenshot of the last few lines visible before my notebook shuts down. It's 13.04 as of May 27th.

Markus, your screenshot shows a network-manager error:

  nm-dispatcher.action: Caught signal 15, shutting down...

This indicates that some part of NM is not being correctly guarded from /etc/init.d/sendsigs, resulting in abnormal termination that breaks the network connection before network filesystems are being unmounted. Network Manager has previously been fixed for such bugs, but it seems to have recurred.

Please file a new bug report against the network-manager package including the screenshot and this information, and paste the number of the new bug here.

Steve, turns out, there already was such a bug report:

https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1066484/comments/11

Regarding the CIFS mounts: Today, I changed the "auto" cifs mounts during startup to "noauto,user" mounts, which get mounted by my user using a script after login. At the end of the day, the delay upon shutdown was gone.

Thank you for reporting this bug to Ubuntu. natty has reached EOL
(End of Life) for this package and is no longer supported. As
a result, this bug against natty is being marked "Won't Fix".
Please see https://wiki.ubuntu.com/Releases for currently
supported Ubuntu releases.

Please feel free to report any other bugs you may find.

It's a slightly different problem, I guess, but in Kubuntu 13.10 the shutdown does not complete for me. It stops with the message "Stale NFS file handle". I suppose this is a different bug because it involves NFS, not CIFS.

Unfortunately, the bug seems to be back in Ubuntu 16.04 (Xenial) now, probably due to changements in the boot and shutdown sequences. See also [bug 1577885].