how to: automatically umount cifs partitions

[kaiben]

Yes, i changed all three scripts.

[diana.artemis]

Yes, i changed all three scripts.

Mmmm... Sorry, I can't suggest anything else.

First, it's very odd that Sander Marechal's umountcifs script has stopped working in Jaunty. Secondly, it's very odd that changes to the priority of the 'stop' in rc0.d and rc6.d are not working as expected.

Given this has just appeared, I'm wondering whether it's something to do with the new Upstart in Jaunty, which now controls the boot and shutdown processes.

(I notice that Sander Marechal mentioned such a possibility in this thread last year, here
http://ubuntuforums.org/showpost.php...1&postcount=65
and I'm guessing the changes just introduced may have messed up the fixes involving external scripts in some way)

But I'm way out of my depth now. Let's hope someone who really understands this stuff can make sense of what's going on, and find a permanent fix for this longstanding bug, which has been plaguing Ubuntu for three years:
https://bugs.launchpad.net/ubuntu/+s...nit/+bug/42121

[veloce]

Strange, I have umountnfs.sh as k15 (i.e. it runs third).

This has been running fine and has not been affected by the upgrade to Jaunty.

[diana.artemis]

Update on this issue with Jaunty. I'd upgraded an old Dell Inspiron laptop from Intrepid, and that was the machine on which the umountcifs script stopped working.

I've just done a clean install of Jaunty on this laptop, and on an old Compaq PC. I installed the script on both.

The desktop shut down fine with umountcifs being called at K02 in rc0.d and rc6.d; but the laptop - with exactly the same set up - suffered the CIFS VFS error.

Importantly, the desktop has a PCI network card, but the laptop has a PCMCIA wifi card. The problem is clearly to do with a difference in the relative positions in the shutdown sequence that the shares are unmounted and different types of interface are closed.

So I tried setting umountcifs to K00 on the laptop. It shuts down OK now (though there is a brief flicker out to a terminal during the GUI shutdown sequence - probably something to do with putting umountcifs before gdm.)

Hope this helps someone with their investigations.

[dmizer]

Update on this issue with Jaunty. I'd upgraded an old Dell Inspiron laptop from Intrepid, and that was the machine on which the umountcifs script stopped working.

I've just done a clean install of Jaunty on this laptop, and on an old Compaq PC. I installed the script on both.

The desktop shut down fine with umountcifs being called at K02 in rc0.d and rc6.d; but the laptop - with exactly the same set up - suffered the CIFS VFS error.

Importantly, the desktop has a PCI network card, but the laptop has a PCMCIA wifi card. The problem is clearly to do with a difference in the relative positions in the shutdown sequence that the shares are unmounted and different types of interface are closed.

So I tried setting umountcifs to K00 on the laptop. It shuts down OK now (though there is a brief flicker out to a terminal during the GUI shutdown sequence - probably something to do with putting umountcifs before gdm.)

Hope this helps someone with their investigations.

Are you using network-manager to manage your wireless connection? Network-manager starts your network in userspace, so when you log off, your network connection (and thereby your share connection) terminates. You may be successful by running the unmount script during your session logout: http://ubuntuforums.org/showthread.php?t=252935

[diana.artemis]

Are you using network-manager to manage your wireless connection? Network-manager starts your network in userspace, so when you log off, your network connection (and thereby your share connection) terminates. You may be successful by running the unmount script during your session logout: http://ubuntuforums.org/showthread.php?t=252935

I just realised this issue occurs on both my laptops (not just the one with PCMCIA wifi interface). So, yes, I use network-manager for the wifi. But I'm afraid I don't know enough about bash scripts to follow your advice. The thread you pointed to suggests adding the script to the end of /etc/gdm/PostSession/Default; but I don't really feel confident about where or how to add umountcifs to this:

#!/bin/sh

PATH="/usr/bin:$PATH:/bin:/usr/bin"
OLD_IFS=$IFS

gdmwhich () {
  COMMAND="$1"
  OUTPUT=
  IFS=:
  for dir in $PATH
  do
    if test -x "$dir/$COMMAND" ; then
      if test "x$OUTPUT" = "x" ; then
        OUTPUT="$dir/$COMMAND"
      fi
    fi
  done
  IFS=$OLD_IFS 
  echo "$OUTPUT"
}

exit 0

I'd be grateful for any suggestions!

(And then I guess it would also be necessary to revert the priorities in rc0.d and rc6.d to the defaults?)

[diana.artemis]

...Network-manager starts your network in userspace, so when you log off, your network connection (and thereby your share connection) terminates...

Dmizer >>> Isn't that why

K01umountnfs.sh
K02gdm
K03usplash

works -- because it makes the nfs unmount *before* gdm shuts down? So what's the 'risk' of shutting down like that, rather than running the umountcifs script?

Is it that the script checks whether any processes are using the mounted shares, and, if so, kills them before unmounting? What happens if they're still running when the shares are unmounted? Possible loss of data, I guess; but is that actually likely to happen in most real-world shutdowns by the user?

Sorry to ask so many questions, but I don't know much about these processes, and am trying to get some inkling of what's going on here.

[dmizer]

Well, you said it's NOT working. That's why K01umountnfs.sh, K02gdm, and K03usplash /should/ work.

As to the /etc/gdm/PostSession/Default, try putting your unmount script at the very top like so:

#!/bin/sh
Your umount script here

PATH="/usr/bin:$PATH:/bin:/usr/bin"
OLD_IFS=$IFS

gdmwhich () {
  COMMAND="$1"
  OUTPUT=
  IFS=:
  for dir in $PATH
  do
    if test -x "$dir/$COMMAND" ; then
      if test "x$OUTPUT" = "x" ; then
        OUTPUT="$dir/$COMMAND"
      fi
    fi
  done
  IFS=$OLD_IFS 
  echo "$OUTPUT"
}

exit 0

If worst comes to worst, it's easy enough to revert that file. If that doesn't work, please post the contents of your /etc/fstab if you've posted it before, I missed it.

[diana.artemis]

Well, you said it's NOT working. That's why K01umountnfs.sh, K02gdm, and K03usplash /should/ work.

As to the /etc/gdm/PostSession/Default, try putting your unmount script at the very top like so...

Thanks for your reply. I should have been clearer - the K01/K02/K03 set up as above does indeed work fine. And I could actually live with that.

But I wasn't sure how 'safe' it is (from the point of view of data loss/corruption during the shutdown). As I understand it, the umountcifs script actually checks for processes using the shares, and kills them before unmounting the shares; but I don't think umountnfs.sh does that, so I assumed it relied on some other script to look after that first? Is that so, or is it safe to leave the K01umountnfs.sh / K02gdm / K03usplash set up to do the job safely?

Not being sure about this, I thought I'd try to get the umountcifs script working properly on my wifi machines, and that's why I came back with the questions above.

Thanks very much for your suggestion about hacking /etc/gdm/PostSession/Default. Do you reckon that would be a better method? If so, I'll put the rc0. and rc6.d scripts back in the right order, and try the hack, when I've got a few minutes.

[dmizer]

Hacking /etc/gdm/PostSession/Default shouldn't be necessary for cifs. For NFS, just add the "soft" option to your nfs fstab line. Then it can unmount normally during shutdown even if the network is not active.

Like this:

server.mydomain.com:/files /files nfs soft,rsize=8192,wsize=8192,timeo=14,intr

FYI from man nfs:

       soft / hard    Determines the recovery behavior of the NFS client after
                      an NFS request times out.  If neither option  is  speci‐
                      fied  (or if the hard option is specified), NFS requests
                      are retried indefinitely.  If the soft option is  speci‐
                      fied,  then  the  NFS  client fails an NFS request after
                      retrans retransmissions have been sent, causing the  NFS
                      client to return an error to the calling application.

                      NB:  A  so-called  "soft"  timeout can cause silent data
                      corruption in certain  cases.  As  such,  use  the  soft
                      option only when client responsiveness is more important
                      than data integrity.  Using NFS over TCP  or  increasing
                      the value of the retrans option may mitigate some of the
                      risks of using the soft option.

Emphasis mine.

For example (default is 3):

server.mydomain.com:/files /files nfs soft,retrans=6,rsize=8192,wsize=8192,timeo=14,intr