Why would KDE 3.5 Konqueror hang while accessing NFS mount

[Lew Pitcher]

Environment:
Slackware 12.2 with all relevant patches applied
KDE 3.5 installed, Slackware packages
k3b-1.0.5-i486-2
kdeaccessibility-3.5.10-i486-2
kdeaddons-3.5.10-i486-2
kdeadmin-3.5.10-i486-4
kdeartwork-3.5.10-i486-2
kdebase-3.5.10-i486-3
kdebindings-3.5.10-i486-2
kdeedu-3.5.10-i486-2
kdegames-3.5.10-i486-2
kdegraphics-3.5.10-i486-2
kdelibs-3.5.10-i486-2
kdemultimedia-3.5.10-i486-2
kdenetwork-3.5.10-i486-2
kdepim-3.5.10-i486-4
kdesdk-3.5.10-i486-3
kdetoys-3.5.10-i486-2
kdeutils-3.5.10-i486-2
kdevelop-3.5.3-i486-3
kdewebdev-3.5.10-i486-2
kipi-plugins-0.1.5_beta1-i486-1bmg
knemo-0.4.8-i486-2
koffice-1.6.3-i486-7
ktorrent-2.2.8-i486-1
Kernel version:
Linux 2.6.27.7-smp #2 SMP Thu Nov 20 22:32:43 CST 2008 i686
AMD Phenom(tm) 9500 Quad-Core Processor AuthenticAMD GNU/Linux
Slackware package:
kernel-firmware-2.6.27.7-noarch-1
kernel-headers-2.6.27.7_smp-x86-1
kernel-huge-smp-2.6.27.7_smp-i686-1
kernel-mmap_min_addr-4096-noarch-1
kernel-modules-smp-2.6.27.7_smp-i686-1

I have several directories exported from an NFS server, all mounted at boot
time to subdirectories in /var/nfs/merlin (a custom directory). This
configuration has not changed at all in the last four years; neither the
exporting system nor the mounting system have had alterations to
permissions or NFS settings.

