Managing IMAP

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 ...