Ubuntu

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

Reported by Yattletrot on 2008-04-04
718
This bug affects 120 people
Affects Status Importance Assigned to Milestone
dbus (Ubuntu)
Medium
Clint Byrum
Declined for Intrepid by Clint Byrum
Declined for Jaunty by Clint Byrum
Declined for Karmic by Clint Byrum
dhcdbd (Ubuntu)
Undecided
Unassigned
Declined for Intrepid by Clint Byrum
Declined for Jaunty by Clint Byrum
Declined for Karmic by Clint Byrum
Lucid
Undecided
Unassigned
Natty
Undecided
Unassigned
netbase (Ubuntu)
Undecided
Unassigned
Declined for Intrepid by Clint Byrum
Declined for Jaunty by Clint Byrum
Declined for Karmic by Clint Byrum
network-manager (Ubuntu)
Medium
Unassigned
Declined for Intrepid by Clint Byrum
Declined for Jaunty by Clint Byrum
Declined for Karmic by Clint Byrum
sysvinit (Debian)
New
Unknown
sysvinit (Ubuntu)
Undecided
Unassigned
Declined for Intrepid by Clint Byrum
Declined for Jaunty by Clint Byrum
Declined for Karmic by Clint Byrum
wpasupplicant (Ubuntu)
Medium
Unassigned
Declined for Intrepid by Clint Byrum
Declined for Jaunty by Clint Byrum
Declined for Karmic by Clint Byrum

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 developer to spot the gem comments. Please use the "me too feature" of launchpad to signal that you are affected and would like to see this fixed.

I installed smbfs,and then put some entries into /etc/fstab, so they automount on startup. An example of this is here:
//<ip address of nas box>/<share name> /home/hamish/<directory name> cifs credentials=/home/hamish/.smbcredentials,file_mode=0777,dir_mode=0777,uid=1000,gid=1000 0 0

** note the use of "cifs" in the lines above **

(The username and password are in the .smbcredentials file)

On startup, for each entry in the /etc/fstab file, I get the following in dmesg:
[ 70.495504] CIFS VFS: Error connecting to IPv4 socket. Aborting operation
[ 70.495569] CIFS VFS: cifs_mount failed w/return code = -101
But the shares are mounted, and a nautilus session opens up (which is also annoying...)

Also logging off with CIFS shares mounted in /etc/fstab, it sits with an error message:
CIFS VFS: server not responding
CIFS VFS: no response for cmd 50 mid <this number changes>
And takes about 2 minutes to timeout. This also happened with Gutsy

Should the timing of the mounting and dismounting be changed so that it works? It is related to the starting of network-manager and CIFS shares trying to connect on startup *before* the network is up, and dismounting the shares *after* network-manager is stopped.

Hamish

Chuck Short (zulcss) wrote :

Is there anything in the logs about your connection?

Thanks
chuck

Changed in samba:
status: New → Incomplete

/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

Chuck Short (zulcss) wrote :

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

Steve Langasek (vorlon) wrote :

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.

Changed in wpasupplicant:
importance: Undecided → Medium
status: New → Confirmed

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

Laurens Simonis (laurens.s) wrote :

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.

Laurens Simonis (laurens.s) wrote :

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.

flaccid (chris-xhost) wrote :

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!

Alfonso Moratalla (vanhell) wrote :

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.

Changed in samba:
status: Incomplete → Confirmed
Steve Langasek (vorlon) wrote :

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.

Changed in dhcdbd:
importance: Undecided → Medium
status: New → Confirmed

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.

clickwir (clickwir) wrote :

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.

Markus Golser (golserma) wrote :

Same problem here

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

H3g3m0n (h3g3m0n) wrote :

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?

gecobb@maine.rr.com (gecobb) wrote :

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.

Thierry Carrez (ttx) wrote :

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)

Changed in dhcdbd:
importance: Medium → Undecided
status: Confirmed → New
Changed in samba:
importance: Undecided → Low
clickwir (clickwir) wrote :

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.

gecobb@maine.rr.com (gecobb) wrote :

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).

Thierry Carrez (ttx) wrote :

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.

wolfie2x (wolfie2x) wrote :

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 ?

gecobb@maine.rr.com (gecobb) wrote :

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 ;-)

wolfie2x (wolfie2x) wrote :

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

Thierry Carrez (ttx) wrote :

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.

gecobb@maine.rr.com (gecobb) wrote :

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

Het Irv (hetirv) wrote :

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.

flaccid (chris-xhost) wrote :

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.

Alexander Sack (asac) wrote :

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.

Changed in network-manager:
importance: Undecided → Medium
status: New → Incomplete

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.

luchio (luch3) wrote :

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

flaccid (chris-xhost) wrote :

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

luchio <email address hidden> writes:

> 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

I'm unsure if that is the correct solution. It will most likely to break
systems that have /usr not on /. Similar problems could arise with
/usr/local/ not on / but custom modifications.

However I wonder if S15wpa-ifupdown should be moved to S41wpa-ifupdown
instead. That *should* cause less breakage and do the right thing
generally.

comments?

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

> mv /etc/rc0.d/S31umountnfs.sh /etc/rc0.d/S14umountnfs.sh
> mv /etc/rc6.d/S31umountnfs.sh /etc/rc6.d/S14umountnfs.sh

This fix is a rather old thing; it had been published more than two years ago.

I had asked here if this solution was correct and really safe, but I did not get any answer yet!

luchio (luch3) wrote :

 Reinhard Tartler wrote:
> I'm unsure if that is the correct solution. It will most likely to break
> systems that have /usr not on /. Similar problems could arise with
> /usr/local/ not on / but custom modifications.

As I said, I don't know the right way to do a rename patch, so does someone know?

 Reinhard Tartler wrote:
> However I wonder if S15wpa-ifupdown should be moved to S41wpa-ifupdown
> instead. That *should* cause less breakage and do the right thing
> generally.

Well, 2 people reported in this very thread that moving wpa-ifupdown to S36 does not fix it. I think that's because of K16dhcdbd.sh. Name resolution is still needed when unmounting NFS drives.

That's why the patch suggests moving up umountnfs instead of pushing down 2 things.

luchio <email address hidden> writes:

> Reinhard Tartler wrote:
>> I'm unsure if that is the correct solution. It will most likely to break
>> systems that have /usr not on /. Similar problems could arise with
>> /usr/local/ not on / but custom modifications.
>
> As I said, I don't know the right way to do a rename patch, so does
> someone know?

creating a patch for that is not the problem. Finding the correct
solution with a proper explanation for debian/changelog is way more
challanging and important!

> Reinhard Tartler wrote:
>> However I wonder if S15wpa-ifupdown should be moved to S41wpa-ifupdown
>> instead. That *should* cause less breakage and do the right thing
>> generally.
>
> Well, 2 people reported in this very thread that moving wpa-ifupdown to
> S36 does not fix it. I think that's because of K16dhcdbd.sh. Name
> resolution is still needed when unmounting NFS drives.

That does not really make sense. According to
http://www.debian.org/doc/debian-policy/ch-opersys.html#s-sysvinit, the
Knn scripts are always executed before any S script. I cannot see how
renaming S15wpa-ifupdown to S41wpa-ifupdown will interefere here.

As this is an extra indication that I have not understood the problem
completely, and given that this bug is already pretty heatly discussed,
I will take extra care before considering any change in this matter.

Looking further at it, it seems pretty obvious why renaming it to
S36wpa-ifupdown does not fix it: unmounting nfs and other filesystems
happen at S40. In order to fix this issue wpasupplicant has to be taken
down after that. Which is a real pain in debian, since wpasupplicant is
installed there in /usr/sbin, which might no longer be available at this
stage. Luckily in ubuntu it is in /sbin, though.

> That's why the patch suggests moving up umountnfs instead of pushing
> down 2 things.

Yes, still I'd like to know what I'm actually doing before uploading
random patches some guys on some bug have proposed that might or might
not fix a (granted, very annoying) bug.

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

For several years, I've had a script that umounts my network shares which runs at K02. It works perfectly for me. Is there a reason why something like this isn't a good general approach?

Fabri Velas (fabrivelas) wrote :

The best solution to avoid messing up the unmounting issue for special cases as described by Reinhard Tartler 5 posts ago is to use a special unmounting script for cifs. People who have used the workaround described by luchio have never used such a special case scenario. Therefore it is much more prudent to leave the present scrips as they are and introduce a new script for cifs. This solution has been proposed before by Sander Marechal. Here is a link to the description of the solution and the script: http://www.jejik.com/articles/2007/07/automatically_mounting_and_unmounting_samba_windows_shares_with_cifs/
It says there: "To solve it I [Sander Marechal] wrote a little script cobbled together from bits and pieces of the umountnfs.sh and sendsigs init scripts. Basically it makes a list of all your mounted CIFS filesystems, shuts down and subsequently kills all processes that are still using those filesystems, and finally unmounts the CIFS filesystems. Save it to /etc/init.d/umountcifs and make it executable. Then symlink to it from /etc/rc0.d and /etc/rc6.d. You should ensure that umountcifs runs before the K20* init scripts fire. If it runs at K20 or later, you will still get the error. Personally I symlinked from /etc/rc(0|6).d/K19umountcifs."
With this following update: "Neill Hogarth adds that for (K)ubuntu 7.10 the script should be symlinked as K12umountcifs. K19 seems to work on (K)ubuntu 7.04 and lower, and on Debian Etch."

