On Wed, 2009-04-08 at 14:38 -0700, Daniel L. Miller wrote:
Having a consistent name prefix for all the processes sounds nice - but then you'd stick out as the exception to typical multi-process server names (like Postfix's master, smtpd, cleanup, etc.). Is it a Good Thing to deviate from accepted (poor) practices? Hmm....
Other tradeoffs...more space consumed in logfiles. More screen width consumed during listings. Not necessarily a Good Thing - not necessarily a Bad Thing. But something to ponder on.
No, I wouldn't write the dovecot- prefix to log files. So while the binary names would be dovecot-lda, dovecot-imap-login, etc. the logs would contain only lda(user), imap-login(user), etc.
Another thing I was thinking about previously was that in process lists they were prefixed with dovecot/. So the binary names could be lda, imap-login, etc. but they'd show up in process lists as dovecot/lda, dovecot/imap-login, etc.
I would also consider the Dovecot architecture. As I (mis)understand it, the "dovecot" process spawns the necessary imap, pop3, and login daemons. So having a "dovecot.conf" file for controlling these is quite appropriate. However, unless I've missed something (quite likely) - "deliver" has nothing to do with the listening daemons. So having the "lda" configuration in the dovecot.conf file might be inappropriate - I would suggest splitting that off to a "dovecot-lda.conf" file (or whatever you change the delivery agent name to).
But deliver also reads dovecot.conf and inside protocol lda {} it can also override all settings from dovecot.conf. So I don't really like the idea of splitting the configuration. Also in v1.3+ the only thing that reads dovecot.conf is doveconf binary, master and deliver and everything else get their configuration from it.