On Tue, 15 Feb 2005, Kashani wrote: > Michael Sullivan wrote: > > Why is it stupid? What is xinetd anyway? What does it do? > > xinetd is what's often called a super-daemon. It sits there listening > for connections on ports you've configured. When connections come in > xinetd answers and then calls the correct server to handle it. Once > the connection is done, the client exits, xinetd drops the connection, > and the server daemon shuts down... not exactly sure on the order for > all that, but it doesn't matter much for our purposes.
True, it doesn't matter for this. Look to the end of this response if you care. > The nice thing about this is that you don't need ten ftp daemons > sitting around using RAM while waiting for incoming connections. This > helps keep resourvces free on a small system with little RAM that runs > many services, but doesn't need to do them all the time. Or, more exactly, xinetd is a single daemon process listening to potentially dozens or hundreds of ports, each with a different service it represents. Without xinetd, all of those ports would need to have separate daemons listening to them, in order to all be active. > The bad thing is that you have to reread all data and may have some > significant start time associated with the daemons. Also you lose any > caching of data when the daemon exits. In the case of a busy server > that has a dedicated function, xinetd is going to slow things down. Or > for real fun try running a database out of xinetd. At the low end. At the high end, the bad thing is that inetd daemons, in general, have no load recognition. They have no concept of what resources the daemons for which they are fronting require, and therefore have no concept of when enough is enough. Because of this and the lack of caching, any complex services run out of xinetd are easy potential DoS attack target points. > Back to imap, unless you like the idea of rescanning your entire dir > every time you make an imap connection, standalone is better most of > the time... for imap/http/mysql. However other daemons with low > overhead like pop3/telnet/ftp/tftp would be fine. Imap has the benefit of maintaining persistent connections after it has started. Pop3, on the other hand, usually does not. Admittedly, this is a client difference, but virtually all clients I've utilized are configured along these lines. As such, pop3 is *not* my idea of a good xinetd service. Back when I ran an overloaded pop/imap server, switching these two to standalone mode got me a near-instant call from my boss's boss, asking what I did to fix the email server. (Of course, as they'd *really* overloaded that sucker, and so it wasn't really fixed. It just took it from about 130% max load to 110% max load. The gains would've been more substantial, except the overload was only on the mail store itself; the main filesystem was fine. This server was running around 99.9% pop3, 0.1% imap.) Don't get me started about telnet; just use ssh, disable/remove telnet, and we can be happy. Or, lie to me, and claim that you did, and I can, at least, be happy. Thank you. Oh, and I would also recommend courier or cyrus. Note that Cyrus' format is (or at least, was, back when I ran a user mail server) similar to maildir, except that the message store is held under the control of the system imap/pop server, and is indexed several ways. The list of mailboxes is also indexed. As such, it scales marvelously well, under most circumstances. Ed And now, for more detail: > xinetd is what's often called a super-daemon. It sits there listening > for connections on ports you've configured. When connections come in > xinetd answers and then calls the correct server to handle it. Once > the connection is done, the client exits, xinetd drops the connection, > and the server daemon shuts down... not exactly sure on the order for > all that, but it doesn't matter much for our purposes. An inetd daemon (such as xinetd) is primarily useful for simplifying its client programs. Those daemons launched out of inetd do not need any complex daemon code, or for that matter, any daemon code at all. When a connection comes in to a port that inetd, it accepts the command, and forks, remaps the connection to feed into the forked process's standard input, and if it's a stream connection, remaps the forked process's standard output back into the connection. It then execs the associated command, which needs no complicated protocol handling capabilities to handle the networked connections. One could, for example, use inetd to invoke cat or date, and it'd work just fine. (Don't do this. inetd servers have equivalents built into them, for both efficiency and security reasons.) Once the connection is done, the client exits, and the daemon server exits. Inetd had been uninvolved since the fork, and couldn't care less that the connection has closed. (Unless, of course, it was a datagram connection with the 'wait' flag. In that case, inetd then starts listening on that port again.) -- gentoo-user@gentoo.org mailing list
