Why does the desktop freeze whenever an NFS share fails? I have set all NFS mounts to soft,intr and yet, if I forget to unmount a share before taking down the NFS server, my desktop freezes.
Luckily I have Yakauke running, so I can at least get to a console. But of course the NFS mount cannot be umounted if it doesn't respond.
Also I assumed the setting shares to intr, soft would prevent other software from hanging if the share stops responding. Is that not so? Or is there another setting I am not aware of?
Any ideas how to prevent this from happening?
Emmett
On Sat, 2015-08-15 at 15:16 -0700, Emmett Culley wrote:
Why does the desktop freeze whenever an NFS share fails? I have set all NFS mounts to soft,intr and yet, if I forget to unmount a share before taking down the NFS server, my desktop freezes.
Maybe for the same reason my local NFS-mounted NAS starts up any time I open Dolphin, even when I'm just looking at a local directory. Something in KDE wants all possible filesystems available before it allows you to look at anything, or at least it seems that way. I've never bothered trying to pin it down.
poc
On 08/16/15 06:50, Patrick O'Callaghan wrote:
On Sat, 2015-08-15 at 15:16 -0700, Emmett Culley wrote:
Why does the desktop freeze whenever an NFS share fails? I have set all NFS mounts to soft,intr and yet, if I forget to unmount a share before taking down the NFS server, my desktop freezes.
Maybe for the same reason my local NFS-mounted NAS starts up any time I open Dolphin, even when I'm just looking at a local directory. Something in KDE wants all possible filesystems available before it allows you to look at anything, or at least it seems that way. I've never bothered trying to pin it down.
I am not seeing any desktop "freeze". I see that dolphin will get "stuck" when I open it up since 2 NFS mounts are at my $HOME location. Also, ls will freeze up.
I didn't uninstall, but I did tell "tracker" not to index anything. I'm sure someone finds "tracker" useful. :-)
On Thu, 2015-08-20 at 19:51 +0800, Ed Greshko wrote:
On 08/16/15 06:50, Patrick O'Callaghan wrote:
On Sat, 2015-08-15 at 15:16 -0700, Emmett Culley wrote:
Why does the desktop freeze whenever an NFS share fails? I have set all NFS mounts to soft,intr and yet, if I forget to unmount a share before taking down the NFS server, my desktop freezes.
Maybe for the same reason my local NFS-mounted NAS starts up any time I open Dolphin, even when I'm just looking at a local directory. Something in KDE wants all possible filesystems available before it allows you to look at anything, or at least it seems that way. I've never bothered trying to pin it down.
I am not seeing any desktop "freeze". I see that dolphin will get "stuck" when I open it up since 2 NFS mounts are at my $HOME location. Also, ls will freeze up.
I didn't uninstall, but I did tell "tracker" not to index anything. I'm sure someone finds "tracker" useful. :-)
Ditto, but AFAIK tracker doesn't run from KDE (it describes itself as "desktop neutral" so it shouldn't cause this issue even if it is running.
poc
Emmett Culley wrote:
Why does the desktop freeze whenever an NFS share fails? I have set all NFS mounts to soft,intr and yet, if I forget to unmount a share before taking down the NFS server, my desktop freezes.
Luckily I have Yakauke running, so I can at least get to a console. But of course the NFS mount cannot be umounted if it doesn't respond.
Also I assumed the setting shares to intr, soft would prevent other software from hanging if the share stops responding. Is that not so? Or is there another setting I am not aware of?
Any ideas how to prevent this from happening?
It not *that* different to when a (mounted) disk stops working. I'd recommend focusing on simply avoiding that situation.
-- rex
On 08/16/2015 07:01 AM, Rex Dieter wrote:
Emmett Culley wrote:
Why does the desktop freeze whenever an NFS share fails? I have set all NFS mounts to soft,intr and yet, if I forget to unmount a share before taking down the NFS server, my desktop freezes.
Luckily I have Yakauke running, so I can at least get to a console. But of course the NFS mount cannot be umounted if it doesn't respond.
Also I assumed the setting shares to intr, soft would prevent other software from hanging if the share stops responding. Is that not so? Or is there another setting I am not aware of?
Any ideas how to prevent this from happening?
It not *that* different to when a (mounted) disk stops working. I'd recommend focusing on simply avoiding that situation.
I assume that you were referring to local (physical) disks.
Regardless, I disagree: Failure happens and software should at least *attempt* to be resilient.
If I'm asking Konqueror or Dolphin to access a broken mount (local or network) then I understand if it hangs (though that could be avoided too, even if it just displays a "loading" indicator since it obviously can't get any further).
But for general operations I would expect that nothing should hang. This is a solvable problem, and suggesting that people should avoid hung mounts isn't helpful given that usually (this particular situation excepted) they are totally unavoidable. A hung desktop is never acceptable.
-Adam Batkin
On Sun, 2015-08-16 at 14:11 -0400, Adam Batkin wrote:
On 08/16/2015 07:01 AM, Rex Dieter wrote:
Emmett Culley wrote:
Why does the desktop freeze whenever an NFS share fails? I have set all NFS mounts to soft,intr and yet, if I forget to unmount a share before taking down the NFS server, my desktop freezes.
Luckily I have Yakauke running, so I can at least get to a console. But of course the NFS mount cannot be umounted if it doesn't respond.
Also I assumed the setting shares to intr, soft would prevent other software from hanging if the share stops responding. Is that not so? Or is there another setting I am not aware of?
Any ideas how to prevent this from happening?
It not *that* different to when a (mounted) disk stops working. I'd recommend focusing on simply avoiding that situation.
I assume that you were referring to local (physical) disks.
Regardless, I disagree: Failure happens and software should at least *attempt* to be resilient.
If I'm asking Konqueror or Dolphin to access a broken mount (local or network) then I understand if it hangs (though that could be avoided too, even if it just displays a "loading" indicator since it obviously can't get any further).
But for general operations I would expect that nothing should hang. This is a solvable problem, and suggesting that people should avoid hung mounts isn't helpful given that usually (this particular situation excepted) they are totally unavoidable. A hung desktop is never acceptable.
+1
poc
On 08/16/2015 12:51 PM, Patrick O'Callaghan wrote:
On Sun, 2015-08-16 at 14:11 -0400, Adam Batkin wrote:
On 08/16/2015 07:01 AM, Rex Dieter wrote:
Emmett Culley wrote:
Why does the desktop freeze whenever an NFS share fails? I have set all NFS mounts to soft,intr and yet, if I forget to unmount a share before taking down the NFS server, my desktop freezes.
Luckily I have Yakauke running, so I can at least get to a console. But of course the NFS mount cannot be umounted if it doesn't respond.
Also I assumed the setting shares to intr, soft would prevent other software from hanging if the share stops responding. Is that not so? Or is there another setting I am not aware of?
Any ideas how to prevent this from happening?
It not *that* different to when a (mounted) disk stops working. I'd recommend focusing on simply avoiding that situation.
I assume that you were referring to local (physical) disks.
Regardless, I disagree: Failure happens and software should at least *attempt* to be resilient.
If I'm asking Konqueror or Dolphin to access a broken mount (local or network) then I understand if it hangs (though that could be avoided too, even if it just displays a "loading" indicator since it obviously can't get any further).
But for general operations I would expect that nothing should hang. This is a solvable problem, and suggesting that people should avoid hung mounts isn't helpful given that usually (this particular situation excepted) they are totally unavoidable. A hung desktop is never acceptable.
+1
poc _______________________________________________ kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
OK, so I am not the only one :-)
I agree that the system shouldn't hang if an NFS share fails, any more that it should hang if I attempt to access an off-line server via fish (ssh), which it doesn't do.
Is it worth reporting a bug, or are we stuck with this (lack of ) functionality?
Emmett
On Sun, Aug 16, 2015 at 1:01 PM, Rex Dieter rdieter@math.unl.edu wrote:
Emmett Culley wrote:
Why does the desktop freeze whenever an NFS share fails? I have set all NFS mounts to soft,intr and yet, if I forget to unmount a share before taking down the NFS server, my desktop freezes.
Luckily I have Yakauke running, so I can at least get to a console. But of course the NFS mount cannot be umounted if it doesn't respond.
Also I assumed the setting shares to intr, soft would prevent other software from hanging if the share stops responding. Is that not so? Or is there another setting I am not aware of?
Any ideas how to prevent this from happening?
It not *that* different to when a (mounted) disk stops working. I'd recommend focusing on simply avoiding that situation.
It is different to mounted disk - if it happens, you have HW issue, not happening that often and it requires an action. But it's usually pretty reliable physical connection.
With NFS share (if it is not share you have your home on) over network, that can have stability issues, it's different thing. This happens to me when I mount internal network NFS share, disconnect for a meeting to the external network. Something you can avoid but it's pretty easy to forget you have to properly unmount NFS share. And the only way is to restart whole session :(
R.
-- rex
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
On 15/08/15 23:16, Emmett Culley wrote:
Why does the desktop freeze whenever an NFS share fails? I have set all NFS mounts to soft,intr and yet, if I forget to unmount a share before taking down the NFS server, my desktop freezes.
Luckily I have Yakauke running, so I can at least get to a console. But of course the NFS mount cannot be umounted if it doesn't respond.
Also I assumed the setting shares to intr, soft would prevent other software from hanging if the share stops responding. Is that not so? Or is there another setting I am not aware of?
Any ideas how to prevent this from happening?
Emmett
Emmette
I asked a similar question on 11 July in this list, to which there was no real answer.
The issue has been in KDE for many years (although I don't know if its had the same cause all along). If you google you'll find lots of people asking about this.
We have quite a lot of cross-mounted disks so I always have to be careful when rebooting an nfs server particularly as systemd often seems to find some reason to wait 3 mins in the shutdown phase while a stop job is running.
Roderick
On 08/18/2015 01:37 AM, Roderick Johnstone wrote:
On 15/08/15 23:16, Emmett Culley wrote:
Why does the desktop freeze whenever an NFS share fails? I have set all NFS mounts to soft,intr and yet, if I forget to unmount a share before taking down the NFS server, my desktop freezes.
Luckily I have Yakauke running, so I can at least get to a console. But of course the NFS mount cannot be umounted if it doesn't respond.
Also I assumed the setting shares to intr, soft would prevent other software from hanging if the share stops responding. Is that not so? Or is there another setting I am not aware of?
Any ideas how to prevent this from happening?
Emmett
Emmette
I asked a similar question on 11 July in this list, to which there was no real answer.
The issue has been in KDE for many years (although I don't know if its had the same cause all along). If you google you'll find lots of people asking about this.
We have quite a lot of cross-mounted disks so I always have to be careful when rebooting an nfs server particularly as systemd often seems to find some reason to wait 3 mins in the shutdown phase while a stop job is running.
Roderick _______________________________________________ kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
This is becoming a pretty serious issue for us. We have more that 15 local servers (both hardware and VM's) many of which are development machines. Which means they are often rebooted or otherwise taken off-line.
When that happens to a machine that someone has mounted an NFS share from, those with that mount get locked up.
Can someone from KDE please chime in on why this has to be so?
We don't use Gnome or any other DE, so I don't know if this is a KDE problem or a system problem.
Emmett
On Tuesday 18 August 2015 06:42:11 Emmett Culley wrote:
This is becoming a pretty serious issue for us. We have more that 15 local servers (both hardware and VM's) many of which are development machines. Which means they are often rebooted or otherwise taken off-line.
When that happens to a machine that someone has mounted an NFS share from, those with that mount get locked up.
Just my 2 penny worth, but...
I understand that this is annoying and would be good to have a solution on the system/KDE level, so NFS mounts are not locking system when they disappear.
It however rings in my head as to why in earth one would put an NFS service on a servers that are development / rebootable .... Logically, I would look at creating a single NFS server, and making your local machines to use that for any file sharing purposes..
On 08/18/2015 07:35 AM, Piotr Gbyliczek wrote:
On Tuesday 18 August 2015 06:42:11 Emmett Culley wrote:
This is becoming a pretty serious issue for us. We have more that 15 local servers (both hardware and VM's) many of which are development machines. Which means they are often rebooted or otherwise taken off-line.
When that happens to a machine that someone has mounted an NFS share from, those with that mount get locked up.
Just my 2 penny worth, but...
I understand that this is annoying and would be good to have a solution on the system/KDE level, so NFS mounts are not locking system when they disappear.
It however rings in my head as to why in earth one would put an NFS service on a servers that are development / rebootable .... Logically, I would look at creating a single NFS server, and making your local machines to use that for any file sharing purposes..
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
These servers are all development servers, and having NFS access allows our development IDE's to have direct access to the code under development. So there is a very good use case for having "unstable" NFS servers on the network.
The issue here is why does KDE stop, like a single threaded windows 3.1, when an NFS share disappears?
Emmett
Am Mittwoch, 19. August 2015, 21:42:37 schrieb Patrick O'Callaghan:
On Wed, 2015-08-19 at 12:20 -0700, Emmett Culley wrote:
The issue here is why does KDE stop, like a single threaded windows 3.1, when an NFS share disappears?
Very well put.
Hm, is it?
The question is more general. There are many programs and systems out there failing badly (with different types of errors - from crash up to reboot) if NFS fails. I run some VMWare ESXi Servers on NFS shares and they fail very hard if NFS goes down for few seconds. Only recovery is to reboot all connected VMWare Servers.
This must not be an excuse for KDE doing the same.
KDE (and Plasma and ...) uses Sockets and databases located in your home folder. Both are known to be bad in loosing their underlying file systems. This is not special to KDE, same is true for Gnome (at least partially).
There was a very old discussion on the kde mailing list (may be six years ago or even longer) about NFS and KDE with the conclusion, that NFS is no good idea for your home directory on modern graphical environments.
In the mean time I doubt that NFS in its current state is sufficient for linux. There are three different types of file access rules (normal unix acl, posix acl and nfs own acls) and you can not change NFS acls witch any modern graphical environment. This must not be NFSs fault, may be it is in the linux tools.
And NFS is no good option at all if it comes to wifi. It is slow and it does not recover very well if the connection breaks for a few seconds (at least with my latest tests three years ago) if you have open files on the NFS storage.
In consequence of this I switched from NFS based home drives to local home drive and sync from/to server at every login/logout. With this I can use my laptop even if there is no network available. And since sssd users login informations are cached.
My thoughts on this Martin
poc _______________________________________________ kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
Am 20.08.2015 um 11:45 schrieb Martin (KDE):
Am Mittwoch, 19. August 2015, 21:42:37 schrieb Patrick O'Callaghan:
On Wed, 2015-08-19 at 12:20 -0700, Emmett Culley wrote:
The issue here is why does KDE stop, like a single threaded windows 3.1, when an NFS share disappears?
Very well put.
Hm, is it?
yes
The question is more general. There are many programs and systems out there failing badly (with different types of errors - from crash up to reboot) if NFS fails. I run some VMWare ESXi Servers on NFS shares and they fail very hard if NFS goes down for few seconds. Only recovery is to reboot all connected VMWare Servers.
but they *use the storage* heavily
This must not be an excuse for KDE doing the same
KDE is not doing the same - it freezes away just because a mountpoint exists nobody intents to touch at that time and so the main question is WTF is there any backround activity at all to that storage
KDE (and Plasma and ...) uses Sockets and databases located in your home folder. Both are known to be bad in loosing their underlying file systems. This is not special to KDE, same is true for Gnome (at least partially).
you missed the point that nobody is talking about the userhome
the topic is about freezing away because a random, currently not used mountpoint is gone and that is simply unacceptable - frankly in 2015 good software should even survive a short network outage even if it is the homedir
you can reboot openvpn servers without killing a "tail -f" running on a remote machine and after the VPN connection in background is restored all is running as before - THAT is how software has to work
There was a very old discussion on the kde mailing list (may be six years ago or even longer) about NFS and KDE with the conclusion, that NFS is no good idea for your home directory on modern graphical environments.
AGAIN: the topic is even not the homedir, read the thread again
start here:
-------- Weitergeleitete Nachricht -------- Betreff: Re: Desktop freeze on NFS share failure Datum: Sat, 15 Aug 2015 23:50:00 +0100 Von: Patrick O'Callaghan pocallaghan@gmail.com Antwort an: KDE on Fedora discussion kde@lists.fedoraproject.org An: kde@lists.fedoraproject.org
On Sat, 2015-08-15 at 15:16 -0700, Emmett Culley wrote:
Why does the desktop freeze whenever an NFS share fails? I have set all NFS mounts to soft,intr and yet, if I forget to unmount a share before taking down the NFS server, my desktop freezes.
Maybe for the same reason my local NFS-mounted NAS starts up any time I open Dolphin, even when I'm just looking at a local directory. Something in KDE wants all possible filesystems available before it allows you to look at anything, or at least it seems that way. I've never bothered trying to pin it down.
Ok
sorry then for the noise. I thought it is a nfs home dir based problem.
regards Martin
Emmett Culley composed on 2015-08-19 12:20 (UTC-0700):
The issue here is why does KDE stop, like a single threaded windows 3.1, when an NFS share disappears?
My guess is the same root cause as why my Geckos hang when tabs are open to files on (OS/2) LANMAN shares CIFS mounted (manually) get broken on the server end (about every 10 days or so unless OS/2 rebooted), showing in mtab, but not available. Something in KDE seems to be demanding an unneeded access, maybe some prefetch process for increased file picker speed.
On Wednesday 19 August 2015 12:20:34 Emmett Culley wrote:
These servers are all development servers, and having NFS access allows our development IDE's to have direct access to the code under development. So there is a very good use case for having "unstable" NFS servers on the network.
I don't see a functional difference between that above and a single server holding the code in shares (one share per dev server, for example), and both dev server and IDE system mounting a share. You would have to change nfs share to work with different code/branch, but now you changing IP of the NFS server anyway, so it is very similar.
I do agree that this does not change the fact that there seem to be bigger issue. However changing the way you using NFS may give you working system now, instead of waiting for upstream to see this as an issue, which is not certain, and the fix it.
Piotr
-
Adam Batkin -
Ed Greshko -
Emmett Culley -
Felix Miata -
Jaroslav Reznik -
Martin (KDE) -
Patrick O'Callaghan -
Piotr Gbyliczek -
Reindl Harald -
Rex Dieter -
Roderick Johnstone