Recently (two days ago), my KDE 3.5 desktop started to give me problems.
Konqueror would hang while navigating through /some/ of the NFS
directories. I have symlinks in my $HOME to several /var/nfs/merlin/*/*
directories and subdirectories; Konqueror would hang at /some/ of these
directories, but properly access others.

I've reloaded all Slackware packages (upgradepkg --reinstall), and managed
to get the desktop and Konqueror to recognize /some/ NFS directories, but
still have things hang up unexpectedly. This KDE environment is fairly
fragile at the moment.

What I'm aiming for (what I had) is folders on my desktop, leading to the
NFS directories. Originally, I simply symlinked an entry in $HOME/Desktop
to the target NFS mount/directory
( ln -s /var/nfs/merlin/some/path $HOME/Desktop/FolderName )
and that worked well. I also used the KDE "Create New" -> "Link to Location"
to create some folders.

Now, I cannot symlink within $HOME/Desktop; all the folders that properly
connect are "Create New" -> "Link to Location" to symlinks in $HOME.
Konqueror will properly display these symlinks (when navigating through
$HOME), and properly open the desktop folders (when clicking the folder on
the desktop).

However, this procedure does not work for /all/ the NFS directories I
previously had access to: some /specific/ directories (whether accessed
through a symlink or through a "Link to Location") hang Konqueror.
Navigating via commandline (xterm, file dialog in Firefox & Kmail, runlevel
3) all work properly and *ALL* the exported directories and files are
accessable that way.

So, the problem seems isolated to Konqueror, and only to /some/ NFS
directories.

I've checked permissions, NFS (both the server and the client system)
and can't find the problem. What I need to know is if anyone has encountered
problems with NFS mounts under KDE 3.5 / Konqueror 3.5.10, and what to look
for.

Thanks
--
Lew Pitcher

[microsys]

> Navigating via commandline (xterm, file dialog in Firefox& Kmail, runlevel

> 3) all work properly and *ALL* the exported directories and files are
> accessable that way.
>
> So, the problem seems isolated to Konqueror, and only to /some/ NFS
> directories.
>
> I've checked permissions, NFS (both the server and the client system)
> and can't find the problem. What I need to know is if anyone has encountered
> problems with NFS mounts under KDE 3.5 / Konqueror 3.5.10, and what to look
> for.
>
> Thanks

Lew

I run slack-12.2 with much the same NFS setup as you describe. Rather than links
on the desktop I keep the links in the user accounts home directory. I have been
doing this since slack-10.2 with the only time symptoms such as you describe
happening being when the NFS server is down either by my own hand or a crash (
usually by my own hand )

I have not seen any problems directly related to KDE or Konqueror. It is unclear
if you are accessing the NFS directories over the network and as I read it you
are not. ( I could be misreading ). In any case, maybe that doesn't matter. The
key seems to be, you have changed nothing until you reinstalled things to
correct the problem. What that tells me is something other than KDE or Konqueror
is the culprit.

Two possibilities: 1. Hard disk problems, quite possibly intermittent.. In
that event, dmesg and or syslog would reveal it. 2. Network hardware somewhere
along the path between the two or more boxes. Wireshark or tcpdump would reveal
such a problem. It occurs to me another possibility being memory problems.

The way you describe the problem leads me to think along those lines. I suspect
you have already been there but maybe not.

Probably of little importance but for accuracy sake I am using several different
kernels with one server using 2.6.29.6-rt24-smp

the second server using 2.6.35.9-smp
and the client using 2.6.29.6-rt24-smp

[o...@grrr.id.au]

On Tue, 10 Jan 2012 19:13:07 -0500, Lew Pitcher <lpit...@teksavvy.com> wrote:

>Environment:
> Slackware 12.2 with all relevant patches applied

...

>I have several directories exported from an NFS server, all mounted at boot
>time to subdirectories in /var/nfs/merlin (a custom directory). This
>configuration has not changed at all in the last four years; neither the
>exporting system nor the mounting system have had alterations to
>permissions or NFS settings.

Looks odd to me, I'd never think to pop an nfs mountpoint in /var.

Not saying you're wrong, doesn't seem right to do that. But I
cannot recall if I've read anything saying _not_ to do that.

Maybe something wrote important state into to the mountpoints
that became buried by the NFS when it was mounted later?
...

>
>I've checked permissions, NFS (both the server and the client system)
>and can't find the problem. What I need to know is if anyone has encountered
>problems with NFS mounts under KDE 3.5 / Konqueror 3.5.10, and what to look
>for.

Check for files on the mountpoint with NFS imports unmounted,
I've been known to write stuff to the mountpoint and not notice
until the mountpoint ran out of space. Oops... :o)

Grant.

[Henrik Carlqvist]

Lew Pitcher <lpit...@teksavvy.com> wrote:
> I have several directories exported from an NFS server, all mounted at boot
> time to subdirectories in /var/nfs/merlin (a custom directory).

What is the configuration of your NFS server?

I suppose that you mount /var/nfs/merlin using a line in /etc/fstab? Do
you have any special options on that line? The option "intr" might be
useful for NFS mounts, it will not help against things like this, but at
least you will be able to kill processes hanging on unaccessable NFS
shares.

> However, this procedure does not work for /all/ the NFS directories I
> previously had access to: some /specific/ directories (whether accessed
> through a symlink or through a "Link to Location") hang Konqueror.

Do you find any NFS related messages from dmesg? It might also be
interesting to read the log files on the NFS client and, if possible, the
NFS server.

> Navigating via commandline (xterm, file dialog in Firefox & Kmail, runlevel
> 3) all work properly and *ALL* the exported directories and files are
> accessable that way.

Maybe konqeuror is follwoing symlinks, also checking out what they are
pointing to but in command line and file dialogs you are only looking at
the symlinks without caring about what they point to?

> So, the problem seems isolated to Konqueror, and only to /some/ NFS
> directories.

My guess is that you have problems with some parts of the directory
structure of your NFS server. I also guess that konqueror steps into those
problems but your other tests so far has not gone deep enough into the
problematic directories.

> I've checked permissions, NFS (both the server and the client system)
> and can't find the problem. What I need to know is if anyone has
> encountered problems with NFS mounts under KDE 3.5 / Konqueror 3.5.10,
> and what to look for.

Look for NFS timeouts in dmesg and log files. As some parts of the NFS
directory tree is working I would continue looking for file system errors
on the NFS server, but that might be hard to track if you have some kind
of cheap embedded NAS.

regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc123(at)poolhem.se Examples of addresses which go to spammers:
root@localhost postmaster@localhost

[Sylvain Robitaille]

On Tue, 10 Jan 2012 19:13:07 -0500, Lew Pitcher wrote:

> Recently (two days ago), my KDE 3.5 desktop started to give me
> problems. Konqueror would hang while navigating through /some/ of the
> NFS directories.

I know you say you checked the NFS server, and that this problem doesn't
exist for all content accessed via NFS, but whenever a "hang" occurs
while accessing data over NFS, you almost always want to be looking at
the network, or the NFS server. Userland applications, such as
Konqueror really make no distinction of whether the files they're
working with are local or on NFS-mounted storage. You see the *symptom*
in Konqueror (perhaps even *only* in Konqueror), but it's a symptom.

Perhaps you have stale file locks on either system? (that's only a
guess, mind you, but based on the fact that this affects only some
remote directories and not others, and only in some parts of the local
filesystem hierarchy, it may be worth looking into)

I hope I've helped.

--
----------------------------------------------------------------------
Sylvain Robitaille s...@encs.concordia.ca

Systems analyst / AITS Concordia University
Faculty of Engineering and Computer Science Montreal, Quebec, Canada
----------------------------------------------------------------------

[J.O. Aho]

Sylvain Robitaille wrote:
> On Tue, 10 Jan 2012 19:13:07 -0500, Lew Pitcher wrote:
>
>> Recently (two days ago), my KDE 3.5 desktop started to give me
>> problems. Konqueror would hang while navigating through /some/ of the
>> NFS directories.
>
> I know you say you checked the NFS server, and that this problem doesn't
> exist for all content accessed via NFS, but whenever a "hang" occurs
> while accessing data over NFS, you almost always want to be looking at
> the network, or the NFS server.

Don't forget portmap on both nfs server and nfs client, if it's not running,
thins kind of things tends to happen.



--

//Aho

[realto margarino]

Warning: Check out http://lewpitcher.ca

[realto margarino]

On Jan 11, 10:04 am, "RUBBER-BUTT" Robitaille wrote:

> I hope I've helped.

Har. Checkout http://lewpitcher.ca

[Lew Pitcher]

On Wednesday 11 January 2012 10:04, in comp.windows.x.kde,

s...@alcor.concordia.ca wrote:

> On Tue, 10 Jan 2012 19:13:07 -0500, Lew Pitcher wrote:
>
>> Recently (two days ago), my KDE 3.5 desktop started to give me
>> problems. Konqueror would hang while navigating through /some/ of the
>> NFS directories.
>
> I know you say you checked the NFS server, and that this problem doesn't
> exist for all content accessed via NFS, but whenever a "hang" occurs
> while accessing data over NFS, you almost always want to be looking at
> the network, or the NFS server.

Thanks, Sylvain.

I'm not entirely certain of the cause of the problem, but I've found a fix
for it. Once I get everything back in shape, I'll research the problem in
more detail.

I've double-checked my NFS server setup, and my client setup, and all seems
to be OK. I've moved my client mounts around, so that they use a different
mountpoint, checked and confirmed that the before-mount mountpoint
permissions and after-mount permissions on the mountpoints are what they
should be. I don't use NIS (too few users to bother setting up a NIS server
and client), and I've checked that all the userid's map properly. As I say,
my NFS setup hasn't changed recently, and hasn't changed much since I
originally set it up about a decade ago.

I can properly access the NFS files from the local commandline, accessing
directories and copying and moving files without problem. I can also
properly access the problem directories using XFCE's Thunar GUI file
manager. It's just Konqueror that gives me a problem.

According to top, when konqueror hangs, it takes 100% CPU; in other words,
it's not hanging on an obviously failed NFS interaction (which would map to
a non-interruptable sleep state), but is instead heavily looping, trying to
do something. This /might/ be a sign that the directory data comes back
corrupt, but if so, then the corruption is limited to interactions with
konqueror (and not to Thunar or to the commandline tools as you would
expect).

My workaround has been to move the data on the NFS server. That seems to fix
the problem. Another clue? My server's system logs and dmesg do not show
any problems with drive I/O, which would be my first guess as to the
problem, given that moving the data fixes it.

In any case, it looks like I'm getting it back together. I'll have to do a
post-mortum after I get stable again.
--
Lew Pitcher

[Lew Pitcher]

On Wednesday 11 January 2012 11:53, in comp.windows.x.kde, us...@example.net
wrote:

Right you are. Portmap is running happily on both client and server, along
with the other NFS tools. Double-checked this one this morning.

Thanks for the reminder.
--
Lew Pitcher

[Lew Pitcher]

Hi, Grant

On Wednesday 11 January 2012 00:25, in comp.windows.x.kde, o...@grrr.id.au
wrote:

> On Tue, 10 Jan 2012 19:13:07 -0500, Lew Pitcher <lpit...@teksavvy.com>
> wrote:
>
>>Environment:
>> Slackware 12.2 with all relevant patches applied
> ...
>>I have several directories exported from an NFS server, all mounted at
>>boot time to subdirectories in /var/nfs/merlin (a custom directory). This
>>configuration has not changed at all in the last four years; neither the
>>exporting system nor the mounting system have had alterations to
>>permissions or NFS settings.
>
> Looks odd to me, I'd never think to pop an nfs mountpoint in /var.
>
> Not saying you're wrong, doesn't seem right to do that. But I
> cannot recall if I've read anything saying _not_ to do that.

I originally set this up about 10 years ago. I didn't want my client NFS
mounts in /mnt, as that was used for temporary mounts, and these were going
to be permenant mounts. I was in the habit of mounting /usr as read-only,
and /boot, /root, /dev, /etc, /lib, /home, /bin, and /sbin were out of the
question. That left only /var and /opt, and I didn't see my mounts sitting
in /opt. I guess that I could have created a new high-level directory
(say /nfs) and mounted the shares there, but I didn't think of it at the
time.

Since then, the FHS has evolved, and (since this problem), I've moved all my
NFS mounts to /media mountpoints. Such is the way of system administration.
A distro can give you only so much; after that, the sysadm has to make
site-specific decisions and configure his/her system accordingly.

> Maybe something wrote important state into to the mountpoints
> that became buried by the NFS when it was mounted later?

Unlikely, but I /did/ check. I umounted all nfs mounts on the client, and
checked the /var/nfs directories for unexpected content. Nada. (FWIW,
the /var/nfs directory subtree was my invention, I didn't expect any system
tool would use the subtree to store info in.)

> ...
>>
>>I've checked permissions, NFS (both the server and the client system)
>>and can't find the problem. What I need to know is if anyone has
>>encountered problems with NFS mounts under KDE 3.5 / Konqueror 3.5.10, and
>>what to look for.
>
> Check for files on the mountpoint with NFS imports unmounted,
> I've been known to write stuff to the mountpoint and not notice
> until the mountpoint ran out of space. Oops... :o)

Done. And thank you for the reminder.

--
Lew Pitcher

[Lew Pitcher]

Hi, Henrik

On Wednesday 11 January 2012 02:22, in comp.windows.x.kde,

Henrik.C...@deadspam.com wrote:

> Lew Pitcher <lpit...@teksavvy.com> wrote:
>> I have several directories exported from an NFS server, all mounted at
>> boot time to subdirectories in /var/nfs/merlin (a custom directory).
>
> What is the configuration of your NFS server?

Well, it's changed a little bit since I posted my original message.
Originally, /etc/exports contained
/var/media *.my.lan(rw,root_squash,sync,no_subtree_check)
/home/lpitcher *.my.lan(rw,root_squash,sync,subtree_check)
Now, it contains a few more user home directories, but with the same format.

My NFS server is started by the bog-standard Slackware 13.0
(32bit) /etc/rc.d/rc.nfsd from /etc/rc.d/rc.inet2. No changes there from
what PV puts out.

This config has worked for about a decade now, over several releases of
Slackware, without any discernable problems.

> I suppose that you mount /var/nfs/merlin using a line in /etc/fstab?

Actually, several lines. I have subdirectories in /var/nfs/merlin, one for
each exported filesystem that I want to mount. This, too, has changed as I
tried to debug this problem; I've moved my client mountpoints out of /var
and into /media.

FWIW, each of the fstab entries use the "defaults" mount options. Yes, I
know that I should change this to specific NFS options, but the original
NFS-HOWTO (that I worked from in setting this up, so long ago) specifically
mentioned that "defaults" was acceptable. I'll look at changing the fstab
options to something more current and see if that fixes the problem.

> Do
> you have any special options on that line? The option "intr" might be
> useful for NFS mounts, it will not help against things like this, but at
> least you will be able to kill processes hanging on unaccessable NFS
> shares.

Nope. Just "defaults". But I'm working through a more current NFS-HOWTO, and
the mount.nfs(8) manpage, and I'll modify my mount options tomorrow.

>> However, this procedure does not work for /all/ the NFS directories I
>> previously had access to: some /specific/ directories (whether accessed
>> through a symlink or through a "Link to Location") hang Konqueror.
>
> Do you find any NFS related messages from dmesg? It might also be
> interesting to read the log files on the NFS client and, if possible, the
> NFS server.

Nothing. No NFS messages on either the client or the server. No media
failure messages on the server, either. The filesystem has been strangely
silent through all this.

>> Navigating via commandline (xterm, file dialog in Firefox & Kmail,
>> runlevel 3) all work properly and *ALL* the exported directories and
>> files are accessable that way.
>
> Maybe konqeuror is follwoing symlinks, also checking out what they are
> pointing to but in command line and file dialogs you are only looking at
> the symlinks without caring about what they point to?

Perhaps. When konqueror hangs, it takes 100% CPU (by top(1) measurement),
and does not swap out on a D status (as I would expect for a hardware-ish
failure). The interesting thing is that XFCE's Thunar GUI filesystem tool
doesn't have any problem navigating the same paths to the remote files and
directories. Thus, my suspicion that konqueror has some bug, that I have
perhaps exacerbated with my unusual and archaic setup.

>
>> So, the problem seems isolated to Konqueror, and only to /some/ NFS
>> directories.
>
> My guess is that you have problems with some parts of the directory
> structure of your NFS server. I also guess that konqueror steps into those
> problems but your other tests so far has not gone deep enough into the
> problematic directories.

What I'm finding is konqueror /does/ get into the problem directories (it
manages to read the .desktop file if it is there) before it hangs. And, if
I move the data (say, copy to a new directory) and remove the old
directory, the problem goes away. I'm thinking that something funky is
happening on the HD (a bad block, perhaps), but can't yet find any log
evidence to confirm it. I'll have to use some disk diagnostic tools to
check further.

>> I've checked permissions, NFS (both the server and the client system)
>> and can't find the problem. What I need to know is if anyone has
>> encountered problems with NFS mounts under KDE 3.5 / Konqueror 3.5.10,
>> and what to look for.
>
> Look for NFS timeouts in dmesg and log files. As some parts of the NFS
> directory tree is working I would continue looking for file system errors
> on the NFS server, but that might be hard to track if you have some kind
> of cheap embedded NAS.

Thanks again for the advice. I haven't yet found any NFS messages in dmesg
or the log files. But, I'll keep looking.

--
Lew Pitcher

[Lew Pitcher]

On Tuesday 10 January 2012 19:13, in comp.windows.x.kde,

lpit...@teksavvy.com wrote:

> Recently (two days ago), my KDE 3.5 desktop started to give me problems.
> Konqueror would hang while navigating through /some/ of the NFS
> directories. I have symlinks in my $HOME to several /var/nfs/merlin/*/*
> directories and subdirectories; Konqueror would hang at /some/ of these
> directories, but properly access others.

