Unix/Linux Go Back    


BSD 2.11 - man page for inetd (bsd section 8)

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:   man
Select Man Page Set:       apropos Keyword Search (sections above)


INETD(8)										 INETD(8)

NAME
       inetd - internet ``super-server''

SYNOPSIS
       inetd [-d] [-R rate] [configuration file]

DESCRIPTION
       The  inetd program should be run at boot time by /etc/rc (see rc(8)).  It then listens for
       connections on certain internet sockets.  When a connection is found on one of  its  sock-
       ets,  it  decides what service the socket corresponds to, and invokes a program to service
       the request.  The server program is invoked with the service socket as its standard input,
       output and error descriptors.  After the program is finished, inetd 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 available for inetd:

       -d	 Turns on debugging.

       -R rate	 Specifies  the  maximum  number of times a service can be invoked in one minute;
		 the default is 1000.

       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 configura-
       tion 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
	    socket type
	    protocol
	    wait/nowait
	    user
	    server program
	    server program arguments

       There are two types of services that inetd can start: standard  and  TCPMUX.   A  standard
       service has a well-known port assigned to it; it may be a service that implements an offi-
       cial Internet standard or is a BSD-specific service.  As described  in  RFC  1078,  TCPMUX
       services  are  nonstandard  services  that do not have a well-known port assigned to them.
       They are invoked from inetd when a program connects to the ``tcpmux'' well-known port  and
       specifies the service name.  This feature is useful for adding locally-developed servers.

       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).	For TCPMUX services, the value of
       the service-name field consists of the string ``tcpmux''  followed  by  a  slash  and  the
       locally-chosen  service	name.	The  service  names  listed in /etc/services and the name
       ``help'' are reserved.  Try to choose unique names for your TCPMUX services  by	prefixing
       them with your organization's name and suffixing them with a version number.

       The  socket-type  should  be  one  of  ``stream'',  ``dgram'', ``raw'', ``rdm'', or ``seq-
       packet'', depending on whether the socket is a stream, datagram, raw,  reliably	delivered
       message, or sequenced packet socket.  TCPMUX services must use ``stream''.

       NOTE: ``rdm'' and ``seqpacket'' are not supported in 2.11BSD.

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

       The wait/nowait entry specifies whether the server that is invoked by inetd will take over
       the  socket  associated	with the service access point, and thus whether inetd should wait
       for the server to exit before listening for new service requests.  Datagram  servers  must
       use  ``wait'',  as  they are always invoked with the original datagram socket bound to the
       specified service address.  These servers must read at least one datagram from the  socket
       before  exiting.   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;
       it should read one datagram from the socket and create a new socket connected to the peer.
       It should fork, and the parent should then exit to allow inetd to check	for  new  service
       requests to spawn new servers.  Datagram servers which process all incoming datagrams on a
       socket and eventually time out are said to be ``single-threaded''.  Comsat(8), biff(1) and
       talkd(8)  are examples of the latter type of datagram server.  Tftpd(8) is an example of a
       multi-threaded datagram server.

       Servers using stream sockets generally are multi-threaded and use  the  ``nowait''  entry.
       Connection  requests  for  these  services are accepted by inetd , and the server is given
       only the newly-accepted socket connected to a client of the  service.   Most  stream-based
       services  operate in this manner.  Stream-based servers that use ``wait'' are started with
       the listening service socket, and must accept at least one connection request before exit-
       ing.  Such a server would normally accept and process incoming connection requests until a
       timeout.  TCPMUX services must use ``nowait''.

       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 exe-
       cuted 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.

       The  inetd  program  provides  several  ``trivial'' services internally by use of routines
       within itself.  These services are ``echo'', ``discard'', ``chargen''  (character  genera-
       tor),  ``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 Infor-
       mation Center.

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

TCPMUX
       RFC  1078  describes the TCPMUX protocol: ``A TCP client connects to a foreign host on TCP
       port 1.	It sends the service name followed by a carriage-return  line-feed  <CRLF>.   The
       service name is never case sensitive.  The server replies with a single character indicat-
       ing positive (+) or negative (-) acknowledgment, immediately followed by an optional  mes-
       sage  of  explanation,  terminated with a <CRLF>.  If the reply was positive, the selected
       protocol begins; otherwise the connection is closed.''  The program is passed the TCP con-
       nection as file descriptors 0 and 1.

       If  the	TCPMUX service name begins with a ``+'', inetd returns the positive reply for the
       program.  This allows you to invoke programs that use  stdin/stdout  without  putting  any
       special server code in them.

       The special service name ``help'' causes inetd to list TCPMUX services in inetd.conf.

EXAMPLES
       Here are several example service entries for the various types of services:

       ftp	     stream  tcp   nowait root	/usr/libexec/ftpd	ftpd -l
       ntalk	     dgram   udp   wait   root	/usr/libexec/ntalkd	ntalkd
       tcpmux/+date  stream  tcp   nowait guest /bin/date		date
       tcpmux/phonebook stream tcp nowait guest /usr/local/phonebook phonebook

ERROR MESSAGES
       The  inetd server logs error messages using syslog(3).  Important error messages and their
       explanations are:

       service/protocol server failing (looping), service terminated.
       The number of requests for the specified service in the past minute  exceeded  the  limit.
       The limit exists to prevent a broken program or a malicious user from swamping the system.
       This message may occur for several reasons: 1) there are lots of hosts requesting the ser-
       vice  within  a	short time period, 2) a 'broken' client program is requesting the service
       too frequently, 3) a malicious user is running a  program  to  invoke  the  service  in	a
       'denial	of  service'  attack,  or 4) the invoked service program has an error that causes
       clients to retry quickly.  Use the -R option, as  described  above,  to	change	the  rate
       limit.	Once the limit is reached, the service will be reenabled automatically in 10 min-
       utes.

       service/protocol: No such user 'user', service ignored
       service/protocol: getpwnam: user: No such user
       No entry for user exists in the passwd file. The first message occurs when inetd (re)reads
       the configuration file. The second message occurs when the service is invoked.

       service: can't set uid number
       service: can't set gid number
       The user or group ID for the entry's user is invalid.

SEE ALSO
       comsat(8), fingerd(8), ftpd(8), rexecd(8), rlogind(8), rshd(8), telnetd(8), tftpd(8)

HISTORY
       The  inetd  command appeared in 4.3BSD.	TCPMUX is based on code and documentation by Mark
       Lottor.

4.4 Berkeley Distribution		 November 7, 1996				 INETD(8)
Unix & Linux Commands & Man Pages : ©2000 - 2018 Unix and Linux Forums


All times are GMT -4. The time now is 09:59 PM.