Fabri Velas (fabrivelas) wrote :

The best solution to avoid messing up the unmounting issue for special cases as described by Reinhard Tartler 5 posts ago is to use a special unmounting script for cifs. People who have used the workaround described by luchio have never used such a special case scenario. Therefore it is much more prudent to leave the present scrips as they are and introduce a new script for cifs. This solution has been proposed before by Sander Marechal. Here is a link to the description of the solution and the script: http://www.jejik.com/articles/2007/07/automatically_mounting_and_unmounting_samba_windows_shares_with_cifs/
It says there: "To solve it I [Sander Marechal] wrote a little script cobbled together from bits and pieces of the umountnfs.sh and sendsigs init scripts. Basically it makes a list of all your mounted CIFS filesystems, shuts down and subsequently kills all processes that are still using those filesystems, and finally unmounts the CIFS filesystems. Save it to /etc/init.d/umountcifs and make it executable. Then symlink to it from /etc/rc0.d and /etc/rc6.d. You should ensure that umountcifs runs before the K20* init scripts fire. If it runs at K20 or later, you will still get the error. Personally I symlinked from /etc/rc(0|6).d/K19umountcifs."
With this following update: "Neill Hogarth adds that for (K)ubuntu 7.10 the script should be symlinked as K12umountcifs. K19 seems to work on (K)ubuntu 7.04 and lower, and on Debian Etch."

luchio (luch3) wrote :

The umountcifs script seems to solve the problem here (tested as K12umountcifs). Of course, I had removed the other S14umountnfs.sh I had added manually earlier.

It would be cleaner to do the symlinks as "../init.d/umountcifs" like other rc0.d scripts, instead of /etc/init.d. Otherwise, it *looks* good. I have not checked if this causes other messages in the system log, I only checked if the "CIFS VFS: server not responding" msgs were gone.

toobuntu (toobuntu) wrote :

For our network using Ubuntu 8.04, Sander Marechal's umountcifs script works when symlinked as K15umountcifs (i.e. the key is that it is called prior to K16dhcdbd).

$ sudo ln -s /etc/init.d/umountcifs /etc/rc0.d/K15umountcifs
$ sudo ln -s /etc/init.d/umountcifs /etc/rc6.d/K15umountcifs

gecobb@maine.rr.com (gecobb) wrote :

In case anyone cares, my initial testing using this method has been very successful so far, both shutdown/restart and suspend/resume are working as I expect. Would be possible to have Canonical officially embrace and include this script in the Ubuntu base packaging and close out this issue once and for all? In the interest of having a Linux deliverable that "just works" right out of the box it seems like this would be a strategic move to me. There's a little bad press further up stream here that I'd like to see turned around. In my opinion this is by far the best release of Ubuntu yet (I've used Intrepid since the Beta and have updated but never actually re-installed with the official version), and now it is 100% complete for me. Thanks for turning me on to this script, and thanks for an awesome Linux environment! --Gary

Mathias Gug (mathiaz) wrote :

The issue discussed here boils down to the fact that network interfaces can be brought down *before* network filesystems are unmounted thus leading to a long timeout.

One option proposed was to move the umountnfs script earlier in the shutdown sequence. Doing leads to the possibility that running processes still have files opened on the network share. This is the reason why S31umountnfs.sh is run *after* S20sendsigs. Some packages have their shutdown scripts set too early in the boot sequence. These should be fix them rather then moving the umountnfs script earlier in the shutdown sequence.

Another option suggested was to use the ifdown.d infrastructure. That means writing a script that is able to unmount network filesystems according to the interface been brought down. However the script should not unmount the remote filesystems when *a* network interface goes down but rather unmount them when the *corresponding* network interface goes down.

What *should* be happening in all cases is that the network route is gone. Trying to send to it will return a no-route-to-host which can be detected and handled by the kernel. So either the route isn't being torn out when it should be, and we should fix that; or the cifs driver doesn't handle no-route-to-host, and we should fix that. Adjusting the timeouts or moving/adding init scripts shouldn't matter at all.

luchio (luch3) wrote :

@Mathias Gug

So, what do you suggest should happen now? Submit a bug report to samba and wait for them?

@ luchio

We are already waiting for years, and nothing did really happen. It is a shame.

Even if it is far from being a perfect solution, it is better to propose a workaround like the script of Scott Severance than to do just nothing.

meestermole (meestermole) wrote :

Why isn't this fixed after so long? The big thing keeping me from switching to Linux full time is that i run into these type of bugs, and no sooner do i get them fixed and feel like i've made progress that ANOTHER bug shows up. The more I want to do with my system, the more bugs I need to find workarounds for. This one is a bit over my head, I'm afraid. Seeing many posts about a bug that has existed for years does not give me much hope.

flaccid (chris-xhost) wrote :

I think the problem lies with the lack of action on behalf of people with power to commit fixes such as Canonical sponsors.
I gave up on Ubuntu's management a long time ago. Where are the chiefs?

I am afraid the problem is that in this case nobody really feels responsible. Is it a problem of the shutdown sequence (Ubuntu problem), of the cifs Kernel module (Linux general) or a Samba bug? Who has got to fix it?

As long as nobody feels responsible there is not much hope indeed.

flaccid (chris-xhost) wrote :

@Max-Ulrich Farber

I disagree and I don't think you can speak for others like that. Considering the Linux kernel and Samba itself are shared between hundreds of Linux distributions and that Samba is basically the same (in this context) on other operating systems such as FreeBSD etc., it is clear that its the responsibility of the distribution especially considering scripts existed already and were simply executed at the wrong stage of the shutdown sequence.

'Who' wants to take responsibility is kind of irrelevant here considering fixes are available and we are only asking for 1 of these to be committed as opposed to 'someone take the blame will you'.

I am sorry. I never wanted to speak for others. It is my opinion, but it would be better if I had said nothing at all.

>considering scripts existed already and were simply executed at the wrong stage of the shutdown sequence

Do these scripts really fix the problem? Please read the posting of Mathias Gug:
>Adjusting the timeouts or moving/adding init scripts shouldn't matter at all.

But I do not want to speak for Mathias. He explained it much better himself.

flaccid (chris-xhost) wrote :

@Max-Ulrich Farber

What Mathias Gug was suggesting may be a better solution however not the current method that Ubuntu employs in its [shutdown] scripts. Considering how hard it is to get the other fixes committed as a solution (which do work, I have tested and so have others), I would assume this would be harder to get committed. Mathias suggested a great possibility but did not attach the actual fix or try it so that doesn't help at all unfortunately.

Owen PG (owen-pg) wrote :

I just think it's a laugh, a linux distribution that can't cope with either NFS or CIFS mounts. See below for details:

https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/213444

Yes and I need to mount a resource both by NFS and CIFS . . .

It can't all be blamed on bug 1 - MS don't support nfs.

https://launchpad.net/ubuntu/+bug/1

I can't understand that the importance of this bug is still set to "low" in samba after such a long time!

flaccid (chris-xhost) wrote :

Ubuntu - too many indians, no chiefs. Oh there are chiefs but they must be too busy smoking crack.

James (james-ellis-gmail) wrote :

So I've read through this entire thread and seen a lot of solutions. I have a fully updated intrepid and this line appears at shutdown (take out the splash line in your kernel command in grub to see it) :
CIFS VFS: No response for ......

basically the same as the original report.
CIFS VFS: server not responding
CIFS VFS: no response for cmd 50 mid <this number changes>

With the result being that the system doesn't shutdown for a longggg time.

I don't want to mess around with init scripts, so I propose two solutions (and note I'm not a programmer):
1. If no network is present when the system is shutting down, try forcing the umount ?
$man umount
-f Force unmount (in case of an unreachable NFS system). (Requires kernel 2.1.116 or later.)
2. Bring the mount down before the network is bought down on shutdown (which seems sensible given remote file systems require a network)

BTW, my CIFS mount is created in userspace in Kubuntu on login, if that alters anything.
$ cat .kde/Autostart/mounts.sh
kdesudo -d --comment "Attach media share" -c "mount -t cifs //remote/media /path/to/mount/point -o username=xxx,rw,password=zzz"

PascalCavy (p92) wrote :

And what if Networkmanager be protected from beeing killed in sendsig and network beeing brought down at end of shutdown ?

wolfie2x (wolfie2x) wrote :

Ok that's it; I'm done with this. Just a waste of time.. All talk 'n no action. I'll just use one of the suggested fixes. If that doesn't work I'll have a big sticky note saying "Remember to unmount your Samba shares!".
The problem is known; Several solutions are known; but just keep dragging forever.. plain ridiculous.

flaccid (chris-xhost) wrote :

@<email address hidden>
I agree of course. You just described the Ubuntu project!

The thing is people solve Launchpad Ubuntu bugs all the time. The problem is the managers of the distro. The other problem is how hard it is to get a fix committed.
This is not the only example of where I have done the pro-active thing and raised a bug, I am stopping reports of any bugs for Ubuntu. It simply is not worth the effort.

Ubuntu has proved to be a political project and not an active one. It is far from Linux for human beings, that it claims. What a joke. Congratulations Ubuntu you have proven to be like a company full of lies and marketing bullshite.

bobp (custom-basses) wrote :

