Re: [Dovecot] PAM child process timed out, killing it.
Tere. Your PAM modules are getting stuck. Probably has nothing to do with Dovecot itself. But I haven't change/install/upgrade anything, but the Dovecot. And version 1.0.3 gives errors like crazy, 1.0.2 from time to time and older versions none? Seems something in new Dovecot versions drives PAM crazy. What userdb do you use? Hmm, passwd, dovecot -n: auth default: verbose: yes worker_max_count: 90 process_size: 512 passdb: driver: pam userdb: driver: passwd You could try adding blocking=yes to passdb pam's args or if you're using userdb passwd add blocking=yes to its args. So either passdb or userdb, but not to both? -- Mart
Re: [Dovecot] PAM child process timed out, killing it.
On 9.9.2007, at 11.00, Mart Pirita wrote: Your PAM modules are getting stuck. Probably has nothing to do with Dovecot itself. But I haven't change/install/upgrade anything, but the Dovecot. And version 1.0.3 gives errors like crazy, 1.0.2 from time to time and older versions none? Seems something in new Dovecot versions drives PAM crazy. The only changes to dovecot-auth between 1.0.2 and 1.0.3 were for LDAP code, which you aren't using. So I think the problem has more to do with the binary getting compiled a bit differently, causing random problems in a buggy PAM module. What userdb do you use? Hmm, passwd, dovecot -n: auth default: verbose: yes worker_max_count: 90 process_size: 512 passdb: driver: pam userdb: driver: passwd So where do PAM and passwd do the lookups from? If you're using pam_ldap+nss_ldap you really need the blocking=yes for them to work right. You could try adding blocking=yes to passdb pam's args or if you're using userdb passwd add blocking=yes to its args. So either passdb or userdb, but not to both? Or both. If you're doing LDAP or other remote lookups it's a good idea to set it to both. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] PAM child process timed out, killing it.
Tere. The only changes to dovecot-auth between 1.0.2 and 1.0.3 were for LDAP code, which you aren't using. So I think the problem has more to do with the binary getting compiled a bit differently, causing random problems in a buggy PAM module. Ok. So where do PAM and passwd do the lookups from? Lookups, hmm, do You mean where passwords are defined and stored. I'm using system accounts, /etc/passwd, /etc/shadow etc.. If you're using pam_ldap+nss_ldap you really need the blocking=yes for them to work right. I'm not using LDAP. Or both. If you're doing LDAP or other remote lookups it's a good idea to set it to both. Ok, I'll try tomorrow version 1.0.4 and blocking=yes in passdb: and userdb: -- Mart
Re: [Dovecot] Courier Migration
Timo Sirainen wrote:
On Fri, 2007-09-07 at 15:20 +0100, Ed W wrote:
Hi
Is it legal/sensible to use the following in the conf file
# default namespace
namespace private {
separator = /
prefix =
inbox = yes
}
# for backwards compatibility:
namespace private {
separator = .
prefix = INBOX.
inbox = yes
hidden = yes
}
Because the second one is hidden, it's legal. But I don't know if there
are compatibility problems with clients. If there are, they most likely
go away by using the same separator with both.
Thanks for the confirmation
Actually are there any advantages in changing separator at all...? I
only wanted to get closer to the default config going forward, but
perhaps it's a pointless goal?
Anyone have any opinions on bugs/features/limitations in changing the
separator and namespace to the dovecot default?
Cheers
Ed W
Re: [Dovecot] v1.1.alpha4 released / about dbox
On Vas, Szeptember 9, 2007 06:01, Timo Sirainen wrote: On Sat, 2007-09-08 at 15:04 +0200, Farkas Levente wrote: Timo Sirainen wrote: But since there's still a chance that index files could break (although v1.1 tries harder than v1.0 to fix problems), it would be nice if the flags/keywords were written to metadata block once in a while. So if the index files are lost, flag changes wouldn't be completely lost. Metadata updates of course use disk I/O so they shouldn't be done too often. I was thinking that the metadata could be updated: - if IMAP connection has been idling for 4 hours (not changing flags) - when closing mailbox and there are changes older than 4h - immediately if there are changes older than 24h (whenever mailbox is being synced, e.g. SELECT/NOOP/STATUS) Or something like that. Those rules can of course be changed, but I'm not sure if I should bother making them configurable from dovecot.conf. There are already too many settings. what about a maintanance srcipt/daemon which can be run from cron and every sysadm can decided when and how often he'd like to update metadatas? That would require keeping the mailbox: last updated information in some central database. Otherwise if you had lots of mailboxes it would waste a lot of disk I/O in such run. And I'm not really interested in creating such a database at least yet. :) than may ber move this code to lda also helps. my main reason to suugest the above is the same why i like lda: try to distribute the system load in time. that's the main problem with indexing at reading time. every morning when most people start to read his mail dovecot start to index all mail which creates high load with lda we distribute this load from mail read time to mail arrival time which is much better place! the same should have to be do with metadata update. somehow distribute the load eg. move to some time which is not so important during the night or move to lda which happend during arrival time in stead of read time or any other place but not during read. --
Re: [Dovecot] IMAP: Disconnected: BUG: Unknown internal error (Dovecot 1.0.x)
Hi, Monday, September 3, 2007, 23:16:07, you wrote: One more piece of info that might (?) be interesting -- I have just run a grep on historical logs and it seems the bug never occured on previous versions of Dovecot I had been running in the past (first it was stock Suse 9.3 Dovecot 0.99.14, then a self-compiled 1.0.rc27). The only difference (apart from the actual source code, of course) between 1.0.rc27 and the current 1.0.3 that might play any role are the configure flags: - 1.0.rc27: ./configure --with-pam - 1.0.3 : ./configure --with-ioloop=best --with-ldap --with-sql --with-mysql --with-pam This resulted in using epoll() for 1.0.3 and poll() for 1.0.rc27; both versions are using dnotify. OK, I am now positive this has nothing to do with epoll() vs. poll() (which was unlikely anyway but I wanted to test it just in case). I have just compiled 1.0.5 with poll() -- which means that its config and compilation options are pretty much the same as with the previous versions -- and the bug occurs again, just as it did with 1.0.3/epoll(). Looking at the backtrace and the code, it seems imap_fetch_deinit() is failing. -- Best regards, Robert Tomanekmailto:[EMAIL PROTECTED]
Re: [Dovecot] imap process consuming 100% CPU (Dovecot 1.0.3)
Hi,
Saturday, September 8, 2007, 2:29:45, you wrote:
0x0806049d in imap_sync_more (ctx=0x80d9770) at imap-sync.c:104
104 if (ctx-seq == 0) {
A short follow-up on this, looks like an infinite loop to me, unless
some threading magic is supposed to happen here:
Fixed: http://hg.dovecot.org/dovecot-1.0/rev/8e86137a04fb
Compiled the new version, so far so good...
Thanks!
--
Best regards,
Robert Tomanekmailto:[EMAIL PROTECTED]
Re: [Dovecot] v1.0.5 released
On Sep 9, 2007, at 12:21 AM, Timo Sirainen wrote: http://dovecot.org/releases/1.0/dovecot-1.0.5.tar.gz http://dovecot.org/releases/1.0/dovecot-1.0.5.tar.gz.sig Just a reminder: http://www.dovecot.org/download.html needs updating to reflect the availability of the new version. B. Bodger New York
Re: [Dovecot] v1.0.5 released
On 9.9.2007, at 13.54, Bruce Bodger wrote: On Sep 9, 2007, at 12:21 AM, Timo Sirainen wrote: http://dovecot.org/releases/1.0/dovecot-1.0.5.tar.gz http://dovecot.org/releases/1.0/dovecot-1.0.5.tar.gz.sig Just a reminder: http://www.dovecot.org/download.html needs updating to reflect the availability of the new version. Thanks, fixed. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] pipe() failed: Too many open files
Thanks, I updated in the meantime to 1.02, which is currently the newest in OpenBSD 4.0 packages. The problem has vanished completely. Performance has gone up in general a lot, too. This is a wonderful programme, thanks Timo, for your hard work and for responding to a newbie's question Peter Timo Sirainen wrote: On Fri, 2007-08-31 at 22:50 +0100, peter wrote: I am getting random disconnects from my imap session, dificulties to revconnect, very sluggish behaviour when changing between mail folders also frequent and rapidly repititive messages on te client mailserver x.x.x.x is not a imap4 server I am running dovecot 1.0.rc2 from ports on OpenBSD 4.0 on a PIII, 500MHz 512MB That's a really old version. You should be running v1.0.0 or later. Aug 31 20:51:57 apache dovecot: pipe() failed: Too many open files If the port used --with-ioloop=kqueue, that's the problem. kqueue is a bit buggy with OpenBSD.
[Dovecot] Feature Request for Proxy
Hi, Quick feature request for the proxy function: I have a couple of machines which are all customer facing and customer mailbox lives on any one of them. Customer can login to any machine and the proxy feature then forwards them to the correct machine (often the machine they are already connected to). However, right now if the SQL query simply returns the IP of the correct machine, and this happens to be the same machine that the connection is already on, then we get the auth process stuck in an infinite loop (and generating a lot of log files...) The quick fix is to customise each installation and add some kind of WHERE clause to change the results IF result is already the same as the machine we are on. However, this is error prone when setting up new machines and it's easy to forget or make a typo adjusting the config files. In my case I am using vservers and it's quite neat to be able to simply copy the whole image and fire it up on a new IP to test an upgrade, etc, hence easy to mess up adjusting the conf files when creating a new image. Any suggestions on how this could be done more dynamically, or else could I raise a feature request that the auth process somehow realises when it's being forwarded to an IP address that it's actually listening on already already (ie it's a request which loops back to itself), thus simplifying the config files? I haven't cracked open the code, but it sounds somewhat possible to check the list of IP addresses we are currently listening on and check that the proxy dest isn't among them? Cheers Ed W
Re: [Dovecot] recipient delimiter results in sieve errors
I guess it depends on what your Sieve code looks like? Or does it give
the same error even if your script is only keep;?
It doesn't depend on the script. Even the simplest script stop; gives
this error. I added two debug strings to cmusieve_deliver_mail in
cmusieve-plugin.c:
if (getenv(DEBUG) != NULL) {
i_info(cmusieve: Using mailbox: %s, mailbox);
i_info(cmusieve: Using username: %s, username);
i_info(cmusieve: Using sieve path: %s, script_path);
}
and here are some more details:
deliver([EMAIL PROTECTED]): Info: cmusieve: Using mailbox: test
deliver([EMAIL PROTECTED]): Info: cmusieve: Using username: [EMAIL PROTECTED]
deliver([EMAIL PROTECTED]): Info: cmusieve: Using sieve path:
/home/vmail/.dovecot.sieve
deliver([EMAIL PROTECTED]): Info: cmusieve: Executing script
/home/vmail/.dovecot.sievec
deliver([EMAIL PROTECTED]): Info: sieve runtime error: Keep: Generic Error
That is, if I send a message to [EMAIL PROTECTED], in cmusieve_deliver_mail()
the name of the mailbox is test. For normal address [EMAIL PROTECTED] it is
INBOX:
deliver([EMAIL PROTECTED]): Info: cmusieve: Using mailbox: INBOX
deliver([EMAIL PROTECTED]): Info: cmusieve: Using username: [EMAIL PROTECTED]
Tested with dovecot 1.0.3 and dovecot-sieve 1.0.2.
Regards,
Gregory
[Dovecot] Unexpected input from auth master: CUID
Hello,
I'm using postfix(2.4.5) and dovecot(1.0.5), and till now I have been
using postfix deliver agent. Now I have tried to reconfigure postfix to
use the dovecot LDA, but I'm getting some strange error:
Sep 9 18:07:57 hostname deliver([EMAIL PROTECTED]): BUG: Unexpected
input from auth master: CUID^I5
For IMAP and POP3 my configuration works fine.
I have tried it also with dovecot versions 1.0.4 and 1.0.1, but the
behaviour is the same.
What can be the reason of this? What should I look for to get more
details what can causing this?
I have this line in postfix master file:
dovecot unix - n n - - pipe
flags=DRhu user=mails:mails argv=/opt/dovecot-1.0.5-1/libexec/dovecot/deliver
-f ${sender} -d ${recipient}
In main.cf:
dovecot_destination_recipient_limit = 1
virtual_transport = dovecot
Relevant parts of dovecot.conf:
auth default {
passdb sql {
args = /path/to/dovecot-sql.conf
}
userdb sql {
args = /path/to/dovecot-sql.conf
}
socket listen {
client {
path = /var/run/dovecot/auth-master
mode = 0600
user = mails
group = mails
}
}
}
protocol lda {
postmaster_address = [EMAIL PROTECTED]
auth_socket_path = /var/run/dovecot/auth-master
}
And relevant parts of dovecot-sql.conf:
driver = mysql
password_query = SELECT address as user, passwd as password FROM
mail_users WHERE address='%u'
user_query = SELECT CONCAT('/home/',maildir) as home, 999 as uid, 999 as
gid FROM mail_users WHERE address='%u'
Thanks,
BB
Re: [Dovecot] imap killed with signal 6 (including backtrace)
* Timo Sirainen [EMAIL PROTECTED]: On Sat, 2007-08-18 at 10:31 +0200, Ralf Hildebrandt wrote: * Ralf Hildebrandt [EMAIL PROTECTED]: Maybe it worked, since I see that particular User NOT getting the errors anymore. Seems to be a particular folder he's accessing: Aug 18 09:57:57 postamt dovecot: IMAP(myuser): file strfuncs.c: line 165 (p_strndup): assertion failed: (max_chars != (size_t)-1) Aug 18 09:57:57 postamt dovecot: IMAP(myuser): Raw backtrace: imap [0x80c6d53] - imap(i_fatal+0) [0x80c6795] - imap(p_strndup+0x38) [0x80d8316] - imap(t_strndup+0x22) [0x80d86d7] - imap(cmd_create+0xb5) [0x8059a39] - imap [0x805eb09] - imap Most likely fixed by http://hg.dovecot.org/dovecot-1.0/rev/33690bb286af I checked out 1.0.4 today, I'll have a look. -- Ralf Hildebrandt ([EMAIL PROTECTED]) [EMAIL PROTECTED] Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155 http://www.arschkrebs.de Ballmer should step down in favour of Mr T, because he pity the fool who don't got high-end video cards and 4GB RAM for Vista Aero!
