On 08/08/15 11:04, Carsten Schoenert wrote: > 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. >
I don't think it is reasonable to expect Icedove to diagnose specific problems with NFS However: - when I tried to create a new profile, the Icedove window would just freeze. At the very least, it should have some timeout and display some popup saying "Couldn't get lock" or whatever it was trying to do. - when I tried to run it with the existing profile, it was making connections to the server, then it realized it needed the password and then it appears that it tried to access the signons.sqlite file, couldn't get a lock and just gave up without informing me. Then it logged the message saying "password prompt failed or user canceled it". That is misleading. The log message should have said something like "couldn't lock signons.sqlite" and maybe that should have displayed a popup too. In both cases, I wouldn't expect Icedove to know why the lock is failing (e.g. the NFS server filling up /var) but it should tell the user that some locking operation failed and they should contact their sysadmin or whatever. >> 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. > I agree these problems are not specific to Icedove and they are upstream issues. I'm happy to go and put them in upstream Bugzilla, did you ever see anything like this in there already? Regards, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
