Hi, please provide a sleep scriptlet to unmount network filesystems. I am currently using this basically copied from /etc/init.d/umountnfs.sh which does more than needed (unmounting sysfs etc) ... This needs to be done before network manager is instructed to shut down networking e.g. i used priority 07 ... #!/bin/sh FLAGS="-f -l" case "$1" in hibernate|suspend) exec 9<&0 </etc/mtab DIRS="" while read DEV MTPT FSTYPE OPTS REST do case "$FSTYPE" in nfs|nfs4|smbfs|ncp|ncpfs|cifs|coda|ocfs2|gfs) DIRS="$MTPT $DIRS" ;; *) continue ;; esac done exec 0<&9 9<&- if [ "$DIRS" ] then umount $FLAGS $DIRS ES=$? fi ;; thaw|resume) ;; *) exit $NA ;; esac
Florian Lohoff wrote: Why is it necessary to unmount the network filesystems and shouldn't they mounted on resume again. Michael
Because typically your network filesystems will not be there after resume. At least thats my typical use case - suspending at home - going to work - resuming - then your serves will not be there and all desktop file managers will hang because of the long timeouts to retry to establish the connection again. TCP based filesystems will even timeout on the server as the tcp connection endpoint is gone and your tcp session will timeout - So you come back and try to regain connectivity on a tcp session the server does not know about anymore. The only sane state is to unmount all network based filesystems on suspend. mounting on resume might be done based on the ones in the fstab. Typically i have all temporary available network filesystems in the fstab as noauto,user so i mount them manually if i need them. Doing a mount -a -t nfs|cifs|smbfs|nfs4 on resume should be okay. If they are in the fstab to be automatically mounted thats what the user wanted to do ... Anyway - unmounting network based storage is what hibernate does and it even goes further by killing programs which have open files on the storage. I would go that far without user really wanting to do that. A sane way could be to refuse suspend if there are open files on the network storage as the state could get severly garbled if suspending with potentially dirty cache content or even resuming with some expectation about the files state (which might have changed in the last hours while we were suspended) so you could garble servers files on resume because somebody else already appended to the file etc I have no clue about dealing with nbd, iscsi, ataoe or all the network based block devices. Those should go away too but thats beyond the scope of this wishlist bug. Flo
Florian Lohoff schreef: Well, that maybe typically for you;) I never have had any problems with suspend and nfs (granted that is not TCP IIRC). We have machines with nfs home-dirs that do that daily here. I do not have any profound knowledge about netword filesystems, but I do think this is highly unlikely. I mean, a network filesystem must be (by nature of going over an unreliable medium) tolerant to timeouts and clients comming back after being disconnected, etc. Also these filesystems are almost certainly developed with a multi-user environment in mind, so your argument about somebody else altering the file and causing corruption seems unlikely. Of course a user who resumes his machine could of course save his old file over a new one, but that wouldn't be different from somebody leaving his machine on for the night, comming back and doing the same. To conclude, I don't think thers is a technical reason to honour your whislist request in pm-utils. I do think there is probably a demant for something like this, but the best place to do something about it would be some higher level app. A level where people can interact and say yes/no or set a default, like gnome-volumne-manager or so. IIRC, it does already complain about mounted USD devices... grts Tim
The point is you halt the application in the middle of saving and continue to save on resume - Nothing the user can prevent - you are stopping the whole system. The point is that all other tools to suspend have this option and it is used a lot. Suspend also takes down networking (/usr/lib/pm-utils/sleep.d/10NetworkManager) whats the point in this? I mean if you take down networking you also should take care of taking down network filestems before disabling networking. This is inconsitent behaviour ... Flo
Florian Lohoff schreef: That seems a bit hard to trigger. You press save in your app and then you immediately try to suspend the system without waiting to see saving had finished? Still, I do not think that corruption on the server could be caused by this. Most likely your app would generate some error, in the worst case I think it would crash. That file is or should be part of NetworkManager. I must confess, I'm not using NetworkManager so I didn't notice it doing evil stuff. FWIW, I'm against bringing down network interfaces during suspend. Besides that, I thought that ifupdown already has some functionality that brings down networked filesystems if you bring down the interface. grts Tim
Thats just a false assumption - suspend/resume is for 100% of the Notebook users a mobility issue - so all assumptions about the outer world dont hold up on a suspend/resume cycle. You might be away 10 minutes and come back on the same network (unlikely) or stay away for years or move thousands of kilometers. Thats why usb disconnects all devices (user might decide to unplug) and all pcmcia devices should get "ejected", network should be shut down and network filesystems should be unmounted. The world will most likely look different when you wakeup so dont take wrong assumptions. Nope Flo
Florian Lohoff schreef: There must be also quite some people that suspend their notebook on their desk. Besides that most modern desktops I've seen also suspend just fine. Anyway, what I wanted to say in all my argumentation so far is that bringing down the network (and with it networked filesystems) is IMHO a policy decision that could be presented as a question by some highlevel app. Also to maybe give the user some time so save their stuff, etc. It should not default to `bring down' at the lowest layer (pm-utils), exactly because there is no reason to do it. Since most wired and wireless network cards have been fixed to survive a suspend/resume cycle there is no _need_ to bring them down. grts Tim
I see it the other way round. Making assumptions about the situation on resume is a policy decision - IMHO suspend/resume should be more like init s, init 2 e.g. half a reboot environment wise. Assuming the network setup is the same and storage is still there is an assumption i guess can not hold up 90% of the time. And its not about the wired/wireless drivers not surviving. Bringing down the network is done because the network environment will most likely change and releasing a DHCP lease on suspend is polite behaviour. I am not network connected while suspended so tell the network about it. Flo
Florian Lohoff wrote: This has a different reason afaik. Some network cards (mostly wireless) have to be taken down, otherwise they can interfere with a successful suspend. Michael
Florian Lohoff wrote: Actually I think this was the initial reason why the NetworkManager scriplet was added to pm-utils, as I wrote in a previous email. Cheers, Michael
Dear submitter, as the package pm-utils has just been removed from the Debian archive unstable we hereby close the associated bug reports. We are sorry that we couldn't deal with your issue properly. For details on the removal, please see https://bugs.debian.org/1058701 The version of this package that was in Debian prior to this removal can still be found using https://snapshot.debian.org/. Please note that the changes have been done on the master archive and will not propagate to any mirrors until the next dinstall run at the earliest. This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@ftp-master.debian.org. Debian distribution maintenance software pp. Thorsten Alteholz (the ftpmaster behind the curtain)