I also did the right thing and reported this bug in one of the reports that was marked as a duplicate. Yes it is frustrating to see bugs take so long to get fixed, and ultimately lack of a positive result teaches users to give up bothering to file bug reports. That's not a good thing, as it causes bugs to go unreported and impedes progress.

In the big scheme of things, using Linux teaches you patience, teaches you to learn to live with disappointment, and teaches you to look on the bright side: I left Gentoo development many years ago because of problems like this. With that other distro, bugs would remain unfixed and some developers would deny that bugs exist and invalidate bug reports without fixing the bugs, just to buff up their bug closure statistics. Then users would fight to have them reopened, and the developer would immediately re-close it. It was like beating your head against the wall. The entire process of user reporting and developer invalidating would repeat itself over and over again in a never ending cycle. It evolved into a farce.

Watching the Gentoo developers insist that the bugs don't exist can be quite amusing -- even though I have not used the distribution any more, I'm still receiving email updates regarding an rsync time logging bug that remains unresolved 5 years after I first reported it, and the same developer continues to close the bug reports every time that users re-open them. Ubuntu may be far from perfect, but at least the price is right and you don't have to waste hours or days COMPILING an entire operating system only to find that it doesn't work right. Look on the bright side -- our situation could be much worse than it is.

flaccid (chris-xhost) wrote :

@bopb
I'm not sure that your closing point has much relevence to completing this bug. It merely suggests you accept the mediocrity of the situation. Of course the situation could be much worse than this, thats just stating the obvious. This does not mean its acceptable.
Oh and there are many other out of the box style Linux distros out there as well as desktop solutions such as PC-BSD. If you have a look around you will find there are dozens of alternatives to Ubuntu.
Also the good old 'but its free' argument is always bogus and classically used as an excuse. Ubuntu has a lot of members on board and is sponsored commercially so there isn't an excuse for no action here.

Ramón Rocha (ramon.rocha) wrote :

Until this is "fixed", what can we as a user community do to help mitigate the annoyances caused by this bug? Would it be sufficient to describe the issue and various workarounds in the relevant places in the community documentation? Maybe here...

https://help.ubuntu.com/community/Fstab

https://help.ubuntu.com/community/SettingUpSamba

Maybe a Known Issues section should be added.

@complainers:

Complaining about Ubuntu's bug-fixing process won't get this bug fixed any
quicker. It just fills people's inboxes with useless drivel. Let's keep the
discussion on-topic, shall we?

Let the inboxes be filled until it is committed!

One thing I only just figured out: if you are using the umountcifs script linked above, you also need to set the network as a system setting, otherwise it's pulled down when you exit KDE/Gnome and still leaves the umount hanging during shutdown/reboot.
I made sure network-manager-gnome was installed, logged out of KDE, choose GNOME from the log in menu, and used GNOME's network manager to set the connection property.
Note there is a bug in *that* program, so you have to make sure both 'automatic connect' and 'system setting' are unticked, then tick 'system' then 'automatic'.

This is disheartening to see that this bug has been around this long and nothing has happened. I have been dealing with it for a while and finally stumbled across it. I found a fix once before that I can't even remember now and I can at least suspend only to find that when I wake my laptop up on another network the shares are still mounted and any suspend after that fails. I have taken to mounting and unmounting shares manually before and after every suspend and its becoming annoying.

I love to tell people about the greatness of Ubuntu and many people want to try it when they take a spin on my laptop. But issues like these are show stoppers for people that just want to switch to something with a solid and easy experience. I sincerely hope that these issues will be fixed in the next release. But from the looks of this thread sadly I don't believe they will. I will attempt the fix listed here but I really question suggesting Ubuntu to someone and then trying to have them apply this these fixes themselves. This gives credence to people that call desktop Linux nothing more than a hobby.

James (james-ellis-gmail) wrote :

This bug is causing usplash to crap-out on shutdown and display a nice screen of vertical coloured lines, as reported in this bug:
https://bugs.launchpad.net/ubuntu/+source/usplash/+bug/301628

usplash shows the coloured lines at exactly the same time as the CIFS error messages are shown in shutdown.

Taking splash out of the kernel boot line in the grub list file removes the graphical element of shutdown/startup and causes the CIFS error line to appear (rather than being hidden by usplash) - It doesn't fix this bug but at least the risk of damage to my screen is reduced.

Thierry Carrez (ttx) wrote :

Quick status update/summary on this bug, because this thread is long and tends to discourage people that could solve it.

The bug occurs on shutdown if you mount a CIFS share (using mount or /etc/fstab). In some cases, S31umountnfs.sh tries to unmount the network file system *after* the network has been brought down. CIFS doesn't handle so well having the network pulled out from under it, so it stalls the shutdown process for some time, but the shutdown finally succeeds.

The most common case appears to be those using NetworkManager to handle the network interface (NetworkManager gets killed by S20sendsigs, before S31umountnfs.sh). If you are not using NetworkManager at all (and have your network defined in /etc/network/interfaces), the unmount will succeed. That's why this bug doesn't really affect Ubuntu Server systems. Also I would argue that you should not mount things system-wide while having your network up/down at Gnome session start (think wireless). Nautilus-based mounts seem like a better idea in that case.

It's *not* simple to fix. There are lots of workarounds which will solve the problem for your use case, but which will also break it for other folks. The fact that workaround X solves the issue for you doesn't make it a proper update that can be applied to all other Ubuntu systems. Cutting the network filesystem before S20sendsigs for example may result in data corruption, which is arguably worse than an annoying delay at shutdown.

The best way of solving this is to have CIFS (probably in kernel) better support having the network pulled out from under it. I haven't really found how we could do that, but I'll try to invite some CIFS specialists here. Another way could be to exclude NetworkManager from S20sendsigs and kill it properly at ~S35... constructive, technical comments welcome.

It's true that the way Launchpad works doesn't help us in solving this kind of in-between-packages bugs (and most distributions won't be better than us). But bitching about it just makes developers turn to easier (and more rewarding) bugs to fix.

Thierry Carrez (ttx) wrote :

smfrench:
Could you have a look at the CIFS timeout part ? Do you think it's possible to have CIFS more gracefully handle the case where the network is being pulled out from under it ? I can reproduce the issue with the current jaunty kernel, so this wasn't "fixed" as of the 2.6.28 we use. Or maybe it's in the userspace side ?

See https://bugs.launchpad.net/ubuntu/+source/samba/+bug/211631/comments/76 for a summary of this (long) bug. Thanks in advance ;)

Thierry Carrez (ttx) wrote :

OK, I uploaded a network-manager upgrade for intrepid to my PPA:
https://launchpad.net/~ttx/+archive/ppa

This release (built on the latest network-manager in intrepid-proposed) basically prevents network-manager from being shut down by sendsigs... From my testing this solves the CIFS hanging during umountnfs, and also ensures the network filesystems are still available when the processes are stopped by sendsigs (allowing them to shutdown without data loss). It was inspired by Daniel J Blueman proposed patch on (related) bug 113095.

Could you please test if it solves the issue for your specific case, and tell me about any side-effects.

I have the same problem, but I had never used Network Manager. I always use WICD.

Thierry Carrez (ttx) wrote :

Just refreshed my PPA (a security update superseded it), please test:
0.7~~svn20081018t105859-0ubuntu1.8.10.3~ppa1

@Max-Ulrich Farber:
I guess WICD has the same bug as NetworkManager (gets killed by sendsigs before the network filesystems are unmounted). If testing shows that the solution for NM is right, we'll push the same kind of fix to WICD.

Steve Grecni (gid-gifpaste) wrote :

Thierry, I just installed your ppa network-manager packages on Intrepid, and it's still hanging on shutdown (using wireless) with CIFS VFS errors. A fairly fresh UMPC install on a Dell Mini 9.

I ran a continuous ping on the machine and network is unavailable nearly immediately after selecting shutdown from the gnome menu, after a bit I can then see the shutdown splash and a bit later I'm geting the CIFS VFS errors.

Interestingly enough, even when I remove quiet and splash from the grub menu.lst, it's still not showing any shutdown messages to me, just the CIFS VFS errors and sometimes an apcid error. So it's impossible for me to tell the network manager is dying too soon.

Thierry Carrez wrote:
> OK, I uploaded a network-manager upgrade for intrepid to my PPA:
> https://launchpad.net/~ttx/+archive/ppa
>
> This release (built on the latest network-manager in intrepid-proposed)
> basically prevents network-manager from being shut down by sendsigs...
>>From my testing this solves the CIFS hanging during umountnfs, and also
> ensures the network filesystems are still available when the processes
> are stopped by sendsigs (allowing them to shutdown without data loss).
> It was inspired by Daniel J Blueman proposed patch on (related) bug
> 113095.
>
> Could you please test if it solves the issue for your specific case, and
> tell me about any side-effects.

Hi Thierry,

I'm on jaunty, I've tried the package but I still have the same problem.
On my jaunty install the problem is even worse, it doesn't get past the
unmounts or perhaps it just takes extremely long, I have to
hard-shutdown my laptop every time I shut down and forget to unmount
these file systems first.

In my opinion this is really a kernel problem, and a big one. If there
is no route to the host (which is the case if the network is down), the
cifs vfs should properly detect this and not wait for some timeout. And
it *can* easily detect this: when the network is down and I do a ping, I
also get "no route to host". I don't see any reason why the cifs vfs
shouldn't be able to detect this as well.

Also, your current attempt at a solution will only solve the problem
when the network is still up. But what if I shut down while my wireless
network is gone? For instance, when I've moved away from my home
location with the laptop on or (probably) suspended? Or what if my
wireless network simply shuts down by itself? It tends to do that. :-)

