Provided by: openbsd-inetd_0.20221205-3build4_amd64 bug

NAME

       inetd, inetd.conf — internet super-server

SYNOPSIS

       inetd [-d] [-E] [-i] [-l] [-q length] [-R rate] [configuration_file]

DESCRIPTION

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

       The options are as follows:

       -d      Turns on debugging.

       -E      Prevents inetd from laundering the environment.  Without this option a selection  of  potentially
               harmful environment variables, including PATH, will be removed and not inherited by services.

       -i      Makes the program not daemonize itself.

       -l      Turns  on  libwrap  connection  logging and access control.  Internal services cannot be wrapped.
               When enabled, /usr/sbin/tcpd is silently not executed even  if  present  in  /etc/inetd.conf  and
               instead libwrap is called directly by inetd.

       -q length
               Specify the length of the listen(2) connections queue; the default is 128.

       -R rate
               Specify  the  maximum number of times a service can be invoked in one minute; the default is 256.
               If a service exceeds this limit, inetd will log the problem and stop servicing requests  for  the
               specific service for ten minutes.  See also the wait/nowait configuration fields below.

       Upon execution, inetd reads its configuration information from a configuration file which, by default, is
       /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.   The
       fields of the configuration file are as follows:

             service name
             socket type
             protocol[,sndbuf=size][,rcvbuf=size]
             wait/nowait[.max]
             user[.group] or user[:group]
             server program
             server program arguments

       To specify a Sun-RPC based service, the entry would contain these fields.

             service name/version
             socket type
             rpc/protocol[,sndbuf=size][,rcvbuf=size]
             wait/nowait[.max]
             user[.group] or user[:group]
             server program
             server program arguments

       For internet services, the first field of the line may also have a host address specifier prefixed to it,
       separated  from  the  service name by a colon.  If this is done, the string before the colon in the first
       field indicates what local address inetd should use when listening  for  that  service.   Multiple  local
       addresses  can  be  specified on the same line, separated by commas.  Numeric IP addresses in dotted-quad
       notation  can  be  used  as  well  as  symbolic  hostnames.   Symbolic  hostnames  are  looked  up  using
       getaddrinfo().   If  a  hostname  has multiple address mappings, inetd creates a socket to listen on each
       address.

       The single character “*” indicates INADDR_ANY, meaning “all local  addresses”.   To  avoid  repeating  an
       address  that  occurs  frequently, a line with a host address specifier and colon, but no further fields,
       causes the host address specifier to be remembered and used for all further lines with no  explicit  host
       specifier (until another such line or the end of the file).  A line
             *:
       is  implicitly provided at the top of the file; thus, traditional configuration files (which have no host
       address specifiers) will be interpreted in the traditional manner, with all services listened for on  all
       local addresses.  If the protocol is “unix”, this value is ignored.

       The  service  name  entry is the name of a valid service in the file /etc/services or a port number.  For
       “internal” services (discussed below), the service name must be the official name of  the  service  (that
       is,  the  first  entry  in /etc/services).  When used to specify a Sun-RPC based service, this field is a
       valid RPC service name in the file /etc/rpc.  The part on the right of the “/” is the RPC version number.
       This can simply be a single numeric argument or a range of versions.  A  range  is  bounded  by  the  low
       version  to  the high version - “rusers/1-3”.  For Unix-domain sockets this field specifies the path name
       of the socket.

       The socket type should be one of “stream” or “dgram”, depending on whether the  socket  is  a  stream  or
       datagram socket.

       The  protocol  must be a valid protocol as given in /etc/protocols or “unix”.  Examples might be “tcp” or
       “udp”.  RPC based services are specified with the “rpc/tcp” or “rpc/udp” service type.  “tcp”  and  “udp”
       will  be  recognized  as  “TCP  or  UDP  over  both  IPv4  and IPv6.” If you need to specify IPv4 or IPv6
       explicitly, use something like “tcp4” or “udp6”.  A protocol of “unix” is used to specify a socket in the
       Unix-domain.

       In addition to the protocol, the configuration file may specify the send and receive socket buffer  sizes
       for  the  listening socket.  This is especially useful for TCP as the window scale factor, which is based
       on the receive socket buffer size, is advertised when the connection handshake occurs,  thus  the  socket
       buffer  size  for  the  server  must be set on the listen socket.  By increasing the socket buffer sizes,
       better TCP performance may be realized in some situations.  The socket  buffer  sizes  are  specified  by
       appending their values to the protocol specification as follows:

             tcp,rcvbuf=16384
             tcp,sndbuf=64k
             tcp,rcvbuf=64k,sndbuf=1m

       A  literal  value  may  be  specified,  or  modified  using  ‘k’ to indicate kilobytes or ‘m’ to indicate
       megabytes.

       The wait/nowait entry is used to tell inetd if it should wait  for  the  server  program  to  return,  or
       continue  processing  connections  on the socket.  If a datagram server connects to its peer, freeing the
       socket so inetd can receive 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(8) (biff(1)) and talkd(8) are both examples of the latter type of datagram server.   The  optional
       “max” suffix (separated from “wait” or “nowait” by a dot) specifies the maximum number of times a service
       can  be  invoked  in one minute; the default is 256.  If a service exceeds this limit, inetd will log the
       problem and stop servicing requests for the specific service for ten minutes.  See  also  the  -R  option
       above.

       Stream  servers  are  usually  marked  as  “nowait”  but if a single server process is to handle multiple
       connections, it may be marked as “wait”.  The master socket will then be passed as fd 0  to  the  server,
       which  will  then need to accept the incoming connection.  The server should eventually time out and exit
       when no more connections are active.  inetd will continue to listen on the master socket for connections,
       so the server should not close it when it exits.

       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.  An optional group name can be specified by appending a
       dot to the user name followed by the group name.  This  allows  for  servers  to  run  with  a  different
       (primary)  group  ID  than specified in the password file.  If a group is specified and user is not root,
       the supplementary groups associated with that user will still be set.

       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  server  program  arguments should be just as arguments 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
       Network Information Center.

       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.

   libwrap
       Support  for  TCP  wrappers  is  included  with  inetd  to  provide  built-in  tcpd-like  access  control
       functionality.   An  external  tcpd program is not needed.  You do not need to change the /etc/inetd.conf
       server-program entry to enable this capability.  inetd  uses  /etc/hosts.allow  and  /etc/hosts.deny  for
       access control facility configurations, as described in hosts_access(5).

   IPv6 TCP/UDP behavior
       The  default  is  to  run  two  servers:  one  for  IPv4 and one for IPv6 traffic.  If you have different
       requirements then you may specify one or two separate lines in inetd.conf, for “tcp4” and “tcp6”.

       Under various combinations of IPv4/v6 daemon settings, inetd will behave as follows:
          If you have only one server on “tcp4”, IPv4 traffic will be routed to the server.  IPv6 traffic  will
           not be accepted.
          If  you  have  two servers on “tcp4” and “tcp6”, IPv4 traffic will be routed to the server on “tcp4”,
           and IPv6 traffic will go to the server on “tcp6”, which is identical to the  default  behaviour  when
           only “tcp” is specified.
          If you have only one server on “tcp6”, only IPv6 traffic will be routed to the server.

           The  special  “tcp46”  parameter  can  be  used  for  obsolete  servers which require to receive IPv4
           connections mapped in an IPv6 socket. Its usage is discouraged.

FILES

       /etc/inetd.conf

SEE ALSO

       fingerd(8), ftpd(8), identd(8), talkd(8)

HISTORY

       The inetd command appeared in 4.3BSD.  Support for Sun-RPC based services is modelled after that provided
       by SunOS 4.1.  IPv6 support was added by the KAME project in 1999.

       Marco d'Itri ported this code from OpenBSD in summer 2002 and added socket  buffers  tuning  and  libwrap
       support from the NetBSD source tree.

BUGS

       On  Linux  systems,  the  daemon  cannot reload its configuration and needs to be restarted when the host
       address for a service is changed between “*” and a specific address.

       Server programs used with “dgram” “udp” “nowait” must read from the network socket, or inetd  will  spawn
       processes until the maximum is reached.

       Host  address  specifiers,  while  they  make  conceptual  sense  for  RPC services, do not work entirely
       correctly.  This is largely because the portmapper interface does not provide a way to register different
       ports for the same service on different local addresses.  Provided you never have more than one entry for
       a given RPC service, everything should work correctly.  (Note that default  host  address  specifiers  do
       apply to RPC lines with no explicit specifier.)

Debian                                          February 10, 2020                                       INETD(8)