I've managed to "reproduce the problem" (that is to say, I did it to myself
again, but this time I was watching what I was doing).

Given a symlink to a directory on an NFS share (mounted rw), I tried to
change the *icon* that konqueror shows for that symlink. This causes
konqueror to write a .directory file in the directory that the symlink
points to, and from that point, konqueror hangs when attempting to access
that directory, or any directory in the non-local part of the path leading
to that directory. Deleting the .directory file fixes the problem.

I'd like to see if anyone can reproduce the behaviour, so I'll describe a
test case:

In your /home/$USER directory, create a symlink to a remote directory
ln -s /local/nfs/mountpoint/remote/nfs/directory /home/$USER/TestPt

In konqueror 3.5.10 (KDE 3.5.10), open your home directory
In konqueror, left-click the TestPt folder and select the "Properties"
option
In "Properties", right-click the default folder icon to bring up the
"Select Icon" window.
In the "Select Icon" window, select an icon that is different from the
default icon. This returns you to the "Properties" window, with the newly
selected icon showing as the icon for the directory.

In the "Properties" window, click the "OK" button. The "Properties" window
should close, and konqueror will hang. top(1) will show 100% CPU on
konqueror.

Kill konqueror.

Open a commandline window and delete remote .directory file:
rm /local/nfs/mountpoint/remote/nfs/directory/.directory