I really hope that somebody will find time to look at a proper, kernel
based solution.

Cheers,
Bart

Bart Samwel (bart-samwel) wrote :

Hi Steve,

Steve Grecni wrote:
> Thierry, I just installed your ppa network-manager packages on Intrepid,
> and it's still hanging on shutdown (using wireless) with CIFS VFS
> errors. A fairly fresh UMPC install on a Dell Mini 9.
>
> I ran a continuous ping on the machine and network is unavailable nearly
> immediately after selecting shutdown from the gnome menu, after a bit I
> can then see the shutdown splash and a bit later I'm geting the CIFS VFS
> errors.
>
> Interestingly enough, even when I remove quiet and splash from the grub
> menu.lst, it's still not showing any shutdown messages to me, just the
> CIFS VFS errors and sometimes an apcid error. So it's impossible for me
> to tell the network manager is dying too soon.

 In that case it seems that the only reason for the existence of the
NetworkManager daemon is to perform the required privileged operations
at the biddingI don't know *exactly* how NetworkManager works, but I'm
under the impression that it only holds a network connection while the
applet is running, i.e., while the user is logged in. This could be a
security thing, because it gets the network settings from the user's
settings, and also the authentication to a wireless network are taken
from the logged on user's key ring. So it's actually quite logical that
it would shut down the network at logoff, BEFORE any of the shutdown
scripts run. (In that case it seems that the NetworkManager daemon is
only there to do the required privileged work at the bidding of the
nm-applet. And if the nm-applet disconnects due to logoff, then it
disconnects...)

Anyway, this is all just conjecture. I might have it all backwards.

Cheers,
Bart

A couple clarifications:
1) We really want the network file systems to be unmounted (or at least synced) before the network goes away. You do not want to risk losing file system data which has been cached by the Linux memory management layer.

2) If there is cached write data, we do want the file system to try as hard as reasonably possible (perhaps forever in the case of mounting with the "hard" mount option rather than the default "soft" mount) before giving up - the network which is down for a few seconds, may recover in most cases (where exactly we are in shutdown of the system may be hard to detect in this path in the kernel)

3) CIFS already does do the obvious - it does not attempt to send network requests in umount (SMB "tree disconnect" followed by SMB "ulogoff") if the session is already dead (the server implicitly closes "tids" and "smb uids" when the socket crashes). Write requests just prior to the umount getting to the kernel would cause attempts at reconnect, but simply from the kernel cifs driver perspective umounting should not cause network traffic if the session is already dead
e.g. see this code excerpt from CIFSSMBTDis
 /*
  * No need to return error on this operation if tid invalidated and
  * closed on server already e.g. due to tcp session crashing. Also,
  * the tcon is no longer on the list, so no need to take lock before
  * checking this.
  */
 if (tcon->need_reconnect)
  return 0;

and similarly in CIFSSMBLogoff:
 if (ses->need_reconnect)
  goto session_already_dead; /* no need to send SMBlogoff if uid
           already closed due to reconnect */

Hi Steve,

Steve French wrote:
> A couple clarifications:
>
> 1) We really want the network file systems
> to be unmounted (or at least synced) before the network goes away.
> You do not want to risk losing file system data which has been cached
> by the Linux memory management layer.
>
> 2) If there is cached write data, we do want the file system to try
> as hard as reasonably possible (perhaps forever in the case of
> mounting with the "hard" mount option rather than the default "soft"
> mount) before giving up - the network which is down for a few
> seconds, may recover in most cases (where exactly we are in shutdown
> of the system may be hard to detect in this path in the kernel)

> 3) CIFS already does do the obvious - it does not attempt to send
> network requests in umount (SMB "tree disconnect" followed by SMB
> "ulogoff") if the session is already dead (the server implicitly
> closes "tids" and "smb uids" when the socket crashes). Write
> requests just prior to the umount getting to the kernel would cause
> attempts at reconnect, but simply from the kernel cifs driver
> perspective umounting should not cause network traffic if the session
> is already dead

I think there must be a bug somewhere in this code then. My cifs file
systems are all as read only as a read-write file system can be: I
almost never write to them, I just mount them by default so that I can
read from them (which I also almost never do), and also write to them
when I want, which is also not a daily thing. So I almost always shut
down in a situation where the file system has only been read from, not
written to -- and the reads are usually also a long time ago. No reason
at all to wait indefinitely!

For reference, all my cifs file systems are mounted below /nas/..., and
the following command:

# lsof | grep nas

shows nothing. No files open on the shares, and it's like that for most
of the time. Still, my system hangs at shutdown. There's *something*
fishy going on here. Do you know of any other commands I should try to
figure out if there is some dirty data left for the cifs file systems,
that somehow doesn't get written? Would it help to sync before I reboot
from the GUI, so that all pending dirty data is flushed to the cifs fs?

Cheers,
Bart

Bart Samwel (bart-samwel) wrote :

Bart Samwel wrote:
> Would it help to sync before I reboot
> from the GUI, so that all pending dirty data is flushed to the cifs fs?

For the record: nope, that doesn't help. Still hangs.

Things get even weirder, if I select logout from the gnome panel, network goes away, so I log back in as the same user, and network comes back as expected. But if I log out again, network stays up! Tried logging out again, network still stays up.

I noticed, if I log out, and then back in, then after shutting down, I see the shutdown messages, I see my cifs mounts getting unmounted properly (no CIFS VFS errors) and then then the networking interfaces get deconfigured. Shutdown happens properly

It seems at least for me, something is causing the network-manager to die the first time I log out, but then after that, it stays up between log outs. Can anyone confirm? Could this be some weird issue where the network-manager is not properly detaching from the controlling terminal or something of the sorts?

So basically something is causing my network-manager to die and not show me shutdown messages if I don't log out and log back in first before shutting down... Am I the only one seeing this behavior?

Thierry Carrez (ttx) wrote :

I think I also need to clarify something here.

If you use NetworkManager with per-user settings (i.e. without the "system setting" checkbox checked) then the network connection is up only during your session. When you log out from your Gnome session, the network connection goes down. This is the default for desktops, and usually the case for wireless connections where the password is stored in the user keyring.

So the whole concept of mounting any network filesystem system-wide at boot (in /etc/fstab) while your network will only be there during your Gnome session is flawed.

Here are the sane modes of operation:
(1) Not using NetworkManager, define a static network configuration in /etc/network/interfaces
Then you can use /etc/fstab without any problem, shutdown will work without a timeout. This is usually used on servers.

(2) Using NetworkManager in "system setting" mode
Then you should be able to use /etc/fstab without a problem. At this point there is a bug in NetworkManager that makes it die before umountnfs is called. The version in my PPA solves this. Please test.

(3) Using NetworkManager without "system setting" checked (per-session mode)
Then you shouldn't be using /etc/fstab at all. The network will go down when the Gnome session stops. True network filesystem mounts require the network to be up regardless of the Gnome session status. You should use nautilus mounts instead (smb://server/share). Those will be unmounted before Gnome logout.

I am trying to solve the bug in the (2) case here.
If you are in the (3) case (and a lot of you probably are) you should either switch to "system setting" mode or drop usage of CIFS mounts in favor of Nautilus gvfs-smb mounts.

toobuntu (toobuntu) wrote :

@Thierry Carrez:

For use case #3, isn't that what the '_netdev' mount option is for? In my fstab, I always use '_netdev' for a network share; I think RedHat considers it a best practice. One could also combine that with 'noauto' and 'user'. The problem with gvfs-smb mounts is that non-gvfs aware apps would not have access to the network filesystem.

In my setup, I also use gid=100 to mount network filesystems for all users (gid=100). I do have the timeout issue on runlevels 0 and 6, of course.

Steve Grecni (gid-gifpaste) wrote :

Thanks for the clarification Thierry. Unfortunately I cannot use it wireless as a system wide setting due to bug #288963 which doesn't have an intrepid backport. Seems when tracking down the cause of one bug, I encounter 3 more to that need to be fixed in order to solve it. :) Maybe I should just upgrade to jaunty and be done with it, but I fear that's a whole new bag of worms...

Steve French (smfrench) wrote :

OK ... doing a little more investigation it gets interesting to see what crazy things gnome does (you can also try clearing the dmesg log and then doing "echo 7 > /proc/fs/cifs/cifsFYI" before you logoff/umount and see what cifs operations are in dmesg)

What I see is that the slow operations are repeated calls (presumably by gnome) to querypathinfo (stat) on ".Trash-1000" ... see below
 fs/cifs/inode.c: Getting info on //localhost/stevef/.Trash-1000
 fs/cifs/cifssmb.c: In QPathInfo (Unix) the path //localhost/stevef/.Trash-1000

cifs has no way of knowing that this is useless and that we should ignore gnome's request

