Bug#505793: pm-utils: please provide scriptlet to unmount network filesystems
Florian Lohoff schreef: On Sat, Nov 15, 2008 at 05:25:19PM +0100, Michael Biebl wrote: Florian Lohoff wrote: Package: pm-utils Version: 1.1.2.4-1 Severity: wishlist 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 ... Why is it necessary to unmount the network filesystems and shouldn't they mounted on resume again. 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 - Well, that maybe typically for you;) TCP based filesystems will even timeout on the server as the tcp connection endpoint is gone and your tcp session will timeout. The only sane state is to unmount all network based filesystems on suspend. 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. 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 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#505793: pm-utils: please provide scriptlet to unmount network filesystems
On Mon, Nov 17, 2008 at 12:08:04PM +0100, Tim Dijkstra wrote: 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 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. 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. 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. 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 [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature
Bug#505793: pm-utils: please provide scriptlet to unmount network filesystems
Florian Lohoff schreef: On Mon, Nov 17, 2008 at 12:08:04PM +0100, Tim Dijkstra wrote: 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 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. 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. 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. 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. 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 ... 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#505793: pm-utils: please provide scriptlet to unmount network filesystems
On Mon, Nov 17, 2008 at 03:01:09PM +0100, Tim Dijkstra wrote: 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 ... 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. 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. Besides that, I thought that ifupdown already has some functionality that brings down networked filesystems if you bring down the interface. Nope Flo -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature
Bug#505793: pm-utils: please provide scriptlet to unmount network filesystems
Florian Lohoff schreef: On Mon, Nov 17, 2008 at 03:01:09PM +0100, Tim Dijkstra wrote: 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 ... 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. 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. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#505793: pm-utils: please provide scriptlet to unmount network filesystems
On Mon, Nov 17, 2008 at 04:17:04PM +0100, Tim Dijkstra wrote: 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. 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 [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature
Bug#505793: pm-utils: please provide scriptlet to unmount network filesystems
Florian Lohoff wrote: 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 ... 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 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#505793: pm-utils: please provide scriptlet to unmount network filesystems
Florian Lohoff wrote: And its not about the wired/wireless drivers not surviving. Bringing 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 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#505793: pm-utils: please provide scriptlet to unmount network filesystems
Package: pm-utils Version: 1.1.2.4-1 Severity: wishlist 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 90 /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 09 9- if [ $DIRS ] then umount $FLAGS $DIRS ES=$? fi ;; thaw|resume) ;; *) exit $NA ;; esac -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature
Bug#505793: pm-utils: please provide scriptlet to unmount network filesystems
Florian Lohoff wrote: Package: pm-utils Version: 1.1.2.4-1 Severity: wishlist 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 ... Why is it necessary to unmount the network filesystems and shouldn't they mounted on resume again. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#505793: pm-utils: please provide scriptlet to unmount network filesystems
On Sat, Nov 15, 2008 at 05:25:19PM +0100, Michael Biebl wrote: Florian Lohoff wrote: Package: pm-utils Version: 1.1.2.4-1 Severity: wishlist 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 ... Why is it necessary to unmount the network filesystems and shouldn't they mounted on resume again. 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 [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature
