[hardy] KDE applications crash on clients with CIFS mounted home directory

Bug #388636 reported by Dragomir Minkovski
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
KDE Base
Fix Released
High
kdebase (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Binary package hint: kdebase

I can reproduce this bug 100% of the time. Many KDE applications crash with the following output from the command line (K Interactive Geometry (kig) is an example here and 'user' is a user logged in via his LDAP account):

WARNING: Problem deleting stale lockfile /home/KAS/user/.kde/share/config/kigrc.lock

Other KDE apps like kgoldrunner, ksokoban, and kbruch also produce the same error.

This is only happening with users who have logged in via their LDAP account on clients. If you log in using an account local to the machine, all of these applications run just fine.

We are using Ubuntu 8.04.2 on all client machines and same with the server.

Just to make sure, I created a brand new account (teststudent) on the server and tried running ksokoban and kig on a client. The error just loops until I kill it with ctrl-Z.

The files in question do exist. Here is the output of the folder:

teststudent@gnu6:~/.kde/share/config$ ls -l
total 3072
-rwxr--r-- 1 teststudent student 23 2009-04-30 12:16 kconf_updaterc.lock
-rwxr--r-- 1 teststudent student 14 2009-04-30 12:19 kigrc.lock
-rwxr--r-- 1 teststudent student 19 2009-04-30 12:18 ksokobanrc.lock"

The original bug is against LDAP, but I don't think that's related. I reproduced the bug using the same environment, but haven't tried to reproduce it without LDAP authentication. The result is the application newer appears on the desktop, and is producing the errors on the terminal:

WARNING: Problem deleting stale lockfile /home/KAS/stu/.kde/share/config/kconf_updaterc.lock
WARNING: Problem deleting stale lockfile /home/KAS/stu/.kde/share/config/kconf_updaterc.lock
...
- cut -

After deleting manually the lock file the error appear again with new lock file:

WARNING: Problem deleting stale lockfile /home/KAS/stu/.kde/share/config/kdeglobals.lock
WARNING: Problem deleting stale lockfile /home/KAS/stu/.kde/share/config/kdeglobals.lock
...
- cut -

The upstream bug is http://bugs.kde.org/show_bug.cgi?id=156759

Comments 19 through 36 look to be the most relevant ... http://bugs.kde.org/show_bug.cgi?id=156759#c19

Particularly comment 24 - http://bugs.kde.org/show_bug.cgi?id=156759#c24

"For all users which can not wait for an KDE update. Here is a workaround:

Add the option "serverino" when mounting a CIFS share. I tested this which
Samba 3.x on the server side. I do not know if this works with Windows on the
server side too."

...

"Thanks for the tip. It solved the problem for me on two out of three
shares.

Just a warning though: According to the mount.cifs man page you should NOT use
this workaround if your share spans more than one disk partition on the server,
as that would give you duplicate inode numbers on the client (two files, same
mount, same inode number = trouble)."

Revision history for this message
In , muesli (muesli) wrote :

Version: (using Devel)
Installed from: Compiled sources
OS: Linux

Having mounted a remote samba share via cifs (or smbfs) i noticed dolphin crashes / freezes when trying to change the sort mode or view mode on a directory that my user has no write-permissions on the server. (yet the share is being mounted as rw). Changing the mount options to ro (read-only) fixes the issue, yet I think dolphin shouldn't crash / freeze in such a situation, but handle the error gracefully. It appears it tries to write a lock-file in this directory - which it obviously fails to do.

Revision history for this message
In , Marco Krohn (marco-krohn) wrote :

I experience the same kind of freeze of dolphin on my NAS (mounted "rw") when trying to switch the view mode from "icons" to "details". However, I have write permissions on the directory.

BTW: Thanks a lot for dolphin - it is a great application!

Revision history for this message
In , Christian Weilbach (christian-weilbach) wrote :

I have the problem, too, with trunk (kdebase rev. 816127). If I remove the .directory.lock file by hand (which I can do as the same user as dolphin runs on cifs), dolphin unfreezes and changes the settings. I guess it should a) not freeze on any view mode changes and at least timeout and b) should work in default here. But this is only my 2 pence. I hope you fix it somehow.

Cheers,
duns

Revision history for this message
In , Ian Dickerson (iandickerson) wrote :

I can confirm Dolphin hangs on change of view mode while navigating cifs mount. When run from command line, it complains of "problem deleting stale lockfile". Deleting .directory.lock manually does unfreeze but only until the next view change. Since I mount most of my home directory over cifs, this is a bit of showstopper.

