http://www.dovecot.org/doc/INSTALL> Once everything is configured, there's two ways to start Dovecot: > > 1) Run "dovecot" binary which does everything. > > 2) Start it via inetd or similiar by executing "imap-login" or "pop3-login" > binaries. If you're listening in SSL port, add --ssl parameter.What are the pros and cons of using 'dovecot' vs. inetd. This may seem silly, but I noticed that there isn't any documentation saying what is the proper way to kill Dovecot. I assume it is to kill the 'dovecot' process. This is indirectly addressed in the Wiki: 6. Why can't I change the log location? http://wiki.dovecot.org/moin.cgi/QuestionsAndAnswers#head-c9650f53dd4f7ca2b07564b7a29b99f2687333a9 though the first few examples refer to <pid> without identifying the pid of what. Maybe adding a "How do I start Dovecot?" and "How do I stop Dovecot?" as the first two items on that page would be a good idea, and then the log file question and "7.1 Dovecot isn't running." and "8. Why doesn't Dovecot listen on localhost (127.0.0.1)?" could refer to those. (If this sounds reasonable, I'll update the Wiki.) Any plans to support a /var/run/dovecot/pid file or similar? What are your thoughts on including an init.d script in the distribution. I know some of the binary distributions will have platform-specific scripts included, but it might be good to include a generic one for those who build from source. -Tom
On Sun, 2004-08-29 at 01:24 -0400, Tom Metro wrote:> http://www.dovecot.org/doc/INSTALL > > Once everything is configured, there's two ways to start Dovecot: > > > > 1) Run "dovecot" binary which does everything. > > > > 2) Start it via inetd or similiar by executing "imap-login" or "pop3-login" > > binaries. If you're listening in SSL port, add --ssl parameter. > > What are the pros and cons of using 'dovecot' vs. inetd.With inetd you can use things like /etc/hosts.allowed and maybe some more advanced features of xinetd and likes. Oh and currently Dovecot doesn't support listening in multiple IPs, but with inetd (or just xinetd?) that's possible. Downside is that there can't be any preforked login processes waiting for new connections. I'm not sure how useful that is though. Normally it probably gives a few microseconds less latency, but in high load it should help some more.> This may seem silly, but I noticed that there isn't any documentation > saying what is the proper way to kill Dovecot. I assume it is to kill > the 'dovecot' process...> Any plans to support a /var/run/dovecot/pid file or similar?I've been meaning to add support for that, but I've always forgotten that. Yes, I guess I should add that file. Could even make it into 0.99.11 :)> What are your thoughts on including an init.d script in the > distribution. I know some of the binary distributions will have > platform-specific scripts included, but it might be good to include a > generic one for those who build from source.Does anyone have a platform-independent init.d-script? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20040831/77d5c4ad/attachment-0001.bin>
On Tuesday 31 Aug 2004 10:46 am, Timo Sirainen wrote:> > Downside is that there can't be any preforked login processes waiting > for new connections. I'm not sure how useful that is though. Normally it > probably gives a few microseconds less latency, but in high load it > should help some more.Of course xinetd offers a lot of options to limit resource usage, so I suspect it might be the method of choice under load, especially if you use it to manage all the other mail related daemons on the server. I'm curious are there any main stream IMAP/POP3 servers not using the "process per user" or "thread per user" model? As I wrote a proof of concept server using Java NBIO, for another application once, the idea being to implement a "staged event driven" architecture - but alas it didn't attract much interest. As this would presumably be the smart way to handle high load if context switching became the bottleneck.
> Does anyone have a platform-independent init.d-script? >If not, you could have a /contrib/ directory where people could contribute their rc scripts, and any other useful scripts. The best rc script evolve over time. Paul