In addition, running with umount.cifs (/sbin/umount.cifs is not needed in most cases unless you are doing user mounts/umount) you get a call to "statfs" (umount.cifs has to verify that this is a cifs mount and AFAIK there is no cheap way to do this in Ubuntu - and so we are stuck calling statfs to check the fs "type" field to make sure that we are in fact unmount a cifs file system - but statfs also unfortunately returns other information that requires sending a request over the network ... it would be very helpful if there were a way to query ... just ... the file system's type and not the other dynamic information that requires going to the server). If you move umount.cifs out of sbin that should help, but the big problem seems to be the desktop querying for things it doesn't need to be doing during umount

Steve French (smfrench) wrote :

running without umount.cifs (which is not needed unless you are doing user mounts), the unmount finishes quickly, and with no visible errors (the tree disconnection request times out fairly fast, and the rest of umount proceeds fast after that)

Steve French (smfrench) wrote :

The easiest way to test this is to always do "umount -i <mnt-point>" rather than "umount <mnt-point>" unless you are doing an umount as a regular user of a user mount (-i prevents the unneeded helper program from being called)

Hi Thierry,

Thierry Carrez wrote:
> I am trying to solve the bug in the (2) case here. If you are in the
> (3) case (and a lot of you probably are) you should either switch to
> "system setting" mode or drop usage of CIFS mounts in favor of
> Nautilus gvfs-smb mounts.

Thanks very much for the detailed explanation. I switched to "system
setting" mode and this did solve the problem for me. This option is very
well hidden however, so this is probably one of the reasons why there
are many users who use fstab in combination with per-user network
settings. (The gvfs option is not suitable for me BTW because I access
the mounts mostly from scripts. And also from KDE programs -- I'm not
sure those can access gvfs. :-) )

I do still think that there is something fishy going on with the long
timeouts while I have nothing open on the network fs.

I admit that I'm applying the same kind of logic that people do actually
use for things like thumb drives -- if you don't write to them (or
haven't written to them in a while) then you can remove them without
thinking. It's not *technically* correct, but it's only not technically
correct because the system works that way. And then we are typically
trying to make the users behave in a certain way to match the behaviour
of the system, instead of making sure the system behaves as the users
quite reasonably expect it to. :-) Personally I think that it would be
very much in line with Ubuntu's "human" philosophy to try and make the
system behave as humans expect it to, which in this case is that if they
haven't written anything to the fs, then there's no reason to wait for
the server. Steve's analysis might give some pointers to WTF is going on
here...

Cheers,
Bart

Thierry, please extend your approach to not kill wpasupplicant on shutdown either. i think thats the problem that is left with your ppa packages here as the ones reporting that your ppa package doesnt help are using wireless.

Once you have that please request a merge for the 0.7.1 branch and if you want also for the 0.7 branch in intrepid and I will take care that this gets into jaunty and after some baking to intrepid.

description: updated
Thierry Carrez (ttx) wrote :

@toobuntu:
The _netdev option tells the system (if it doesn't already knows it from the fstype) that the filesystem should be considered mounted on network (and therefore be unmounted in umountnfs.sh rather than umountfs).

@Steve Greci ("Seems when tracking down the cause of one bug, I encounter 3 more to that need to be fixed in order to solve it."):
I understand the feeling. That's part of why I said this bug is not so easy to fix. Looks like your bug is solved in Jaunty though... so let's try if we can completely fix it for that release :)

@Steve French:
Yes, there seems to be a major inconsistency between the way Gnome handles files on network mounts vs. how NetworkManager handles the network. Thanks for your analysis :) To mitigate the effects I agree we should hack umountnfs.sh so that it always uses "umount -i". Since that script is always run as root I suppose there wouldn't be any wrong side-effects ?

@Bart:
I agree that the different "network modes" are poorly documented (and checkbox behavior in n-m-applet to switch between them used to be very buggy). I am still not sure I got them right. I guess Alexander could confirm if what I said in comment 88 is indeed how it works.

@Alexander:
I think most of the users with wireless reporting failure are in use case (3) described in comment 88, since it's the default N-M mode of operation. However I agree wpasupplicant needs to be fixed as well, for the case where you would run on wireless with a system connection (is that even possible ?). Looking at wpa-ifdown though, it appears it already has some support for sendsigs omission (at least in Jaunty), so that might not be needed. I need more time on this.

Thierry Carrez (ttx) wrote :

Filed bug 341084 to discuss usage of "umount -i" rather than "umount" in umountnfs.sh. Please followup there.

Updating other status: Nothing to fix in samba or dhcdbd, something to fix in network-manager, and maybe something to fix in wpasupplicant.

Changed in sysvinit:
status: New → Invalid
Changed in samba:
status: Confirmed → Invalid
Changed in network-manager:
status: Incomplete → Confirmed
Changed in dhcdbd:
status: New → Invalid
Changed in wpasupplicant:
status: Confirmed → New
Thierry Carrez (ttx) wrote :

There is *some* sendsigs omission support in wpasupplicant, but apparently not enough. It still should write something to /lib/init/rw/sendsigs.omit.d...

Changed in wpasupplicant:
status: New → Confirmed
Ryan Sinn (ryan-sinn) wrote :

I am still having the issue with the latest Jaunty Beta 9.04 64-bit Desktop install.

This would seem to me to be a moderate usability due to the fact it can take upwards of 5-10 minutes to shutdown depending on the system.

In 8.10 the system would never shut down for me. Now it seems to shutdown after idling at the CIFS error for upwards of 5 minutes.

I currently have 5 SMB shares I manually mount as my user once I log in. I typically would mount them in the FSTAB, but I haven't gotten around to it yet since I installed the fresh copy of Jaunty Beta this weekend.

Thierry Carrez (ttx) wrote :

Status update

This problem is well-identified, it will affect Jaunty, there is no need to confirm it or add to this already-long thread. Please just use the "This bug affects me" link at the top instead.

This issue comes from the shutdown sequence that is not supporting a use case of mounted network filesystems combined with a Networkmanager-defined networking. It's difficult to solve for everyone because most "solutions" are breaking other perfectly valid use cases. Solutions for the next release cycle will be discussed by the Foundations team.

If you are affected by this bug, workarounds include:
- Do not use system-wide CIFS mounts but use Gnome VFS pseudomounts like typing smb://foo/bar in nautilus
- define your network in /etc/network/interfaces rather than in NetworkManager
- hacking the shutdown sequence to make it unmount network filesystems earlier (for example moving S31umountnfs.sh to S14umountnfs.sh in /etc/rc[06].d) : will fix it if you aren't executing anything on those network filesystems

Thanks for this status update.

As Thuerry Carrez proposed, I tried to avoid system wide CIFS mounts via fstab by monting my cifs shares manually with "mount.cifs ..." in my home folder. The shutdown problem is still the same.

Using GNOME vfs pseudomounts is not a solution for me because the cifs UNIX extensions would not work.

Het Irv (hetirv) wrote :

Add this to the One Hundred Paper Cuts Project to allow for more visibility. I know that this may not fit the "easy to fix" part of the projects description, but it does negatively affect the user experience. I am hoping that Karmic will have a solution.

Please don't add bugs to hundredpapercuts when you know the bug is not a paper cut!

Changed in hundredpapercuts:
status: New → Invalid
Harry (harry2o) wrote :

I am facing this issue on intrepid and jaunty using wired connection (with NM in system mode).
Even before reading this thread I went through moving S31umountnfs.sh up in the rc0/6 scripts in order to find the critical tip. For me this was S20sendsigs (as described by Thierry), i.e. S19umountnfs.sh solved it, S21umountnfs.sh broke it (so there was no need to put it before S15wpa-ifupdown). Ppl using wireless should check this for S15wpa-ifupdown, as well.

This still occurs in the 9.10 beta. In fact, the upgrade has disabled the fix I'd put in, based on this bug, under 9.04.

As it's such a simple fix, lets do this for 9.10 final shall we ?

Hi Tom

I installed Karmic Beta the other day and no longer get this error (with the entries in the /etc/fstab as I originally described).

Hamish

Alexander Sack (asac) wrote :

NM 0.8 does not bring down ethernet connections on exit anymore. I don't think we will be able to something similar for wifi soon. Is that good enough for this bug?

Changed in sysvinit (Debian):
status: Unknown → New

The moving/copying of the rc0/6 scripts doesn't seem to work in Karmic RC (using wireless). I just get a hang on shutdown with the message "init: usplash post-start process (2446) terminated with status 1" and never seems to shut down. If I put the scripts back the way they're supposed to be, then I simply get the usual CIFS VFS errors.

I can confirm that this bug is fixed for wired network users. However, I can no longer get any previously expounded solution to work when using wireless. Any workaround would be a godsend to me.

Neil Broadley (scaine) wrote :

Confirmed here too. I've tried all the solutions listed previously to resolve this issue in Karmic and Wireless, but I always experience a hang on shutdown. The only "workaround" (not really) I've found so far is to add the "users" option to my /etc/fstab entry for my cifs share, then manually unmount the volume before shutting down / restarting the laptop.

Although the umountcifs script still works when run manually, I've tried linking to just about every position in /etc/rc0.d (and /etc/rc6.d) with no success. A linked thread here also suggests putting umountcifs in /etc/gdm/Postsession/default - all that seems to do is break the exit usplash (or whatever that's called now - the ubunut logo thing that fades away) - but the hang persists.

Is there perhaps some kind of upstart configuration that needs to be modfied in Karmic to emulate the K0umountcifs behaviour?

James (james-ellis-gmail) wrote :

"NM 0.8 does not bring down ethernet connections on exit anymore. I don't think we will be able to something similar for wifi soon. Is that good enough for this bug?"

