inetd

inetd
Name	inetd
Title	inetd
Developer	Various Unix vendors
Operating system	Unix, BSD, Linux, System V
Genre	Daemon, super-server

inetd is a Unix-derived super-server daemon that listens for incoming network connections and dispatches requests to appropriate service programs. It consolidates multiple network services under a single process, reducing resource usage and centralizing access control for legacy TELNET-style and other socket-based services. inetd influenced subsequent service management systems and remains relevant for lightweight or embedded deployments.

Overview

inetd acts as a multiplexor for network services, accepting connections on behalf of multiple server programs and launching those programs on demand. It supports both stream and datagram protocols and can spawn either short-lived processes or hand off file descriptors to long-running daemons. The design reduces the number of concurrently running processes and simplifies service configuration for administrators of BSD and System V systems.

History and Development

inetd originated in early UNIX distributions as networking was integrated into Research Unix environments and commercial variants. It became standard in Berkeley Software Distribution releases and in AT&T-derived System V implementations. Over time, inetd's role evolved alongside networking stacks such as TCP/IP and service suites like BSD networking utilities; later projects such as xinetd, systemd, and launchd offered alternative models. Contributors to inetd-style daemons include vendors and projects affiliated with Sun Microsystems, DEC, FreeBSD, and NetBSD.

Architecture and Operation

inetd monitors multiple sockets using event demultiplexing mechanisms provided by the kernel, invoking handlers based on configured port, protocol, and address family. It typically uses system calls like accept(2) and recvfrom(2) to obtain client connections and can pass file descriptors to executed programs via the process environment. For datagram services, inetd reads a packet and may launch a handler with the socket bound to the client's address; for stream services it forks and execs the server program. This architecture interacts closely with kernel networking subsystems such as BSD sockets and relies on process control primitives in POSIX-compliant systems.

Configuration

inetd is configured via a central table file that lists services, protocols, socket types, wait/nowait semantics, user identities, and server programs. Typical fields mirror policy in Internet Assigned Numbers Authority-managed port assignments, and administrators map entries to daemons or wrappers. Configuration utilities and formats vary among implementations; some support access control via TCP wrappers or integration with name service mechanisms such as DNS and NIS. Changes to the configuration are applied by signaling inetd with SIGHUP or by restarting the daemon under supervision tools like cron or init systems including System V init.

Security Considerations

Running services via inetd centralizes attack surface and requires careful control over allowed services, file permissions, and execution contexts. Historically, vulnerabilities exploited privileged network daemons in OpenBSD, FreeBSD, and various Linux distributions, prompting hardened replacements and privilege separation mechanisms. Administrators mitigate risk by disabling unnecessary entries, employing wrappers such as TCP Wrappers and mandatory access control frameworks like SELinux and AppArmor, and using chroot jails or privilege-dropping to limit compromise impact. Auditing and patch management from vendors including Debian, Red Hat, and Canonical are essential to maintain secure deployments.

Implementations and Variants

Multiple projects implement inetd-like functionality. Variants include the traditional inetd found in early 4.3BSD releases, enhanced inetd in Solaris distributions by Sun Microsystems, and extended replacements such as xinetd and openbsd-inetd. Modern init and service managers like systemd provide socket activation that supersedes classic inetd semantics in many Linux distributions; launchd offers analogous capabilities on macOS and Darwin. Embedded and minimalist systems sometimes use lightweight inetd clones from projects associated with BusyBox and Toybox.

Usage and Examples

Common use cases include running small, on-demand services such as echo (networking), discard (protocol), chargen, and legacy TELNET or FTP servers. Example entries in inetd tables specify service names correlated with IANA port numbers and invoke executables with appropriate user privileges. Administrators combine inetd with monitoring tools and wrappers to provide logging, access control, and rate limiting; integration with tcpdump and system logging daemons such as syslogd aids in troubleshooting and incident response. For modern replacements, administrators migrate to socket-activation features in systemd or to supervised services managed by launchd on Apple platforms.

Category:Unix daemons