INETD(1M)           RISC/os Reference Manual            INETD(1M)



NAME
     inetd - internet ``super-server''

SYNOPSIS
     /etc/inetd [ -d ] [ configuration file ]

DESCRIPTION
     inetd should be run at boot time by /etc/rc2.d/S30tcp.  It
     then listens for connections on certain internet sockets.
     When a connection is found on one of its sockets, it decides
     what service the socket corresponds to, and invokes a pro-
     gram to service the request.  After the program is finished,
     it continues to listen on the socket (except in some cases
     which will be described below).  Essentially, inetd allows
     running one daemon to invoke several others, reducing load
     on the system.

     Upon execution, inetd reads its configuration information
     from a configuration file which, by default, is
     /usr/etc/inetd.conf.  There must be an entry for each field
     of the configuration file, with entries for each field
     separated by a tab or a space.  Comments are denoted by a
     ``#'' at the beginning of a line.  There must be an entry
     for each field.  The fields of the configuration file are as
     follows:
          service name or rpc specification
          socket type
          protocol
          wait/nowait
          user
          server program
          server program arguments

     The service name entry is the name of a valid service in the
     file /etc/services.  For ``internal'' services (discussed
     below), the service name must be the official name of the
     service (that is, the first entry in /etc/services).  Rpc
     specifications are discussed below.

     The socket type should be one of ``stream'', ``dgram'',
     ``raw'', ``rdm'', or ``seqpacket'', depending on whether the
     socket is a stream, datagram, raw, reliably delivered mes-
     sage, or sequenced packet socket.  The socket type may be
     suffixed with ``/stream'' to indicate that the service pro-
     vider expects an streams connection, as opposed to a sockets
     connection, and that the streams connection should conform
     to the Transport Provider Interface specification.  The
     socket type may further be suffixed with ``/xti'' or
     ``/tli'' to indicate that the streams connection should be
     suitable for use with the XTI facility (-lxti or -lnsl in -
     systype svr3 or -systype svr4), or with ``/socket'' to indi-
     cate that the streams connection should be suitable for use



                        Printed 11/19/92                   Page 1

INETD(1M)           RISC/os Reference Manual            INETD(1M)



     with the -systype svr4 sockets emulation library (-lsocket).
     For example, if the service provider is implemented using
     the XTI facility, and expects a virtual circuit, the socket
     type should be ``stream/stream/xti''.  Similarly, if the
     service provider is implemented using the -systype svr4
     sockets emulation library, and expects datagrams, the socket
     type should be ``datagram/stream/socket''.

     The protocol must be a valid protocol as given in
     /etc/protocols.  Examples might be ``tcp'' or ``udp''.

     The wait/nowait entry is applicable to datagram sockets only
     (other sockets should have a ``nowait'' entry in this
     space).  If a datagram server connects to its peer, freeing
     the socket so inetd can received further messages on the
     socket, it is said to be a ``multi-threaded'' server, and
     should use the ``nowait'' entry.  For datagram servers which
     process all incoming datagrams on a socket and eventually
     time out, the server is said to be ``single-threaded'' and
     should use a ``wait'' entry.


     ``Comsat'' (``biff'') and ``talk'' are both examples of the
     latter type of datagram server.  Tftpd is an exception; it
     is a datagram server that establishes pseudo-connections.
     It must be listed as ``wait'' in order to avoid a race; the
     server reads the first packet, creates a new socket, and
     then forks and exits to allow inetd to check for new service
     requests to spawn new servers.

     The user entry should contain the user name of the user as
     whom the server should run.  This allows for servers to be
     given less permission than root.  The server program entry
     should contain the pathname of the program which is to be
     executed by inetd when a request is found on its socket.  If
     inetd provides this service internally, this entry should be
     ``internal''.

     The arguments to the server program should be just as they
     normally are, starting with argv[0], which is the name of
     the program.  If the service is provided internally, the
     word ``internal'' should take the place of this entry.

     inetd provides several ``trivial'' services internally by
     use of routines within itself.  These services are ``echo'',
     ``discard'', ``chargen'' (character generator), ``daytime''
     (human readable time), and ``time'' (machine readable time,
     in the form of the number of seconds since midnight, January
     1, 1900).  All of these services are tcp based.  For details
     of these services, consult the appropriate RFC from the Net-
     work Information Center.




 Page 2                 Printed 11/19/92

INETD(1M)           RISC/os Reference Manual            INETD(1M)



     inetd rereads its configuration file when it receives a
     hangup signal, SIGHUP.  Services may be added, deleted or
     modified when the configuration file is reread.

NOTE
     /etc/routed is symbolic link to /usr/etc/routed

SEE ALSO
     ftpd(1M), rexecd(1M), rlogind(1M), rshd(1M), telnetd(1M),
     tftpd(1M)

ORIGIN
     4.3 BSD










































                        Printed 11/19/92                   Page 3