Since fedora 15 (and now with 16) it seems that wireless clients take a long while to shutdown when they have network filesystems mounted at shutdown time.

I've pushed out a cifs mount via puppet, and all clients have it, including those on wireless. If say a laptop is on a wired connection it shuts down just fine, but if its on the wifi at the time (and no wired connection) it'll hang at the fedora f logo. I'm not sure if its indefinite or just a really long while, but ill give it a test when i shut this machine down in a second.

Needless to say its pretty annoying, so is there a way of causing the machine to shutdown even if network connectivity has been lost at unmount time, -- or an official way to reorder events so the wireless card is kept up until after the unmount happens during the shut down process (short of writing a custom script for shutdowns which is a bit of a kludge) ?

It does this on multiple machines, and all started doing it when we went from fedora 14 to 15. It was such an obvious issue i'd kind of assumed someone must have reported it or there was an easy fix, but i've not discovered anything yet.

Additional info: I can confirm that manually unmounting the mounts then shutting down (sudo shutdown or the xfce shutdown button) will shutdown just fine, it only hangs if the mounts are still mounted

The puppet config that sets the mount looks like this (now with the _netdev entry that is indeed pushed to clients successfully, but makes no difference):

   file    { "/mnt/share": ensure => directory,}
    mount   { "/mnt/share": 
    atboot => true,
    ensure => mounted,
    remounts => false,
    fstype => cifs,
    device => "//srv/share",
    options => "user,gid=shareusers,uid=${user},file_mode=0700,dir_mode=0700,credentials=/root/.smbcreds,_netdev",
    require => [ File["/mnt/share"], Group["shareusers"] ],
  • Do the -t cifs mounts include -o _netdev? I'm not sure how Fedora's init scripts are set up but it's something of a convention to mark mounts that require network.
    – ephemient
    Nov 23, 2011 at 22:51
  • ill check when i get home, but i very much doubt it. I'll see if i can get that option into the putty config that gets pushed out. I kind of assumed that it'd know its a network device as its a cifs mount type.
    – Sirex
    Nov 24, 2011 at 8:24
  • didn't help i'm afraid.
    – Sirex
    Nov 25, 2011 at 7:56
  • I have the same issue with a rolling Debian Testing too, I haven't noticed in a while since it's usually up, and I've been connected wired for a while with it. Never found a solution other than making sure to unmount before I shutdown.
    – Rob
    Nov 30, 2011 at 16:51

1 Answer 1


You could add "ifdown -a" or "ifdown wlan0" script to your /etc/init.d/ and then softlink it to /etc/rc0.d/ For example ln -s /etc/init.d/killwlan.sh /etc/rc0.d/S05killwlan.sh where killwlan.sh contains the ifdown script, rc0.d is the shut down process and S05 means that the script will start as the fifth (if there are other scripts from S01 to S04)

  • yea, i'm just kind of hoping this is a known issue without a custom fix. It happens on every laptop, seems a bit odd that noone else has run into it. :-(
    – Sirex
    Nov 29, 2011 at 10:27
  • also, wont this kill the wifi link, which is the opposite of what i want. The wifi being killed is why it hangs, i think.
    – Sirex
    Dec 5, 2011 at 21:30
  • sorry, do the opposite instead. ifup wlan0
    – dag729
    Dec 10, 2011 at 23:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.