Hello list,
I have a strange problem with dovecot and quota. The error message is
not obvious...
After a couple of seconds when I try to start dovceot, I get this:
root at taleira:~# /etc/init.d/dovecot start
Alarm clock
If I uncomment the "imap_quota and quota" in dovecot.conf everything
seem to work fine:
protocol imap {
listen = *:143
ssl_listen = *:993
# problem pa taleira01: konstigt...
#mail_plugins = quota imap_quota
mail_plugins }
I can't really figure out what's wrong. There's nothing in the log
and
dovecots error message is not so talkative. It took a while to figure
out that it was the quota that caused the problem. I guess there is
something with the underlying FS, but all kernel modules are loaded as
far as I know. The maildir is on a nfs-mounted disk. The whole system
is on a XEN machine and I have multipe copies of this image running on
other machines with no problem.
Strace gives me:
root at taleira:~# strace dovecot
....
lstat64("/var/run/dovecot//login", {st_mode=S_IFDIR|0750,
st_size=60, ...}) = 0
open("/var/run/dovecot//login", O_RDONLY|O_NONBLOCK|O_LARGEFILE|
O_DIRECTORY|0x80000) = 4
fstat64(4, {st_mode=S_IFDIR|0750, st_size=60, ...}) = 0
getdents64(4, /* 3 entries */, 4096) = 88
lstat64("/var/run/dovecot//login/ssl-parameters.dat",
{st_mode=S_IFREG|
0644, st_size=230, ...}) = 0
getdents64(4, /* 0 entries */, 4096) = 0
close(4) = 0
geteuid32() = 0
pipe([4, 5]) = 0
fcntl64(4, F_GETFD) = 0
fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
fcntl64(5, F_GETFD) = 0
fcntl64(5, F_SETFD, FD_CLOEXEC) = 0
dup(2) = 6
fcntl64(6, F_GETFD) = 0
fcntl64(6, F_SETFD, FD_CLOEXEC) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|
SIGCHLD, child_tidptr=0xf7e666f8) = 3343
close(6) = 0
close(5) = 0
alarm(5) = 0
wait4(-1, 0xffbd7e9c, 0, NULL) = ? ERESTARTSYS (To be
restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---
+++ killed by SIGALRM +++
Process 3342 detached
Finally, my system is:
root at taleira:~# dovecot --version
1.1.4
root at taleira:~# uname -a
Linux taleira 2.6.26-1-xen-amd64 #1 SMP Sat Nov 8 21:20:04 UTC 2008
x86_64 GNU/Linux
Any ideas?
/Magnus
On Dec 12, 2008, at 5:06 PM, Magnus Appelquist wrote:> After a couple of seconds when I try to start dovceot, I get this: > root at taleira:~# /etc/init.d/dovecot start > Alarm clock > If I uncomment the "imap_quota and quota" in dovecot.conf everything > seem to work fineWhat quota backend are you using? fs or maildir?> wait4(-1, 0xffbd7e9c, 0, NULL) = ? ERESTARTSYS (To be > restarted) > --- SIGALRM (Alarm clock) @ 0 (0) --- > +++ killed by SIGALRM +++Dovecot doesn't have any calls to send SIGALRM signals.. If you're using fs quota with NFS rpc calls, that could cause it I guess, although I don't really understand why the signal would be sent to master process instead of just the child process. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20081212/da985125/attachment-0002.bin>
Well, I don't think it matter. Although I'm not sure that I've
configured backend properly and I don't know if one backend excludes
the others (i.e. they may be loaded anyway).
I've tried with three different backend (not at the same time):
plugin {
quota = fs:user
}
plugin {
quota = dirsize:user
quota_rule = *:storage=1024M
}
plugin {
quota = maildir:storage=10240:ignore=Trash
}
All three variants gives me the same behaviour.
/Magnus
12 dec 2008 kl. 16.13 skrev Timo Sirainen:
> On Dec 12, 2008, at 5:06 PM, Magnus Appelquist wrote:
>
>> After a couple of seconds when I try to start dovceot, I get this:
>> root at taleira:~# /etc/init.d/dovecot start
>> Alarm clock
>> If I uncomment the "imap_quota and quota" in dovecot.conf
>> everything seem to work fine
>
> What quota backend are you using? fs or maildir?
>
>> wait4(-1, 0xffbd7e9c, 0, NULL) = ? ERESTARTSYS (To be
>> restarted)
>> --- SIGALRM (Alarm clock) @ 0 (0) ---
>> +++ killed by SIGALRM +++
>
> Dovecot doesn't have any calls to send SIGALRM signals.. If you're
> using fs quota with NFS rpc calls, that could cause it I guess,
> although I don't really understand why the signal would be sent to
> master process instead of just the child process.
>