[Dovecot] dovecot bug - kevent(EV_DELETE, 9)
Sorry for my english.
FreeBSD 7.0-STABLE
dovecot-1.1.2_1 (from ports with LDAP)
AD LDAP на Win 2003 SP2 (work via GK)
CPU 2xIntel XEON
NFS not used
LDAP part of dovecot.conf (if you need all file, l'll send it):
auth default {
mechanisms = plain login
passdb ldap {
args = /usr/local/etc/dovecot-ldap.conf
}
userdb ldap {
args = /usr/local/etc/dovecot-ldap.conf
}
user = nobody
count = 1
ssl_require_client_cert = no
ssl_username_from_cert = no
#Postfix Auth
socket listen {
client {
path = /var/spool/postfix/private/auth
mode = 0660
user = postfix
group = postfix
}
}
}
Whole dovecot-ldap.conf:
hosts = 192.168.8.5:3268 192.168.8.6:3268
dn = CN=SomeUser,OU=SomeOU,DC=domain,DC=ru
dnpass = password
tls = no
debug_level = 0
auth_bind = yes
ldap_version = 3
base = DC=domain,DC=ru
deref = never
scope = subtree
user_filter =
((mail=%u)(objectclass=user)(memberOf=CN=Mail,OU=SomeOU,DC=domain,DC=ru))
pass_filter =
((mail=%u)(objectclass=user)(memberOf=CN=Mail,OU=SomeOU,DC=domain,DC=ru))
default_pass_scheme = CRYPT
My problem.
dovecot works fine with AD! but i have this in logs (This not nice,
but no more):
Aug 14 02:21:03 somecomp dovecot: auth(default): LDAP: Connection lost to LDAP
server, reconnecting
Aug 14 02:21:03 somecomp dovecot: auth(default): kevent(EV_DELETE, 9) failed:
Bad file descriptor
Aug 14 02:36:04 somecomp dovecot: auth(default): LDAP: Connection lost to LDAP
server, reconnecting
Aug 14 02:36:04 somecomp dovecot: auth(default): kevent(EV_DELETE, 9) failed:
Bad file descriptor
Aug 14 02:51:04 somecomp dovecot: auth(default): LDAP: Connection lost to LDAP
server, reconnecting
Aug 14 02:51:04 somecomp dovecot: auth(default): kevent(EV_DELETE, 9) failed:
Bad file descriptor
Aug 14 03:06:05 somecomp dovecot: auth(default): LDAP: Connection lost to LDAP
server, reconnecting
Aug 14 03:06:05 somecomp dovecot: auth(default): kevent(EV_DELETE, 9) failed:
Bad file descriptor
Aug 14 03:21:05 somecomp dovecot: auth(default): LDAP: Connection lost to LDAP
server, reconnecting
Aug 14 03:21:05 somecomp dovecot: auth(default): kevent(EV_DELETE, 9) failed:
Bad file descriptor
Aug 14 03:36:06 somecomp dovecot: auth(default): LDAP: Connection lost to LDAP
server, reconnecting
Aug 14 03:36:06 somecomp dovecot: auth(default): kevent(EV_DELETE, 9) failed:
Bad file descriptor
docecot was launched with debug_level = -1 in dovecot.conf. If you
need this log (it's very big) - i send it too. But i don't see in it
something new (dovecot check connection when it lost and succesefully
reconnecting to AD LDAP).
I want to know:
What this event means?
Can i fix it and what to fix?
Re: [Dovecot] Cyrus vs Dovecot
On Wed, 13 Aug 2008, Wesley Craig wrote: On 13 Aug 2008, at 10:31, kbajwa wrote: I think you are missing a point which is most important, i.e., what type of support Cyrus vs Dovecot offers. In my experience: Cyrus = 0 Dovecot= 100 As someone who answers many help requests for cyrus (and I'm very far from the only one), I can honestly say I've never seen a requests from you. Perhaps you've had a lot of occasion to ask for help with Dovecot. I'm happy to hear you've gotten that help. Community is a lot of what open source software is about. As for your experience with the cyrus imapd community, perhaps your sample size is too small. Or perhaps you're thinking of paid support? Because I know very well that you can get that for cyrus imap. can you provide links to where from? David Lang
[Dovecot] PAM session closes too soon
Hi. I'm trying to keep most of my data encrypted when possible, only keeping the decryption key in memory (and thus vulnerable to local attacks) when I'm actually using my data. In practice, this means using pam_mount to mount my home directory from an encrypted device. It almost looked like I could get this to work with mail as well, even when read via IMAP from a remote client: I placed my mail in the encrypted home directory, added pam_mount to /etc/pam.d/dovecot, and set session=yes in Dovecot's PAM configuration. Except that it didn't, quite: pam_mount worked just fine and mounted the encrypted disk using the IMAP password... and then immediately unmounted it, since for some reason session=yes means that Dovecot closes the session _immediately_ after opening it. This seems just silly. If a PAM session is to be used, then it seems obvious to me that its length should be exactly the length of the IMAP session. I can't see any reason for the current behavior, except maybe that it was a bit simpler to code and is sufficient for pam_mkhomedir (and only that). Can this be fixed with reasonable effort? Also, for pam_mount to work correctly, there must not be any file descriptors open in the mounted file system when the session closes, as otherwise unmounting is impossible. Will dovecot release all fds into the mail and index files when the session ends, or can it be made to do so? (UTSL is an acceptable answer.) Thanks in advance. Lauri Alanko [EMAIL PROTECTED]
Re: [Dovecot] Error 89
Many thanks for the patch Got a clear error message this time. Dovecot had not been built with PAM support Starts up OK now, although still not working as I had hoped; may have to post again At 19:14 12/08/2008, you wrote: On Aug 8, 2008, at 3:55 AM, Hodges wrote: Just installed dovecot 1.1.2. downloaded from dovecot.org. Seemed to compile and install OK but I get the following error when I try to start it child 28410 (auth) returned error 89 (fatal failure) This shows that dovecot-auth process exited. Doesn't it show any other error message before that line? There was a bug related to the logging though, this patch should help for it: http://hg.dovecot.org/dovecot-1.1/rev/1dc2dd3cd902
Re: [Dovecot] PAM session closes too soon
On Aug 16, 2008, at 12:59 PM, Lauri Alanko wrote: Except that it didn't, quite: pam_mount worked just fine and mounted the encrypted disk using the IMAP password... and then immediately unmounted it, since for some reason session=yes means that Dovecot closes the session _immediately_ after opening it. This seems just silly. If a PAM session is to be used, then it seems obvious to me that its length should be exactly the length of the IMAP session. I can't see any reason for the current behavior, except maybe that it was a bit simpler to code and is sufficient for pam_mkhomedir (and only that). The session=yes documentation says it does that, which is why it's optional and disabled by default. Can this be fixed with reasonable effort? I don't really see how. PAM code is in dovecot-auth which keeps track of sessions only as long as users are being authenticated. Changing that doesn't seem like a very good idea and could cause a lot of extra potential problems. Moving only the PAM session handling (or closing) code to post-login imap/pop3 process code could work, but is it possible? Also, for pam_mount to work correctly, there must not be any file descriptors open in the mounted file system when the session closes, as otherwise unmounting is impossible. Will dovecot release all fds into the mail and index files when the session ends, or can it be made to do so? (UTSL is an acceptable answer.) If PAM session handling code was moved to imap/pop3 process then yes, the fds are all cleanly closed. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] dovecot: Fatal: Time just moved backwards by 3603 seconds.
On 8/15/2008, Daniel L. Miller ([EMAIL PROTECTED]) wrote: Umdo you have a UPS? If not - get one! Are you running running an ntp server? I'm assuming not. It's time to start. He doesn't need an ntp server, he needs to be running an ntp CLIENT... But first he needs to fix his hardware clock problem if this is a production server. -- Best regards, Charles
Re: [Dovecot] Simplest (static?) build config for loopback access?
2) The Dovecot I built on OS X 10.4 appears to work fine when copied on another Mac running 10.5. Now, I'd love to avoid installing developer tools on both machines, but I fear this an illusion (some libraries are changing under us, e.g. libiconv.2.2.0.dylib -- libiconv.2.4.0.dylib). Does this mean I should try a static build? If so, what are the flags and how do I go about specifying a minimal set of libraries to include for my purposes? Sorry to insist, but... Anyone? I guess I'm confused by this line in ./configure --help: --enable-static[=PKGS] build static libraries [default=yes] Does this mean that my build has (by default) all libraries statically linked, so that there is no problem at all? Francois Z.
[Dovecot] Dovecot 1.1.2, index_mailbox_set_recent_seq crash again
Hi folks, after about 3 weeks without any problems, I've found this crash in yesterday's logfile (again related to index_mailbox_set_recent_seq): Aug 16 03:39:58 linux dovecot: IMAP(user1): Raw backtrace: imap [0x80cf8e0] - imap [0x80cf93a] - imap [0x80cf26c] - imap [0x809d11a] - imap(index_mailbox_set_recent_seq+0x3e) [0x809d15e] - imap(mbox_sync+0x105d) [0x80823fd] - imap [0x807a454] - imap(index_transaction_commit+0x4e) [0x809ddfe] - imap(cmd_copy+0x35f) [0x805b26f] - imap(cmd_uid+0x59) [0x805f3d9] - imap [0x805fd7c] - imap [0x805fe25] - imap [0x80605e5] - imap(client_input+0x5e) [0x80607fe] - imap(io_loop_handler_run+0x100) [0x80d7230] - imap(io_loop_run+0x28) [0x80d63c8] - imap(main+0x4a1) [0x8068321] - /lib/libc.so.6(__libc_start_main+0xe0) [0x149390] - imap [0x805a101] I don't know what IMAP operation caused that crash. The client (Thunderbird 2.0.0.16) silently reconnected without any notification. No obvious problems since yesterday. Dovecot 1.1.2 is running on Fedora 8 Linux 32 Bit with all patches and custom OpenSSL 0.9.8h. [ output of dovecot -n ] # 1.1.2: /usr/local/dovecot/etc/dovecot.conf ssl_cert_file: /usr/local/dovecot/etc/dovecot.crt ssl_key_file: /usr/local/dovecot/etc/dovecot.key login_dir: /usr/local/dovecot/var/run/dovecot/login login_executable: /usr/local/dovecot/libexec/dovecot/imap-login mail_location: mbox:~/Mail:INBOX=/var/spool/mail/%u auth default: mechanisms: plain login digest-md5 cram-md5 passdb: driver: passwd-file args: /usr/local/dovecot/etc/dovecot.passwd userdb: driver: passwd-file args: /usr/local/dovecot/etc/dovecot.passwd Greetings, Andreas
Re: [Dovecot] Dovecot 1.1.2, index_mailbox_set_recent_seq crash again
Some minutes ago I wrote: after about 3 weeks without any problems, I've found this crash in yesterday's logfile (again related to index_mailbox_set_recent_seq): Aug 16 03:39:58 linux dovecot: IMAP(user1): Raw backtrace: imap [0x80cf8e0] - imap [0x80cf93a] - imap [0x80cf26c] - imap [0x809d11a] - imap(index_mailbox_set_recent_seq+0x3e) [0x809d15e] - imap(mbox_sync+0x105d) [0x80823fd] - imap [0x807a454] - imap(index_transaction_commit+0x4e) [0x809ddfe] - imap(cmd_copy+0x35f) [0x805b26f] - imap(cmd_uid+0x59) [0x805f3d9] - imap [0x805fd7c] - imap [0x805fe25] - imap [0x80605e5] - imap(client_input+0x5e) [0x80607fe] - imap(io_loop_handler_run+0x100) [0x80d7230] - imap(io_loop_run+0x28) [0x80d63c8] - imap(main+0x4a1) [0x8068321] - /lib/libc.so.6(__libc_start_main+0xe0) [0x149390] - imap [0x805a101] And just again, this time with Pine 4.64 (different user) when saving a mail from INBOX to a folder: Aug 17 05:38:02 linux dovecot: IMAP(user2): Raw backtrace: imap [0x80cf8e0] - imap [0x80cf93a] - imap [0x80cf26c] - imap [0x809d11a] - imap(index_mailbox_set_recent_seq+0x3e) [0x809d15e] - imap(mbox_sync+0x105d) [0x80823fd] - imap [0x807a454] - imap(index_transaction_commit+0x4e) [0x809ddfe] - imap(cmd_copy+0x35f) [0x805b26f] - imap [0x805fd7c] - imap [0x805fe25] - imap [0x80605e5] - imap(client_input+0x5e) [0x80607fe] - imap(io_loop_handler_run+0x100) [0x80d7230] - imap(io_loop_run+0x28) [0x80d63c8] - imap(main+0x4a1) [0x8068321] - /lib/libc.so.6(__libc_start_main+0xe0) [0x149390] - imap [0x805a101] Greetings, Andreas
Re: [Dovecot] Dovecot 1.1.2, index_mailbox_set_recent_seq crash again
Hi folks! Aug 16 03:39:58 linux dovecot: IMAP(user1): Raw backtrace: imap [0x80cf8e0] - imap [0x80cf93a] - imap [0x80cf26c] - imap [0x809d11a] - imap(index_mailbox_set_recent_seq+0x3e) [0x809d15e] - imap(mbox_sync+0x105d) [0x80823fd] - imap [0x807a454] - imap(index_transaction_commit+0x4e) [0x809ddfe] - imap(cmd_copy+0x35f) [0x805b26f] - imap(cmd_uid+0x59) [0x805f3d9] - imap [0x805fd7c] - imap [0x805fe25] - imap [0x80605e5] - imap(client_input+0x5e) [0x80607fe] - imap(io_loop_handler_run+0x100) [0x80d7230] - imap(io_loop_run+0x28) [0x80d63c8] - imap(main+0x4a1) [0x8068321] - /lib/libc.so.6(__libc_start_main+0xe0) [0x149390] - imap [0x805a101] And just again, this time with Pine 4.64 (different user) when saving a mail from INBOX to a folder: Aug 17 05:38:02 linux dovecot: IMAP(user2): Raw backtrace: imap [0x80cf8e0] - imap [0x80cf93a] - imap [0x80cf26c] - imap [0x809d11a] - imap(index_mailbox_set_recent_seq+0x3e) [0x809d15e] - imap(mbox_sync+0x105d) [0x80823fd] - imap [0x807a454] - imap(index_transaction_commit+0x4e) [0x809ddfe] - imap(cmd_copy+0x35f) [0x805b26f] - imap [0x805fd7c] - imap [0x805fe25] - imap [0x80605e5] - imap(client_input+0x5e) [0x80607fe] - imap(io_loop_handler_run+0x100) [0x80d7230] - imap(io_loop_run+0x28) [0x80d63c8] - imap(main+0x4a1) [0x8068321] - /lib/libc.so.6(__libc_start_main+0xe0) [0x149390] - imap [0x805a101] Additional information: Saving the mail to the given folder didn't succeed and the mail was still in the INBOX (thus, no mail lost). Once more (saving mail from INBOX to folder with Pine 4.64): Aug 17 05:43:47 linux dovecot: IMAP(user2): Raw backtrace: imap [0x80cf8e0] - imap [0x80cf93a] - imap [0x80cf26c] - imap [0x809d11a] - imap(index_mailbox_set_recent_seq+0x3e) [0x809d15e] - imap(mbox_sync+0x105d) [0x80823fd] - imap [0x807a454] - imap(index_transaction_commit+0x4e) [0x809ddfe] - imap(cmd_copy+0x35f) [0x805b26f] - imap [0x805fd7c] - imap [0x805fe25] - imap [0x80605e5] - imap(client_input+0x5e) [0x80607fe] - imap(io_loop_handler_run+0x100) [0x80d7230] - imap(io_loop_run+0x28) [0x80d63c8] - imap(main+0x4a1) [0x8068321] - /lib/libc.so.6(__libc_start_main+0xe0) [0x149390] - imap [0x805a101] This time, the mail was successfully saved to the folder, but it was also still in the INBOX (doubled mail). Well, better than mail loss (corrupted folders) as in Dovecot 1.1.0/1.1.1. Still don't know how to reproduce this. With Thunderbird it's hard to notice at all if you don't look at the logfile all the time. Enabling mail_debug doesn't seem to give much useful information on such type of problem. Is there anything I can do to collect useful data without watching the logfile in realtime all day long? Greetings, Andreas
