[Dovecot] starting/stopping Dovecot
http://www.dovecot.org/doc/INSTALL
Once everything is configured, there's two ways to start Dovecot:
Run "dovecot" binary which does everything.
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:
- Why can't I change the log location? http://wiki.dovecot.org/moin.cgi/QuestionsAndAnswers#head-c9650f53dd4f7ca2b0...
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:
Run "dovecot" binary which does everything.
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?
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.
On Tue, 2004-08-31 at 11:32 +0100, Simon Waters wrote:
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.
Dovecot is going a bit towards making it possible. All network I/O is now nonblocking. Blocking disk reads and waiting for locks are the next problems. Maybe the mail store APIs could be made fully nonblocking and after that it should be pretty easy to make a couple of processes handle all connections.
participants (4)
-
Paul Reilly
-
Simon Waters
-
Timo Sirainen
-
Tom Metro