Start konqueror again. Navigation to the target NFS directory should work
now.

--
Lew Pitcher

[Lew Pitcher]

On Thursday 12 January 2012 07:56, in comp.windows.x.kde,

lpit...@teksavvy.com wrote:

> On Tuesday 10 January 2012 19:13, in comp.windows.x.kde,
> lpit...@teksavvy.com wrote:
>
>> Recently (two days ago), my KDE 3.5 desktop started to give me problems.
>> Konqueror would hang while navigating through /some/ of the NFS
>> directories. I have symlinks in my $HOME to several /var/nfs/merlin/*/*
>> directories and subdirectories; Konqueror would hang at /some/ of these
>> directories, but properly access others.
>
> I've managed to "reproduce the problem" (that is to say, I did it to
> myself again, but this time I was watching what I was doing).
>
> Given a symlink to a directory on an NFS share (mounted rw), I tried to
> change the *icon* that konqueror shows for that symlink. This causes
> konqueror to write a .directory file in the directory that the symlink
> points to, and from that point, konqueror hangs when attempting to access
> that directory, or any directory in the non-local part of the path leading
> to that directory. Deleting the .directory file fixes the problem.

I tried this again, and watched a little harder this time.

For some reason, the created .directory file was entirely empty (0 bytes).
That probably means that my NFS mount options need to be tightened a bit,
to force a data buffer flush (or perhaps my server's filesystem needs to
flush it's data buffer faster, I don't know yet which).

Here's a very simple way to hang konqueror: in the command line,
>/some/directory/.directory
to write a truncated .directory file into that directory. Pick a scratch
directory to do this in; you'll lose whatever settings you had.

Now, use konqueror to browse the target directory (/some/directory).
Hang!

Delete the .directory file, kill konqueror and all will be well.
--
Lew Pitcher

[J.O. Aho]

Lew Pitcher wrote:
> Hi, Henrik
>
> On Wednesday 11 January 2012 02:22, in comp.windows.x.kde,
> Henrik.C...@deadspam.com wrote:
>
>> Lew Pitcher <lpit...@teksavvy.com> wrote:
>>> I have several directories exported from an NFS server, all mounted at
>>> boot time to subdirectories in /var/nfs/merlin (a custom directory).
>>
>> What is the configuration of your NFS server?
>
> Well, it's changed a little bit since I posted my original message.
> Originally, /etc/exports contained
> /var/media *.my.lan(rw,root_squash,sync,no_subtree_check)
> /home/lpitcher *.my.lan(rw,root_squash,sync,subtree_check)
> Now, it contains a few more user home directories, but with the same format.

I would use async (standard today) and no_subtree_check, you will get a more
responsive shares.

>> I suppose that you mount /var/nfs/merlin using a line in /etc/fstab?
>
> Actually, several lines. I have subdirectories in /var/nfs/merlin, one for
> each exported filesystem that I want to mount. This, too, has changed as I
> tried to debug this problem; I've moved my client mountpoints out of /var
> and into /media.
>
> FWIW, each of the fstab entries use the "defaults" mount options. Yes, I
> know that I should change this to specific NFS options, but the original
> NFS-HOWTO (that I worked from in setting this up, so long ago) specifically
> mentioned that "defaults" was acceptable. I'll look at changing the fstab
> options to something more current and see if that fixes the problem.

default have at least for me caused problems when nfs server went down, the
client locks down and as you may know Linux NFS ain't as good on reconnecting
to NFS server when it comes up again as Solaris. I tend to use
bg,soft,timeo=100,intr, this has given me the best success if the server goes
down, but still not as good as Solaris based NFS clients.

>>> However, this procedure does not work for /all/ the NFS directories I
>>> previously had access to: some /specific/ directories (whether accessed
>>> through a symlink or through a "Link to Location") hang Konqueror.
>>
>> Do you find any NFS related messages from dmesg? It might also be
>> interesting to read the log files on the NFS client and, if possible, the
>> NFS server.
>
> Nothing. No NFS messages on either the client or the server. No media
> failure messages on the server, either. The filesystem has been strangely
> silent through all this.

When Konqueror has locked, can you access the directory in question with "ls
/path/to/nfs/directory/" ?
If that works without issues, then it's something in the Konqueror (most
likely then a bug which never will be fixed). Keep in mind that KDE3 ain't
anymore supported by the KDE devels, I know there is a "community" maintained
version, but I don't know how much work they done or if they done anything at all.

> What I'm finding is konqueror /does/ get into the problem directories (it
> manages to read the .desktop file if it is there) before it hangs. And, if
> I move the data (say, copy to a new directory) and remove the old
> directory, the problem goes away. I'm thinking that something funky is
> happening on the HD (a bad block, perhaps), but can't yet find any log
> evidence to confirm it. I'll have to use some disk diagnostic tools to
> check further.

This should generate some messages in dmesg output on the NFS server.

>>> I've checked permissions, NFS (both the server and the client system)
>>> and can't find the problem. What I need to know is if anyone has
>>> encountered problems with NFS mounts under KDE 3.5 / Konqueror 3.5.10,
>>> and what to look for.
>>
>> Look for NFS timeouts in dmesg and log files. As some parts of the NFS
>> directory tree is working I would continue looking for file system errors
>> on the NFS server, but that might be hard to track if you have some kind
>> of cheap embedded NAS.
>
> Thanks again for the advice. I haven't yet found any NFS messages in dmesg
> or the log files. But, I'll keep looking.

Keep eyes for network related messages, like link down/up message, but I guess
you would have noticed those by now if there was some.


--

//Aho

[Henrik Carlqvist]

Lew Pitcher <lpit...@teksavvy.com> wrote:
> When konqueror hangs, it takes 100% CPU (by top(1) measurement),
> and does not swap out on a D status

This fact combined with the fact that no useful messages were found in any
log files or dmesg would make me suggest the following to debug the
problem:

strace -p <pid of konqeror>

You could use ps to find out the pid of konqeror. The above command will
write a lot of text explaining what system calls the program does. Those
calls might explain which files are being accessed and how.

However, as you have already found the cause of the problem this will not
be neccesary for now, maybe you will find strace useful some other time.