On Fri, Aug 07, 2015 at 01:09:13PM +0200, Daniel Pocock wrote: > Ok, I finally found the root cause of this problem > > On the NFS server, dmesg output included the line: > > "lockd: cannot monitor host1" > > repeated many times. It would appear several times each time I tried to > start icedove. > > Looking in other logs, I found that /var had filled up on the NFS server > and this was causing problems for the lockd process to write in > /var/lib/nfs/* > > There had been no other obvious signs of trouble and the lack of > feedback from Icedove and the log line telling me "password prompt > failed or user canceled it" was a distraction from spotting the real > problem.
I'm thinking a sort of different about that. >From a point of view from the application it looks not as it seems on the first sight. Every application must assume that the underlaying parts are working correctly and a fail safe mechanism is doing his job right. So Icedove can't do anything on the filesystem side (and hasen't to do that!), for Icedove it doesn't matter if you are working on a local harddisk or a network filesystem. On the other hand a network FS has other properties than a FS on a local disk. But that has to be handled by FS implementation. So what should Icedove/Thunderbird doing here? It's some kind of blind on the eyes for normal reasons. Maybe some small messages from Icedove could be improved but I don't think there is much to do here. Feel free to open requests on the Mozilla Bugtracker. > So, Icedove is not specifically broken, it is just giving really > inadequate feedback in the case of problems like this. It's no hard issue to blame on Icedove, I lowered down the severity of this report to important. Regards Carsten -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