Using Dolphin Version 1.0.99
KDE 4.00.83 (KDE 4.0.83 (KDE 4.1 Beta2)

Revision history for this message
In , Peter-penz19 (peter-penz19) wrote :

The issue is on my TODO-list and I've increased the priority, but I cannot promise that it will be fixed until KDE 4.1 final.

Revision history for this message
In , Toma-u (toma-u) wrote :

Confirmed. Makes file management impossible for those folders, is there a temp workaround or can you explain more about the cause?

Revision history for this message
In , Peter-penz19 (peter-penz19) wrote :

@Tom: A temporary workaround is to enable "(x) Use common view properties for all folders", by this Dolphin won't write the .directory files. The fix should not be difficult I hope, but the next 2 weeks I've quite less time for Dolphin :-(

Revision history for this message
In , Peter-penz19 (peter-penz19) wrote :

@David: I cannot reproduce this issue - although I've write access to my samba-share, Dolphin (correctly) stores the .directory files mirrored inside ~/.kde4/share/apps/dolphin -> no locking.

I had a look at the code and from my point of view Dolphin should never try to write on non-local directory. Inside ViewProperties.cpp there is the following check (simplified here - 'url' is the input, m_filePath the path where the .directory file will be written):

    KUrl cleanUrl(url);
    cleanUrl.cleanPath();
    m_filepath = cleanUrl.path();

    ...
    if (cleanUrl.isLocalFile()) {
        const QFileInfo info(m_filepath);
        if (!info.isWritable()) {
            m_filepath = destinationDir("local") + m_filepath;
        }
    } else {
        m_filepath = destinationDir("remote") + m_filepath;
    }

Where destinationDir() is implemented like this:

QString ViewProperties::destinationDir(const QString& subDir) const
{
    QString basePath = KGlobal::mainComponent().componentName();
    basePath.append("/view_properties/").append(subDir);
    return KStandardDirs::locateLocal("data", basePath);
}

I'm confused now as cleanUrl.isLocalFile() should return false in the case of cifs/smbfs and hence never may touch the .directory file. And even if true would be returned, then isWritable() may not return true if it is not writable.

From a quick look at this code: Do you see a general flaw here? Thanks!

Revision history for this message
In , Toma-u (toma-u) wrote :

(for me this is about cifs mounted shares, so that would be /home/toma/someserver/networkshare/)

Revision history for this message
In , Peter-penz19 (peter-penz19) wrote :

@Tom: Ah, this would explain why at least cleanUrl.isLocalFile() returns true. Hmm, I'm still wondering when fileInfo.isWriteable() returns true why it still locks...

Revision history for this message
In , Toma-u (toma-u) wrote :

yes, it looks like dolphin checks the timestamp on the .directory file like: "m_node->timestamp() < settings->viewPropsTimestamp()". I'm pretty sure this is error prone for mounted devices, as it will probablt get the server timestamp. So if the date/time on the server does not match exactly the one on the client, this could cause trouble in theory. I just can't see how it could make dolphin hang though. Maybe this helps.

Revision history for this message
In , Peter-penz19 (peter-penz19) wrote :

*** Bug 162816 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Peter-penz19 (peter-penz19) wrote :

*** Bug 168407 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Peter-penz19 (peter-penz19) wrote :

*** Bug 151112 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Cwales (cwales) wrote :

Confirming I have this bug also - openSUSE x86_64 rpms, using a CIFS-mounted filesystem. Trying to change the view to detailed view, to image preview or any other change to the basic folder view causes Dolphin to crash.

Revision history for this message
In , Cwales (cwales) wrote :

Additional behaviour I've observed: Dolphin will crash if you try to switch view or sort mode on ANY directory, whilst you have a SMBFS/CIFS directory open. So, if you have an SMBFS/CIFS window open, split the view, use the second pane to navigate through the local filesystem and then try and change view/sort mode on the local fs, Dolphin will freeze as there is an SMBFS/CIFS window open, even though this is not the directory you are trying to sort.

This applies even if the SMBFS/CIFS system is open in a completely Dolphin window; changing view or sort on the local fs will still cause Dolphin to freeze.

Revision history for this message
In , Danielstefanmader (danielstefanmader) wrote :

It seems to me that this bug also affects Konqueror, not only Dolphin. Since networking is a somewhat essential feature of a Linux box I'd be very happy to see this bug fixed soon! (Along with the printing issues :)

I am using the KDE4:factory repo from the openSUSE Buildservice for the future 11.1 release.

Revision history for this message
In , Danielstefanmader (danielstefanmader) wrote :

Is there any news on this issue? It makes everyday real-life usage experience with KDE4 a hellish nightmare...

Revision history for this message
In , Gregor Rosenauer (grexe) wrote :

same here with KDE 4.1.1, thanks for the workaround, Christian Weilbach!
I'd even build dolphin from SVN for this issue to get resolved, please get back to this bug as soon as you can, Peter Penz.

Revision history for this message
In , David Faure (faure) wrote :

Doh, I first tested with a NFS mount, but those work fine.
With smbmount I see "couldn't lock local file" indeed, for a readonly mount
(this is because smbmount doesn't adjust permissions like nfsmount does, for a readonly mount, so the permissions seem to indicate that the directory is writable, while it is not). Ah, with a readwrite mount I finally get the bug.
WARNING: Problem deleting stale lockfile /<path>/.directory.lock
WARNING: Problem deleting stale lockfile /<path>/.directory.lock
etc. forever. Definitely a KLockFile bug. Investigation showed:

lockFile() always returns LockFail, even though it creates the lock file fine.

173 if (st_buf != st_buf2 || S_ISLNK(st_buf.st_mode) || S_ISLNK(st_buf2.st_mode))
174 {
175 // SMBFS supports hardlinks by copying the file, as a result the above test will always fail
176 if ((st_buf.st_nlink == 1) && (st_buf2.st_nlink == 1) && (st_buf.st_ino != st_buf2.st_ino))
177 {
[...]
181 }
182 return KLockFile::LockFail;

The first if() is indeed always false, but the second one too:
st_buf.st_nlink is 2, st_buf2.st_nlink is 2 as well, and the st_ino differ indeed.
So I have a patch which fixes this, but KLockFile is still VERY slow locking that file (i.e. every time I click on the view mode change button!), because of the slow testLinkCountSupport() code that the snipped code in the above if runs... Ouch I wanted to ask the author of the code about all this, but that's Waldo...

Revision history for this message
In , David Faure (faure) wrote :

Created attachment 27434
patch

Revision history for this message
In , David Faure (faure) wrote :

Dirk says he has a patch that replaces all this code with an atomic move instead. Sounds good to me :)

Revision history for this message
In , David Faure (faure) wrote :

*** Bug 151680 has been marked as a duplicate of this bug. ***

Revision history for this message
In , David Faure (faure) wrote :

*** Bug 165245 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Bjoern Voigt (bjoern) wrote :

For all users which can not wait for an KDE update. Here is a workaround:

Add the option "serverino" when mounting a CIFS share. I tested this which Samba 3.x on the server side. I do not know if this works with Windows on the server side too.

Revision history for this message
In , Gregor Rosenauer (grexe) wrote :

bjoern, thanks very much for the tip - works here too!
Still looking forward to the atomic fix, though,-)

Revision history for this message
In , Jon Severinsson (jon-severinsson) wrote :

bjoern: Thanks for the tip. It solved the problem for me on two out of three shares.

Just a warning though: According to the mount.cifs man page you should NOT use this workaround if your share spans more than one disk partition on the server, as that would give you duplicate inode numbers on the client (two files, same mount, same inode number = trouble).

Revision history for this message
In , Danielstefanmader (danielstefanmader) wrote :

Any news on thuis issue? This bug is still not fixed in 4.1.3 which is an annoyance since it seriously affects networking experience. I would very much appreciate any improvements here!

Revision history for this message
In , Peter-penz19 (peter-penz19) wrote :

@David: The issue has already 100 votes, should we apply your patch in the meantime? It's unclear for me currently until when Dirk can apply his patch.

Revision history for this message
In , Danielstefanmader (danielstefanmader) wrote :

May I ask which Dirk that would be? Dirk Müller from the openSUSE team? If so, please bug him a little more to apply his patch! Thank you very much!

Revision history for this message
In , Mueller-kde (mueller-kde) wrote :

Porting the patch to 4.2 and 4.1 branch.

Revision history for this message
In , Solo0815 (triple-x) wrote :

The Bug is not fixed in 4.2RC1. Hopefully it's fixed until the final version. Thx in advance.

Revision history for this message
In , jofko (jofko) wrote :

just adding console output:

dolphin(5786)/kio (KDirListerCache) KDirListerCache::forgetDirs: DolphinDirLister(0x8644c38) item moved into cache: KUrl("file:///home/jofko")
dolphin(5786)/kio (KDirListerCache) KDirListerCache::listDir: Listing directory: KUrl("file:///home/jofko/kaktus")
dolphin(5786)/kio (KDirWatch) KDirWatchPrivate::addEntry: Added Dir "/home/jofko/kaktus" for "" ["KDirWatch-2"]
dolphin(5786)/kio (KDirWatch) KDirWatchPrivate::useINotify: trying to use inotify for monitoring
dolphin(5786)/kio (KDirWatch) KDirWatchPrivate::useINotify: inotify successfully used for monitoring
dolphin(5786) MetaDataWidget::setFile: KUrl("file:///home/jofko/kaktus")
dolphin(5786)/kio (KDirListerCache) KDirListerCache::slotResult: finished listing KUrl("file:///home/jofko/kaktus")
dolphin(5786)/kio (KIOJob) KDirModel::indexForUrl: KUrl("file:///home/jofko") not found
dolphin(5786)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
WARNING: Problem deleting stale lockfile /home/jofko/kaktus/.directory.lock
WARNING: Problem deleting stale lockfile /home/jofko/kaktus/.directory.lock

Revision history for this message
In , Mueller-kde (mueller-kde) wrote :

SVN commit 915410 by mueller:

add a workaround for cifs/samba 2.x oddity. better
fix in trunk.
BUG: 156759

 M +3 -1 klockfile_unix.cpp

WebSVN link: http://websvn.kde.org/?view=rev&revision=915410

Revision history for this message
In , Danielstefanmader (danielstefanmader) wrote :

Only partially fixed here in 4.2 from http://download.opensuse.org/repositories/KDE:/KDE4:/Factory:/Desktop/openSUSE_11.1/

As it seems, it works OK in smaller shares but still crashes Dolphin in larger folders:

mader@santenay:/home/02_optstaff> dolphin -v
Qt: 4.4.3
KDE: 4.2.00 (KDE 4.2.0) "release 83.1"
Dolphin: 1.2
mader@santenay:/home/02_optstaff> dolphin
"/usr/bin/dolphin(14480)" Error in thread 140428661770064 : "org.freedesktop.DBus.Error.ServiceUnknown - The name org.kde.nepomuk.services.nepomukstorage was not provided by any .service files"
"/usr/bin/dolphin(14480)" Error in thread 140428661770064 : "QLocalSocket::connectToServer: Invalid name"
dolphin(14480): Attempt to use QAction "close_tab" with KXMLGUIFactory!
dolphin(14480): Attempt to use QAction "show_info_panel" with KXMLGUIFactory!
dolphin(14480): Attempt to use QAction "show_folders_panel" with KXMLGUIFactory!
dolphin(14480): Attempt to use QAction "show_terminal_panel" with KXMLGUIFactory!
dolphin(14480): Attempt to use QAction "show_places_panel" with KXMLGUIFactory!
mader@santenay:/home/02_optstaff> WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock
WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock
WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock
WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock
WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock
WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock
WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock
WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock
WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock
WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock
WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock
WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock
WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock
WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock
WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock
WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock
WARNING: Problem deleting stale lockfile /home/02_optstaff/.directory.lock
[...]

Revision history for this message
In , Jux (jux) wrote :

I can not confirm this - I've created 10k files for testing purposes and everything works fine. My files are at 0byte size (maybe that's the reason why it works?). But it seems not to depend on the amount of files ...

for i in `seq 1 10000` ; do touch $i ; done

Qt: 4.4.3
KDE: 4.2.00 (KDE 4.2.0) "release 88.2"
Dolphin: 1.2

Revision history for this message
In , Danielstefanmader (danielstefanmader) wrote :

Dirk confirmed yesterday that the patch is incomplete. It does not depend on the amount of files or the size of the share, though. The problem persists with an existing .directory.lock file in the respective share. Deleting it was a workaround for me, but Dirk wants to fix the stale lock issue completely and reassigned it to him.

https://bugzilla.novell.com/show_bug.cgi?id=414339

Revision history for this message
Yuriy Kozlov (yuriy-kozlov) wrote :

Confirmed by upstream report, looks like it's being worked on there and is partially fixed.

Changed in kdebase (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Changed in kdebase:
status: Unknown → Fix Released
Revision history for this message
Jonathan Thomas (echidnaman) wrote :

Would be best to pursue further problems upstream at bugs.kde.org.

Changed in kdebase (Ubuntu):
status: Triaged → Fix Released
Revision history for this message
In , psych787 (psych787) wrote :

I can also confirm this bug. However, in my case appears to show up when accessing root UNIX shares and there is no accessible .directory.lock file.

This bug not only freezes dolphin but also all applications which are trying to access the share (including konsole windows). Worse, many of these processes (including dolphin) share instances, and *cannot be terminated even by SysRq commands*. As a result, rebooting is necessary.

This is a severe bug, and needs to be treated as such.

Changed in kdebase:
importance: Unknown → High
Revision history for this message
In , Ivost-v (ivost-v) wrote :

I even have this problem with Dolphin 16.04.1

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.