Managing xinetd services
There are a bunch of services, particularly Internet services, that are not handled by separate run-level scripts. Instead, a single run-level script called xinetd (formerly inetd) is run to handle incoming requests for a variety of network services. For that reason, xinetd is sometimes referred to as the super-server. The xinetd run-level script (along with the xinetd daemon that it runs) offers the following advantages:
Less daemon processes. Instead of one (or more) daemon processes running on your computer to monitor incoming requests for each service, the xinetd daemon can listen for requests for many different services. As a result, when you type ps -ax to see what processes are running, dozens of fewer daemon processes will be running than there would be if each service had its own daemon.
Access control and logging. By using xinetd to oversee the management of services, consistent methods of access control (such as PAM) and consistent logging methods (such as the /var/log/messages file) can be used across all of the services.
When a request comes into your computer for a service that xinetd is monitoring, xinetd uses the /etc/xinetd.conf file to read configuration files contained in the /etc/xinetd.d directory. Then, based on the contents of the xinetd.d file for the requested service, a server program is launched to handle the service request.
Each server process is one of two types: single-thread or multithread. A single-thread server will handle only the current request, whereas a multithread server will handle all incoming requests for the service as long as there is still a client holding the process open. Then the multithread server will close and xinetd will begin monitoring that service again.
The following are a few examples of services that are monitored by xinetd. The daemon process that is started up to handle each service is also listed.
Note Some of the following services are actually launched by the tcpd daemon. The tcpd daemon acts as an extra level of security, logging each incoming request and performing other security checks.
comsat (/usr/sbin/in.comsat)
— Used to alert the biff client program that new mail has arrived.
eklogin (/usr/kerberos/sbin/klogind) — Kerberos-related login daemon.
finger (/usr/sbin/in.fingerd) — Handles incoming finger requests for information from remote users about local users.
gssftp (/usr/kerberos/sbin/ftpd) — Kerberos-related daemon for handling file transfer requests (FTP).
imap (/usr/sbin/imapd) — Daemon for handling requests from remote mail clients to get their mail from this IMAP server.
linuxconf (/sbin/linuxconf) — Accepts requests from Web browsers from other computers to run linuxconf.
ntalk (/usr/sbin/in.ntalkd) — Daemon for handling requests to set up chats between a remote user and a local one (using the talk command).
rlogin (/usr/sbin/in.rlogind) — Daemon for responding to remote login requests (from a remote rlogin command).
rsh (/usr/sbin/in.rshd) — Handles requests from a remote client to run a command on the local computer.
wu-ftpd (/usr/sbin/in.ftpd) — Accepts FTP requests to the wu-ftpd server.
Other services that can be launched by requests that come in to xinetd include services for POP mail, remote telnet requests, Samba configuration requests, and amanda network backups.
Continue reading here: Understanding cron files
Was this article helpful?