No. I have a use case of wanting to pack up my laptop up quickly after using wireless at a client's office where I have to mount a remote Windows filesystem using Samba. Having your laptop not suspend or shutdown (or do it such a bad way it's not funny) isn't very good for my system or for desktop linux (picture a Windows using client interested in desktop linux and watching a laptop doing this shutdown dance).

What's the reason for not being able to keep wireless up until after network filesystems are unmounted ?

Thierry Carrez (ttx) wrote :

> I have a use case of wanting to pack up my laptop up quickly after using wireless
> at a client's office where I have to mount a remote Windows filesystem using Samba.

Any reason why you don't use nautilus-based mounts (typing smb:// ... in Nautilus) ? fstab-based network filesystem mounts and wireless/suspend don't work that well together.

Hi Thierry

There are lots of reasons why we don't use gvfs mounts.

I am using a NAS and want the mounts to be there automatically on login. With gvfs mounts I have to go in an "activate" them each time.

I use an rsync script for backing up from my NAS to an external hard disk drive and want to have defined mount points for that to work.

There's no easy way to mount the smb shares from my NAS to a point that I want on my filesystem, without using fstab entries.

Hamish

An other important reason is that gvfs does not support "cifs UNIX Extensions" yet.

Vish (vish) on 2009-10-29
affects: hundredpapercuts → null
Alexis de Lattre (alexis-via) wrote :

I don't get the message "CIFS VFS server not responding" on shutdown any more on the Ubuntu PCs that I have upgraded to Karmic (and which have cifs lines in /etc/fstab). So the bug is fixed ?

H3g3m0n (h3g3m0n) wrote :

@sixela: It still happens on wifi system

@Thierry Carrez
I can't use the gvfs because I'm not using Gnome on my system.
Something lite on a netbook makes much more sense but I don't want an overly simplified interface like you get with most netbook interfaces, so I'm using Fluxbox with a bunch of key binds to launch terminals quickly and so on.

You also loose the command line with gvfs.

James (james-ellis-gmail) wrote :

Ditto, gvfs is Gnome-centric and this is an underlying system issue.

The network:/ and smb: protocol in KDEs Dolphin works well enough but for instance, Amarok doesn't allow music collections to be used via smb:/ but does handle Samba mounts via mount.cifs. fusesmb also doesn't do much as it dies when Amarok tries to scan music on the fuse mountpoint.

In KDE, I found a workaround is to create a shell script that unmounts the mount point that has been mounted with mount.cifs
e.g

-------
#!/bin/bash
umount.cifs /path/to/media
-------

* Make it executable by your user and put in it your home directory (or whereever you like)
* Choose System Settings > Advanced > AutoStart
* Choose Add Script and select the script. In "Run On" select "Shutdown".

When you log out of KDE now, the mount point will be unmounted. The opposite can be done on log in by mounting on Startup -- using a shell script calling mount.cifs with the required options instead.

It works for me and my laptop properly shuts down now. Doesn't fix the underlying bug though.

Which brings up another question - would it be possible for NetworkManager to bring up & down configured mount points as part of it's configuration/settings ? That way, it unmounts just before bringing the network down and mounts the filesystems after bring the network up ? A simple checkbox would suffice e.g "Control Network Shares"

Neil Broadley (scaine) wrote :

@James : That would be awesome and exactly what I'll propose to the networkmanager list (when I get round to it).

@Sixela : As H3g3m0n notes, the bug is still apparent on WIFI systems.

In general, worth noting another reason gvfs shares don't always work out - nautilus won't process thumbnails for "remote" filesystems by default and it considers gvfs mounts as remote (fair enough). Meanwhile, fstab filesystems aren't considered remote. It's not feasible in my case to turn on previewing in all remote systems, since if I use my laptop at work, it'll connect to systems where a preview of the files would not be desirable (too slow).

spaetz (spaetz) wrote :

re #100:
> - hacking the shutdown sequence to make it unmount network filesystems earlier (for example moving S31umountnfs.sh to S14umountnfs.sh in /etc/rc[06].d) : will fix it if you aren't executing anything on those network filesystems

This is not safe, as at S14 applications might still have open files on those mounts. It is way better to have:
 S20sendsigs
 S25umountnfs
 S26wpa-ifupdown

in order to first close application, then unmount filesystems and then kill networkmanager. Sorry for the additional noise in this bug, but I have not seen this better fix mentioned before.

Neil Broadley (scaine) wrote :

Hi Spaetz. That "fix" was documented as early as comment 7 and is discussed thoroughly throughout the 110 or so comments. Sadly, the fix doesn't work in Karmic any more. Well, I'll qualify that - it works for wired connections, but not for WIFI. Network Manager brings WIFI connections down internally on a shutdown signal BEFORE any startup/shutdown script is run.

I recommend anyone still affected by this bug to use autofs to mount their CIFS and NFS shares. Autofs gracefully kills the connection on an interface disconnection without triggering the dreaded "CIFS VFS server not responding" message and subsequent 90 second delay.

I *think* that this bug is only apparent now if :
a) You're mounting remote NFS/CIFS shares by specifying them in /etc/fstab AND
b) You're using WIFI to connect to said shares and you forget to disconnect/unmount the shares before shutting down.

Correct me if I'm wrong. I'm not sure if there's a way to update the bug to reflect this?

Brad Krause (brad-krause) wrote :

It's unfortunate that people have to write custom scripts to unmount CIFS shares, especially since .bash_logout doesn't seem to run in Ubuntu 9.10 for super-users. I fixed the problems by creating my own self-healing wireless scripts to replace Network Manager and (as related to the mounts, and it is not an ideal solution, because /etc/gdm/PostSession/Default isn't run on shutdown and the system will still hang if Network Manager is used):

For each user:
cd ~
mkdir network
cd network
mkdir archive p-$LOGNAME w-$LOGNAME
echo username=$LOGNAME >> p-$LOGNAME.pwd
chmod 600 p-$LOGNAME.pwd
echo password=somepasswd >> p-$LOGNAME.pwd
cp p-$LOGNAME.pwd w-$LOGNAME.pwd archive.pwd

exo-desktop-item-edit --create-new --type Application --name "User Directory Mount" --icon shares --command '/usr/local/bin/usr_mount' ~/.config/autostart/
  (Note: This is run instead of /etc/gdm/PostLogin/Default because that file runs as 'root' and not under the user account, so the mounts would not happen.)

mousepad ~/.gtk-bookmarks (replace $LOGNAME with the user's actual name)
    Add first line: file:///home/$LOGNAME/network/p-$LOGNAME (this causes Places to use p-username)

sudo su root
echo >> /etc/fstab
echo //192.168.0.1/p-newUserName /home/newUserName/network/p-newUserName cifs noauto,nodfs,user,rw,credentials=/home/newUserName/network/p-newUserName.pwd 0 0 >> /etc/fstab
(repeat 2nd line for each share)

The following is done once:

Add to /etc/gdm/PostSession/Default (because .bash_logout isn't run for a sudo-admin account):
# Unmount local volumes.
/usr/local/bin/usr_unmount

/usr/local/bin/usr_mount
for d in `find ~/network -mindepth 1 -maxdepth 1 -type d`
do
  case "${0##*/}" in
  usr_mount)
    echo "Mounting $d ..."
    mount $d
  ;;
  usr_unmount)
    echo "Unmounting $d ..."
    umount $d
  ;;
  *)
    echo "Unknown option: ${0##*/}"
  ;;
  esac
done

ln -s /usr/local/bin/usr_mount /usr/local/bin/usr_unmount

flaccid (chris-xhost) wrote :

Advice: stop wasting time on ubuntu bugs. Nothing is done about them. I moved away from Ubuntu years ago because of this fact and every now and then major bugs like this are updated with a new comment and nothing is ever done. If you want politics and bugs, use ubuntu; if not move to a distro that does something about bug reports.

Initial report on this bug: 2008-04-04. Wont' be long before that is 2 years and 4 ubuntu releases since initial report. Canonical ... start sponsoring bugs and fix your distro!!

James (james-ellis-gmail) wrote :

I think comment #121 workaround will only work if you are using GDM, this bug affects KDE and other desktop environment users as well.

Comment #120 states
I *think* that this bug is only apparent now if :
a) You're mounting remote NFS/CIFS shares by specifying them in /etc/fstab AND
b) You're using WIFI to connect to said shares and you forget to disconnect/unmount the shares before shutting down.

But I should add an option - which is how the bug is apparent to me
* You're mounting CIFS shares using mount.cifs, using WIFI to connect with the shares and the shares are not being unmounted before shutdown. In that case I get the dreaded wait before shutdown and a screenful of nice coloured vertical lines.

Yep, nearly two years on this one. Maybe Ubuntu should bake a cake and have a party on the 4th of April.

David Tombs (dgtombs) wrote :

It seems NetworkManager 0.8 fixed this issue for those on wired connections, so I'm marking as fix released for n-m.

Wireless connections apparently still broken.

Changed in network-manager (Ubuntu):
status: Confirmed → Fix Released
Steve Langasek (vorlon) wrote :

Since management of wireless network connections is a principal use case of NM, this is not fixed.

Changed in network-manager (Ubuntu):
status: Fix Released → Confirmed

Not fixed for wireless network with WICD too !

Still busted in Ubuntu 10.4, which is meant to be a super stable LTS release :-/
You can not be serious that this is 'fixed' when it's only fixed for users on wired connections, more and more people are using wireless in general.

