Re: [Dovecot] v1.1.alpha4 released / about dbox

2007-09-22 Thread Timo Sirainen
On Mon, 2007-09-10 at 01:04 +0200, luciano mannucci wrote:
> dovecot: Sep 09 20:32:31 Fatal: execv(/usr/libexec/dovecot/pop3- 
> login) failed: T
> oo many open files
> dovecot: Sep 09 20:32:31 Fatal: execv(/usr/libexec/dovecot/imap- 
> login) failed: T
> oo many open files
> in the log file and no one is able to access the mail.
> I reverted to alpha3 and everything is working fine now.

alpha5 should have fixed this.



signature.asc
Description: This is a digitally signed message part


Re: [Dovecot] v1.1.alpha4 released / about dbox

2007-09-09 Thread luciano mannucci


On Sep 8, 2007, at 3:08, Timo Sirainen wrote:


Lots of fixes since alpha3.

I tried it on a SuSE 10.2, running alpha 3.
Same configure, same config files.
I'm getting a lot of:
dovecot: Sep 09 20:32:31 Fatal: execv(/usr/libexec/dovecot/pop3- 
login) failed: T

oo many open files
dovecot: Sep 09 20:32:31 Fatal: execv(/usr/libexec/dovecot/imap- 
login) failed: T

oo many open files
in the log file and no one is able to access the mail.
I reverted to alpha3 and everything is working fine now.

My dovecot -n (seen from the alpha3) looks like this:
baobab:/var/log/dovecot # dovecot -n
# 1.1.alpha3: /etc/dovecot.conf
log_path: /var/log/dovecot/logfile
info_log_path: /var/log/dovecot/logfile.info
protocols: imap imaps pop3 pop3s
ssl_listen: *
ssl_ca_file: /etc/ssl/ca.crt
disable_plaintext_auth: no
login_dir: /var/run/dovecot/login
login_executable(default): /usr/libexec/dovecot/imap-login
login_executable(imap): /usr/libexec/dovecot/imap-login
login_executable(pop3): /usr/libexec/dovecot/pop3-login
login_greeting: Dovecot at Baobab ready.
login_max_processes_count: 512
first_valid_uid: 100
first_valid_gid: 0
mail_location: mbox:/var/spool/mailboxes/%u:INBOX=/var/spool/mail/%u
maildir_copy_with_hardlinks: no
mail_executable(default): /usr/libexec/dovecot/imap
mail_executable(imap): /usr/libexec/dovecot/imap
mail_executable(pop3): /usr/libexec/dovecot/pop3
mail_plugins(default): quota imap_quota
mail_plugins(imap): quota imap_quota
mail_plugins(pop3): quota
mail_plugin_dir(default): /usr/lib/dovecot/imap
mail_plugin_dir(imap): /usr/lib/dovecot/imap
mail_plugin_dir(pop3): /usr/lib/dovecot/pop3
imap_client_workarounds(default): outlook-idle delay-newmail
imap_client_workarounds(imap): outlook-idle delay-newmail
imap_client_workarounds(pop3):
pop3_enable_last(default): no
pop3_enable_last(imap): no
pop3_enable_last(pop3): yes
pop3_client_workarounds(default):
pop3_client_workarounds(imap):
pop3_client_workarounds(pop3): outlook-no-nuls oe-ns-eoh
auth default:
  mechanisms: plain login
  cache_size: 3072
  username_format: %Lu
  verbose: yes
  debug: yes
  debug_passwords: yes
  passdb:
driver: pam
  userdb:
driver: passwd
  socket:
type: listen
client:
  path: /var/spool/postfix/private/auth
  mode: 432
  user: postfix
  group: postfix
plugin:
  quota: maildir::dirsize
  quota_rule: *:storage=300M

luciano.
--
 /"\ /Via A. Salaino, 7 - 20144 Milano (Italy)
 \ /  ASCII RIBBON CAMPAIGN / PHONE : +39 2 485781 FAX: +39 2 48578250
  X   AGAINST HTML MAIL/  E-MAIL: [EMAIL PROTECTED]
 / \  AND POSTINGS/   WWW: http://www.mannucci.ORG/




Re: [Dovecot] v1.1.alpha4 released / about dbox

2007-09-09 Thread Farkas Levente

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 ": " 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] v1.1.alpha4 released / about dbox

2007-09-08 Thread Timo Sirainen
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 ": " 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. :)



signature.asc
Description: This is a digitally signed message part


Re: [Dovecot] v1.1.alpha4 released / about dbox

2007-09-08 Thread David Favor

It appears configure.in is still set to 1.1.alpha3 instead of alpha4.

Great work on the dbox implementation.

- David

--
Love feeling your best ever, all day, every day?
Email [EMAIL PROTECTED] for the easy way.


Re: [Dovecot] v1.1.alpha4 released / about dbox

2007-09-08 Thread Farkas Levente
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?

-- 
  Levente   "Si vis pacem para bellum!"


[Dovecot] v1.1.alpha4 released / about dbox

2007-09-07 Thread Timo Sirainen
http://dovecot.org/releases/1.1/alpha/dovecot-1.1.alpha4.tar.gz
http://dovecot.org/releases/1.1/alpha/dovecot-1.1.alpha4.tar.gz.sig

Lots of fixes since alpha3. Also includes the dbox rewrite. Currently
dbox works properly only in one-message-per-file mode. I'm not actually
even sure how good idea it would be to use it with
multiple-messages-per-file mode. But I guess it won't hurt to finish its
implementation and see. :)

As you can see I haven't been replying much to the mailing list lately.
My school started again, which meant that I had to start sleeping again
at night instead of at day :) Doing that always takes a few weeks of
feeling too tired to get much of anything done. Hopefully that goes away
soon.

A bit more about dbox:

Originally I had thought that it'd be good to have multiple messages per
file. The bad thing about that is that it works badly without fcntl
locks, which don't work all that great with NFS. So I changed my plans a
bit so that dbox also supports one-message-per-file behavior where it
doesn't need locking much. (Multiple-messages-per-file is still
supported by the format, but currently the code is not fully working.)

dbox files begin with a header, then they have the message data and at
the end of file there's a metadata block. Metadata contains things like
message flags, keywords, received date and so on.

When a flag/keyword is updated, the change is normally done only to
index files. This is why dovecot.index and dovecot.index.log files are
important with dbox format, they contain flag changes that haven't been
written anywhere else.

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.


signature.asc
Description: This is a digitally signed message part