Running imapd: inetd Versus Standalone
The question has been brought up from time to time as to whether itâs better to run imapd standalone, particularly on heavily loaded systems, rather than have inetd fork the daemon process. The UW server and Cyrus server prior to the 2.0 release run under inetd. Version 2.0 of the Cyrus server runs as a standalone daemon.
If a daemon has to do a lot of work at startup time (e.g., processing a large amount of configuration information), then running it standalone will result in faster connect times for your users. sendmail is a good example of a daemon thatâs better suited to run standaloneâits configuration file is large. imapd reads a very small configuration file at startup.
The life of the connection and associated inetd overhead are other factors to consider. If connections to a daemon are long-lived, then there are fewer startups and thus, less inetd overhead. That makes the daemon a good candidate to run under inetd. If a connection, on the other hand, is short-lived, itâs better not to run the daemon under inetd because of the extra overhead inetd will concur. imapd is an example of a daemon with long-lived connections, compared with daemons that make many short-lived connections, such as sendmail and popd.
Even on a heavily loaded system (e.g., 1,000 active processes), each imapd process will start once and remain active throughout a userâs IMAP session. Since the number of connections in any given time period is small, compared ...
Get Managing IMAP now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.