Brad Krause (brad-krause) wrote :

Agree with Tom in full.

Steve Langasek (vorlon) wrote :

The bug is not marked as fixed.

Nor, as you previously claimed, is it "such a simple fix". So far we don't have any model for getting this working reliably.

varanasi (mark-hugheshome) wrote :

I agree with Tom's overall point. This is a serious usability problem for people where I work. We use a script as a partial workaround but it's impossible to make the script work everywhere. This really should be fixed before the LTS.

I absolutely do agree with Tom and varanasi. This is a serious usability problem that should be fixed as soon as possible!

Changed in network-manager:
status: New → Confirmed
status: Confirmed → New

I had already mentioned above: It's not only a network-manager problem because it is exactly the same with WICD.

Fabio Albieri (chareos) wrote :

Same problem in Kubuntu 10.4
(which means KDE 4.4.2 and it's network manager)

Jan Lillelund (jan-lillelund) wrote :

This is still a big issue on WiFi-enabled workstations. To put it into perspective, we have upgraded from 8.04 LTS to 10.04 LTS and shutdown still takes around 40 minutes for the 16 cifs mounts in FSTAB on four workstations. Users are seriously inconvenienced.

As hinted earlier, a workaround could be adding the K14-links to rc0.d and rc6.d:

ln -s /etc/init.d/umountnfs.sh /etc/rc0.d/K14umountnfs.sh
ln -s /etc/init.d/umountnfs.sh /etc/rc6.d/K14umountnfs.sh

and deleting the equivalent S31umountnfs.sh link.

I see this as a stop-gap measure only until it has been fully tested and verified.

However, as Max-Ulrich Farber also stated more than two years ago, the full ramifications of this are not clear as I do not have the test cases nor insight for that matter to determine that this does not adversely affect something else.

Could someone please please take a look at this and have the issue resolved. This is not just an obscure technical issue but also affects the image that ordinary mortal users have of Ubuntu.

Fabio Albieri (chareos) wrote :

God, even Ubuntu 10.10 still suffer from this bug 2 years later...

Robbie Williamson (robbiew) wrote :

@Fabio: Do you know if this is fixed in another Linux Distro? If so, please tell us so we can see how they've addressed this problem.

@Robbie Williamson: Yes other distros have solved this. Like Arch. I switched my laptop to arch for that very reason.

With Arch, I first have my shares that I want connected in fstab. The Ubuntu documentation is ample on the subject.

Secondly, in Arch, netfs daemon is used to control connections to network shares. To avoid any problem, netfs can be managed by a script in /etc/NetworkManager/dispatcher.d/ which both starts and stops netfs according to the state of the connection. As follows:

#!/bin/sh

IF=$1 # The interface which is brought up or down
STATUS=$2 # The new state of the interface

case "$STATUS" in
    'up') # $IF is up
 exec /etc/rc.d/netfs start
 ;;
    'down') # $IF is down
 exec /etc/rc.d/netfs stop
 ;;
esac

With such a setup, the shares are connected if there is a connection to the network and taken down with the connection. It is no longer a question of "timing" what comes first or second. Why Ubuntu couldn't carry such a solution is beyond me. This problem brought me to switch my laptop to Arch as no good solution was out there for Ubuntu. It's time developers looked at what others are doing or Ubuntu will loose more users on this issue.

Umang Varma (umang) wrote :

Here's some info, if it helps:

Neither of the solutions on https://help.ubuntu.com/community/MountWindowsSharesPermanently#System%20Hangs%20on%20Shutdown or https://wiki.ubuntu.com/MountWindowsSharesPermanently#Fixing%20a%20CIFS%20bug%20with%20network%20manager worked for me (after one or two quick shutdowns, it was back to taking a minute to shutdown) However if I unmount my network drive before shutting down, my computer does in fact shut down almost instantly, as opposed to the one minute it takes if I don't.

Glen Robinson (glentrobfc) wrote :

This bug is present in 11.04. CIFS mounted with wifi network connection hangs forever on shutdown. Wired shuts down fine. For what it is worth, liinux mint 10 gnome on the same machine, same network identical CIFS mount in /etc/fstab does NOT exhibit the failure. Mint is using a symbolic link from umountnfs to K15umountnfs, while 11.04 has it linked to S43umountnfs.

Changed in dhcdbd (Ubuntu Lucid):
status: New → Invalid
Changed in dhcdbd (Ubuntu Natty):
status: New → Invalid
flaccid (chris-xhost) wrote :

@Clint Byrum
How about we fix the bug for the next release instead of marking it as invalid?

flaccid (chris-xhost) wrote :

Bug was rasied on 2008-04-04 and has 14 duplicates, yet this is somehow invalid?
I don't even use Ubuntu anymore because of silly issues like this.
What do we need to do to get action on this?

Excerpts from flaccid's message of Mon May 23 06:27:57 UTC 2011:
> Bug was rasied on 2008-04-04 and has 14 duplicates, yet this is somehow invalid?
> I don't even use Ubuntu anymore because of silly issues like this.
> What do we need to do to get action on this?

flaccid, its not Invalid as a bug, its just that its not actually a
bug in the packages which have a status of Invalid. Its set that way
to help developers avoid going down the same dead-ends that triagers
and previous developers have gone down before. Please note that it is
marked as Confirmed in at least one package, network-manager, which is
where the focus of any dev work should go.

Its an old bug because its hard to solve. We're paying quite a bit
of attention to shutdown this cycle, so it should at least get some
attention.

Clint Byrum (clint-fewbar) wrote :

So I've done some analysis, and I believe the root of the problem is that dbus is stopped too early. network-manager stops whenever dbus stops, because it is needed. We currently stop dbus "on runlevel [06]" .. that is too early, because it is needed until after umountnfs runs as part of the shutdown.

So the solution will be in two parts:

1. we must change netbase so that the 'networking stop' action emits a hook event, which I'll call deconfiguring-networking, just before it deconfigures the network.
2. dbus will be changed to 'stop on deconfiguring-networking', and therefore also need a versioned dependency on the new version of netbase (otherwise it would not stop).

I am preparing uploads to oneiric that implement these two fixes.

Changed in dbus (Ubuntu):
assignee: nobody → Clint Byrum (clint-fewbar)
importance: Undecided → Medium
status: New → In Progress
Mike Perrin (mperrin) wrote :

On a functional level perhaps it is worth considering whether Network Manager, on stopping, should simply leave the interfaces as currently configured instead of taking them down. I can make the argument that Network Manager is a tool to make it easy for the user to control network interfaces, but Network Manager is not the owner of those interfaces, the system and user are. If the user makes a connection using Network Manger and then disables NM, why shouldn't the interface stay up until the user or a shutdown sequence takes it down?

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package netbase - 4.45ubuntu2

