On Mon, Jan 24, 2000 at 12:17:36PM +1100, Neil Brown wrote:
> On Thursday January 20, jens@pinguin.conetix.de wrote:
> > ... The problem occurs whenever a KDE app tries to access its
> > configuration or starts a file open dialog. It hangs with CPU stuck at
> > about 40% on both server and client. strace and tcpdump logs are below.
> ...
> > I chose to strace krdb because it's the first app that is started by the
> > startkde script (and it hangs).
> > krdb STRACE:
> > read(6, 0x40508000, 4096) = -1 EPERM (Operation not permitted)
> > fstat(6, {st_mode=S_IFREG|S_ISGID|0640, st_size=76, ...}) = 0
> > read(6, 0x40508000, 4096) = -1 EIO (Input/output error)
> > fstat(6, {st_mode=S_IFREG|S_ISGID|0640, st_size=76, ...}) = 0
> st_mode=S_IFREG|S_ISGID|0640 implies a "mandatory locking" file. knfsd
> currently refuses to touch mandatory locking files as NFS (v2 and v3 at
> least) cannot support mandatory locking. It would probably be as safe,
> and less intrusive, to allow access but simply deny all lock requests to
> a mandatory locking file, but I haven't looked into the issues very
> deeply.
Stupid question:
Why/how does nfsd tackle this? Can't knfsd just duplicate nfsd in this
respect for the time being?
> Do you know which file is being accessed? used "tcpdump -s 300" should
> help you find out. Does it "need" to have mandatory locking set?
No (as I'm not on the right machine right now) but I strongly suspect krdb
(the KDE-xrdb) is trying to load its configuration, i.e. load the KDE X
resources somewhere under $HOME/.kde/share/apps/krdb/. It's not critical (I
suppose) to just ignore mandatory locking for now.
But probably the KDE developers should also think of something here, it
makes all KDE apps unusable over kernel nfs (opening a file dialog is
enough..)
Thanks for your help!
-- _ciao, Jens_______________________________ http://www.pinguin.conetix.de · "[Microsoft] ... guarantees 99.8% NT uptime for certain hard-/software. That's exactly the 3 minutes daily that my NT server needs to reboot." -- ZDnet editorial- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:19 EST