[Dovecot] dovecot servers hanging with fuse/glusterfs errors

[Jordi Moles]

hi,

actually, squirrelmail is not mounting any fuse device. You are right... 
why? :) it's all stored in a database.

as for the cheap hardware.... i'm using virtual machines from Xen to 
build both nodes and clients. The thing is that i've already tried to 
run nodes and dovecots in non-virtual servers, but i get the same error 
sooner or later.

Finally, thanks to help of the people in the glusterfs channel on the 
IRC, i upgraded all the packages to the latest development version and 
i'll let you know if that works for me.

Thank you all.


En/na Bill Cole ha escrit:
> At 11:10 AM +0100 1/28/08, Jordi Moles wrote:
>> hi.
>>
>> i've got a clustered mail system with glusterfs and some postfix, 
>> squirrelmail and dovecot machines sharing the same storage system 
>> through glusterfs.
>
> Why?
>
> I can see the Postfix/Dovecot justification (barely) but it seems 
> pointless for SquirrelMail. What storage does SquirrelMail share with 
> the other types of machines, and why? Since SquirrelMail normally 
> accesses mail only via IMAP, there's no point in making the back end 
> of the IMAP server visible to it.
>
>
>> each server has only postfix or squirrel or dovecot installed on it.
>> The thing is... dovecot servers hang very often and the last thing 
>> they always log is this:
>>
>> *************
>>
>> login: Unable to handle kernel paging request at 0000000000100108 RIP:
>> [<ffffffff88020838>] :fuse:request_end+0x45/0x109
>> PGD 1f729067 PUD 1faae067 PMD 0
>> Oops: 0002 [1] SMP
>> CPU 0
>> Modules linked in: ipv6 fuse dm_snapshot dm_mirror dm_mod
>> Pid: 678, comm: glusterfs Not tainted 2.6.18-xen #1
>> RIP: e030:[<ffffffff88020838>]  [<ffffffff88020838>] 
>> :fuse:request_end+0x45/0x109
>> RSP: e02b:ffff88001f04dd68  EFLAGS: 00010246
>> RAX: 0000000000200200 RBX: ffff88001db9fa58 RCX: ffff88001db9fa68
>> RDX: 0000000000100100 RSI: ffff88001db9fa58 RDI: ffff88001f676400
>> RBP: ffff88001f676400 R08: 00000000204abb00 R09: ffff88001db9fb58
>> R10: 0000000000000008 R11: ffff88001f04dcf0 R12: 0000000000000000
>> R13: ffff88001db9fa90 R14: ffff88001f04ddf8 R15: 0000000000000001
>> FS:  00002b29187c53b0(0000) GS:ffffffff804cd000(0000) 
>> knlGS:0000000000000000
>> CS:  e033 DS: 0000 ES: 0000
>> Process glusterfs (pid: 678, threadinfo ffff88001f04c000, task 
>> ffff88001fc5a860)
>> Stack:  ffff88001db9fa58 ffff88001f676400 00000000fffffffe 
>> ffffffff88021056
>> ffff88001f04def8 000000301f04de88 ffffffff8020dd40 ffff88001f04ddb8
>> ffffffff80225ca3 ffff88001de23500 ffffffff803ef023 ffff88001f04de98
>> Call Trace:
>> [<ffffffff88021056>] :fuse:fuse_dev_readv+0x385/0x435
>
> This is almost certainly a bug in the kernel proper, the fuse module, 
> or possibly the glusterfs client. If you're using cheap hardware it 
> could also be caused by a hardware issue like an intermittent memory 
> failure. This failure is at too low a level to be the fault of a 
> misbehaving application.
>
> [...]
>
>> these are basic debian etch brand new set ups, they have nothing else 
>> than dovecot and glusterfs-client installed on them. The thing is all 
>> machines i've got have the very same version of glusterfs-client, but 
>> only the dovecot ones hang.
>>
>> Do you have any idea?
>
> The same failure across multiple machines implies a problem in 
> software, not hardware.
>
> The fact that Dovecot is poking this bug where postfix and 
> squirrelmail are not is not particularly surprising, and doesn't 
> really indicate a Dovecot flaw. A mailstore server like Dovecot makes 
> more complex demands for proper behavior from a filesystem than an MTA 
> like Postfix.
>
>
>