---------------
netbase (4.45ubuntu2) oneiric; urgency=low

  * debian/netbase.init: adding initctl call to allow upstart jobs which
    support networking to shutdown at the appropriate moment. just before
    networking is deconfigured. This specifically addresses network-manager
    stopping too soon. (LP: #211631)
 -- Clint Byrum <email address hidden> Mon, 23 May 2011 12:01:29 -0700

Changed in netbase (Ubuntu):
status: New → Fix Released
Clint Byrum (clint-fewbar) wrote :

Excerpts from Mike Perrin's message of Mon May 23 20:28:52 UTC 2011:
> On a functional level perhaps it is worth considering whether Network
> Manager, on stopping, should simply leave the interfaces as currently
> configured instead of taking them down. I can make the argument that
> Network Manager is a tool to make it easy for the user to control
> network interfaces, but Network Manager is not the owner of those
> interfaces, the system and user are. If the user makes a connection
> using Network Manger and then disables NM, why shouldn't the interface
> stay up until the user or a shutdown sequence takes it down?

Mike thats a great point and I think would be a design change for NM.
It might then be best to bring that up with the upstream developers.

As it stands now, NM does in fact own a network interface that it is
set to manage, and so, we must architect the system around that.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package dbus - 1.4.8-3ubuntu2

---------------
dbus (1.4.8-3ubuntu2) oneiric; urgency=low

  * debian/dbus.upstart: stop on deconfiguring-networking, a new
    event emitted during shutdown just before networking is deconfigured.
    This is a somewhat obtuse solution to the problem of network-manager
    stopping too early. (LP: #211631)
  * debian/control: versioned dependency on netbase that emits the new
    deconfiguring-networking event.
 -- Clint Byrum <email address hidden> Mon, 23 May 2011 16:17:51 -0700

Changed in dbus (Ubuntu):
status: In Progress → Fix Released
Mike Perrin (mperrin) wrote :

Excerpt from Clint Byrum's comment #146

> Excerpts from Mike Perrin's message of Mon May 23 20:28:52 UTC 2011:
> On a functional level perhaps it is worth considering whether Network
> Manager, on stopping, should simply leave the interfaces as currently
> configured instead of taking them down. I can make the argument that
> Network Manager is a tool to make it easy for the user to control
> network interfaces, but Network Manager is not the owner of those
> interfaces, the system and user are. If the user makes a connection
> using Network Manger and then disables NM, why shouldn't the interface
> stay up until the user or a shutdown sequence takes it down?
>
> Mike thats a great point and I think would be a design change for NM.
> It might then be best to bring that up with the upstream developers.
>
> As it stands now, NM does in fact own a network interface that it is
> set to manage, and so, we must architect the system around that.
--------------------
Bug (enhancement request) https://bugzilla.gnome.org/show_bug.cgi?id=650925 submitted 2011-05-24 01:05:57 UTC

bdoe (bdoe-att) wrote :

>On a functional level perhaps it is worth considering whether Network
>Manager, on stopping, should simply leave the interfaces as currently
>configured instead of taking them down. I can make the argument that
>Network Manager is a tool to make it easy for the user to control
>network interfaces, but Network Manager is not the owner of those
>interfaces, the system and user are. If the user makes a connection using
>Network Manger and then disables NM, why shouldn't the interface stay
>up until the user or a shutdown sequence takes it down?

Good point. However, an argument could also be made that if a user uses Network Manager to set up and establish the network connections, the user expects Network Manager to own and manage those connections. A logical extension of this expectation is that, when Network Manager is shut down, it takes its connections with it. If the user wants a more "permanent" connection, then the user should set up the connection manually. At least, that's the way I would expect things to work.

Johan Ryberg (jryberg) wrote :

Good point!
Den 24 maj 2011 22.54 skrev "bdoe" <email address hidden>:
>>On a functional level perhaps it is worth considering whether Network
>>Manager, on stopping, should simply leave the interfaces as currently
>>configured instead of taking them down. I can make the argument that
>>Network Manager is a tool to make it easy for the user to control
>>network interfaces, but Network Manager is not the owner of those
>>interfaces, the system and user are. If the user makes a connection using
>>Network Manger and then disables NM, why shouldn't the interface stay
>>up until the user or a shutdown sequence takes it down?
>
> Good point. However, an argument could also be made that if a user uses
> Network Manager to set up and establish the network connections, the
> user expects Network Manager to own and manage those connections. A
> logical extension of this expectation is that, when Network Manager is
> shut down, it takes its connections with it. If the user wants a more
> "permanent" connection, then the user should set up the connection
> manually. At least, that's the way I would expect things to work.
>
> --
> You received this bug notification because you are a direct subscriber
> of a duplicate bug (348075).
> https://bugs.launchpad.net/bugs/211631
>
> Title:
> Network is brought down before network filesystems are unmounted (CIFS
> timeout at shutdown)
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/network-manager/+bug/211631/+subscribe

Clint Byrum (clint-fewbar) wrote :

Excerpts from bdoe's message of Tue May 24 20:54:25 UTC 2011:
> >On a functional level perhaps it is worth considering whether Network
> >Manager, on stopping, should simply leave the interfaces as currently
> >configured instead of taking them down. I can make the argument that
> >Network Manager is a tool to make it easy for the user to control
> >network interfaces, but Network Manager is not the owner of those
> >interfaces, the system and user are. If the user makes a connection using
> >Network Manger and then disables NM, why shouldn't the interface stay
> >up until the user or a shutdown sequence takes it down?
>
> Good point. However, an argument could also be made that if a user uses
> Network Manager to set up and establish the network connections, the
> user expects Network Manager to own and manage those connections. A
> logical extension of this expectation is that, when Network Manager is
> shut down, it takes its connections with it. If the user wants a more
> "permanent" connection, then the user should set up the connection
> manually. At least, that's the way I would expect things to work.

Right, lets make sure this discussion happens in the right place,
which would be in the GNOME bug report.

I still have a hang on reboot / shutdown even after installing the more recent netbase (4.45ubuntu3) and dbus (1.4.8-3ubuntu2) packages on my Kubuntu 11.04 laptop. I have four cifs shares defined in fstab. If I shutdown or reboot, I see network-manager caught signal 15, then a message about dbus, then modem-manager caught signal 15, then modem-manager restarts and load a bunch of plugins, then restarts again and again loads a bunch of plugins after several seconds' pause, and then the system hangs. If I unmount the network shares before shutting down / rebooting ("sudo umount - a"), the sequence is the same, except that after the second time modem-manager starts up, there's message about dbus that flashes briefly on the screen just before the power cycles off (so no hang if I unmount the network shares).

deckoff@gmail.com (deckoff) wrote :

Hello
I got this bug on my Kubuntu 10.10 and 11.04 machine
Adding this conf file solved the problem for me on Kubuntu 10.10, but on 11.04 the bug is present even though the upstart job kicks off( the NAS is mounted) Other described solutions for the bug, which used to work on 10.10 does not on 11.04 anymore. Hope this info helps
Here is the conf
description "Automounter on default network"
author

start on net-device-up IFACE!=lo
stop on networking stopping
stop on net-device-down IFACE!=lo

env wifiD=deckoff #SSID(name) ot the wireless network where the NFS is connected
env mIP=192.168.1.106 #local IP of of the NFS
env mDIR=Public #default mounted dir
env lDIR=MyBookLive #the local place where the NFS is mounted to. The script mounts in a dir into /media/
env moptions=username=***,password=***,iocharset=utf8,file_mode=0777,dir_mode=0777,soft,noperm #options for your mount - username, password, iochart etc

post-start script

wifi="'$(/sbin/iwconfig eth1 | egrep ESSID | cut -d '"' -f 2)'"

      if [ $wifi = "'$wifiD'" ];
    then
      mount -t cifs //$mIP/$mDIR /media/$lDIR -o $moptions
      fi
end script

post-stop script

sleep 2
umount /media/$lDIR -f

end script

whochismo (whochismo) wrote :

I have had this problem for a long time, in different ubuntu versions, but this is the first time (Ubuntu 11.04) that I am unable to find a workaround.

Before, I used to create a script that would umount the network drives and place it at /etc/network/if-down.d. It used to work for Ubuntu 10.10, but now it doesn't anymore.

I don't think it's going to be solved anytime soon, so, any solution/workaround?

Neil Broadley (scaine) wrote :

Your options are :

1. Use a wired connection
2. Avoid Samba/CIFS shares and configure your server for NFS instead
3. Use AutoFS to create your network shares.

In case 3, AutoFS replaces the need to configure anything in /etc/fstab. Seems to work well enough with most connections, although another bug (https://bugs.launchpad.net/autofs/+bug/393012/comments/34) will give you some issues when you first set it up.

Samba shares and Ubuntu, at least over WIFI, don't make for a very happy experience, I'm afraid.

deckoff@gmail.com (deckoff) wrote :

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.

Mike Perrin (mperrin) wrote :

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.

c0l2e (ronartos) wrote :

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.

c0l2e (ronartos) wrote :

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.

Fred Saunier (fsaunier) wrote :

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

Fred Saunier (fsaunier) wrote :

Please read : on all *my* systems as well

jonbonjovi (jonbonjovi-84) wrote :

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

Steve Sutton (sutton) wrote :

@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.

jonbonjovi (jonbonjovi-84) wrote :

@ Steve Sutton:
done! it works!

Thanx!

Gonzals, S. (gonzales-speedy) wrote :

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

Steve Sutton (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

Gonzals, S. (gonzales-speedy) 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
>

Ernst (ernst-blaauw) 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?

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
>

Gonzals, S. (gonzales-speedy) wrote :
Download full text (4.7 KiB)

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...

Read more...

Alonso Andres (alo-and) wrote :

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

Steve Langasek (vorlon) wrote :

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>

Ernst (ernst-blaauw) wrote :

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?

Gonzals, S. (gonzales-speedy) wrote :

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

Steve Langasek (vorlon) wrote :

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>

Curtis Hovey (sinzui) on 2011-11-11
no longer affects: null
James (jamesasgrim) wrote :

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?!

Steve Langasek (vorlon) wrote :

> 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.

Changed in network-manager (Ubuntu):
status: Confirmed → Fix Released
Steve Langasek (vorlon) wrote :

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

Changed in wpasupplicant (Ubuntu):
status: Confirmed → Fix Released
James (jamesasgrim) 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).

Gonzals, S. (gonzales-speedy) wrote :

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

>

James (jamesasgrim) wrote :

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.

Clint Byrum (clint-fewbar) 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.

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.

Steve Langasek (vorlon) wrote :

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>

Gonzals, S. (gonzales-speedy) wrote :

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.

no longer affects: network-manager
Gonzals, S. (gonzales-speedy) wrote :

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)

DocJ (docjl61) wrote :

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

Markus Birth (mbirth) wrote :

The problem is still there on a fresh Raring installation.

Markus Birth (mbirth) wrote :

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

Steve Langasek (vorlon) wrote :

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.

Markus Birth (mbirth) wrote :

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.

Jamie Strandboge (jdstrand) wrote :

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.

Changed in dbus (Ubuntu Natty):
status: New → Won't Fix
no longer affects: dbus (Ubuntu Lucid)
no longer affects: dbus (Ubuntu Natty)
no longer affects: netbase (Ubuntu Lucid)
no longer affects: netbase (Ubuntu Natty)
no longer affects: network-manager (Ubuntu Lucid)
no longer affects: network-manager (Ubuntu Natty)
no longer affects: sysvinit (Ubuntu Lucid)
no longer affects: sysvinit (Ubuntu Natty)
no longer affects: wpasupplicant (Ubuntu Lucid)
no longer affects: wpasupplicant (Ubuntu Natty)
no longer affects: samba (Ubuntu)
no longer affects: samba (Ubuntu Lucid)
no longer affects: samba (Ubuntu Natty)
Paul Abrahams (abrahams) wrote :

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.

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

Other bug subscribers

Remote bug watches

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