Version: 4.7 (using KDE 4.7.4) OS: Linux After running a KDE session for a long time (>48h), the gam_server/gamin file alteration monitor daemon acts up when accessing a local maildir akonadi resource, either through KMail/Kontact or the akonadiconsole browser. A restart of akonadi via akonadictl restart does not help, the problem persists. Logging out of KDE is the only way to solve it. It can easily be fixed, however, by killing the gam_server process (which will immediately be restarted automatically). 15 is ok, the daemon itself is not locked up. Reproducible: Sometimes Steps to Reproduce: 1. Have KMail/Kontact running for a day or two with a local maildir akonadi resource configured. 2. At some point all access to the mails in the maildir folders will stall, while imap and/or pop will continue to work as usual. Actual Results: Access to mails in maildir resources ceases, along with filters moving or copying mails to them. Expected Results: Maildir should continue working. This might be an openSuse-specific issue, but I'm not sure. Killing the daemon cleanly resolves it, however, so for the moment I settled for a small script in .kde/Autostart that kills it every hour.
Maildir indeed sets up quite some folder watchers (3 watches per mail folder). What do you see with the gam_server, does it start to use the CPU? I also have openSUSE, but didn't notice this behavior yet. BTW, file monitoring can be disabled, the easiest way is through akonadiconsole, select the account on Agents tab, right click and Configure->Configure Remotely. You might need to restart the agent. Disabling it means that files delivered to the maildir folder from a different application will not be recognized unless you do a full synchronization of the account.
No, the gam_server doesn't seem to be using up any cpu at all, and not much memory either. And it's only one process. The file monitoring is already disabled for any local maildir resources, as there are no other processes touching it. I found, however, that while the maildir resource will resume working correctly after killing the gam_server (and it being respawned automatically), the virtuoso-t process will still use up 100% cpu and lots of memory until akonadi is restartet. Then it takes some moments till virtuoso is down to idle again and stays there. This, however, will only work if the gam_server was killed shortly before restarting akonadi. Otherwise, nothing will change and virtuoso will continue hogging the cpu. System is now on KDE 4.8.0 and this still applies.
Ah, then this looks to be the nepomuk/virtuoso bug... I don't know now the bug report number for it, but it was reported several times on different places. I also keep my nepomuk disabled because of it.
Can you please test it in KDE 4.10.1? There was a bug related to file watching and leaking file descriptors(a bug in Qt) that is workarounded now. I'd like to know if this fixes your bug.
It doesn't seem to happen with 4.10 anymore, so marking it as fixed.
This bug has had its resolution changed, but accidentally has been left in NEEDSINFO status. I am thus closing this bug and setting the status as RESOLVED to reflect the resolution change.