*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->IRIX man pages -> inetd (1)              


INETD(1M)							     INETD(1M)

NAME    [Toc]    [Back]

     inetd - Internet ``super-server''

SYNOPSIS    [Toc]    [Back]

     /usr/etc/inetd [ -R rate ]	[ -d ] [ -l qlen ] [ -s	]
	 [ configuration-file ]

DESCRIPTION    [Toc]    [Back]

     When inetd	is started at boot time	by /etc/init.d/network,	it reads its
     configuration information from the	/etc/inetd.conf	and 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.

OPTIONS    [Toc]    [Back]

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

     -d	  This option turns on debugging information.  Note that this can
	  confuse some applications; use this cautiously.

     -f	  This option is no longer supported and will simply cause a warning
	  message to be	included in the	syslog if used.

     -l	  This option changes the listen queue length used for TCP sockets.
	  By default this value	is 255.

     -s	  Causes inetd to just parse the configuration file (default is
	  /etc/inetd.conf) and report any errors.  Do not need superuser
	  privileges to	run inetd using	this option.

     To	specify	a different configuration file,	put its	pathname in the	file


     Each line of the configuration file must be a valid service or a comment.
     Comments are denoted by a ``#'' at	the beginning of a line.  Each field
     in	a line must be specified, with values for each field separated by a
     tab or a space. The fields	are as follows:
	  service name
	  socket type
	  server program
	  server program arguments

									Page 1

INETD(1M)							     INETD(1M)

     There are three types of services that inetd can start: standard, RPC and
     TCPMUX.  A	standard service has a well-known port assigned	to it and is
     listed in /etc/services or	the NIS	services map (see services(4));	it may
     be	a service that implements an official Internet standard	or is a	BSD
     Unix-specific service.  RPC services use the Sun RPC calls	as the
     transport;	such services are listed in /etc/rpc or	the NIS	rpc map	(see
     rpc(4)).  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

     For standard Internet services, the service name field is the name	of a
     valid service in the services(4) database.	 For ``internal'' services
     (discussed	below),	the service name must be the official name of the
     service (that is, the first field in /etc/services).  For RPC services,
     the value of the service name field consists of the RPC service name,
     followed by a slash and either a version number or	a range	of version
     numbers (e.g., mountd/1).	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. If the service name begins with a ``+'', it
     indicates inetd will handle the initial handshake with the	requesting
     program, otherwise	the service is responsible for the handshake.  (The
     handshake is described in the inetd section in the	IRIX Network
     Programming Guide.)  The service names listed in /etc/services and	the
     name ``help'' are reserved.  The ``help'' name causes inetd to list
     available TCPMUX services.	 Private protocols should use a	service	name
     that has a	high chance of being unique.  A	good practice is to prefix the
     service name with the name	of your	organization.  Multiple	versions of a
     protocol can suffix the service name with a protocol version number.

     The socket	type should be one of ``stream'', ``dgram'', or	``raw'',
     depending on whether the socket is	a stream, datagram, or raw socket.
     TCPMUX services must use ``stream.''

     The protocol must be a valid protocol as given in /etc/protocols (see
     protocols(4)).  Examples might be ``tcp'' or ``udp''.  For	RPC services,
     the field consists	of the string ``rpc'' followed by a slash and the name
     of	the protocol (e.g., rpc/tcp or rpc/udp for an RPC service using	the
     TCP or UDP	protocol as a transport	mechanism. If 2	RPC services use the
     same server program with different	protocol such as tcp or	udp, the 2
     services need to be based on protocol lexicographic order).  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

									Page 2

INETD(1M)							     INETD(1M)

     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.  Talkd(8) is an example of the	singlethreaded
 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 exiting.  Such a server would normally accept and process incoming
     connection	requests until a timeout.  RPC services	usually	wait.  TCPMUX
     services must use nowait.

     The user field 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	field 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 field	should be
     ``internal''.  For	non-internal services, the arguments to	the server
     program should be just as they normally are, starting with	argv[0], which
     is	the name of the	program. There is a limit of 11	arguments per program
     (including	argv[0]).  A `?' character, placed just	before the server
     program pathname, causes inetd to suppress	error logging of a missing
     server.  As shipped, /etc/inetd.conf uses `?' to suppress error logging
     for servers that are included in optional software	packages.

     Inetd provides several trivial services internally	by use of routines
     within itself.  These services are	``echo'', ``discard'', ``chargen''
     (character	generator), ``daytime''	(human readable	time), ``time''
     (machine readable time, in	the form of the	number of seconds since
     midnight, January 1, 1900), and ``tcpmux''	(service multiplexor). All of
     these services are	TCP-based.  For	details	of these services, consult
     RFCs 862, 863, 864, 867, 868, and 1078.

     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.  To disable a service, add the comment
     character ``#'' at	the beginning of the service's line in inetd.conf and
     send SIGHUP to inetd with the command

	  /etc/killall -HUP  inetd

									Page 3

INETD(1M)							     INETD(1M)

ERROR MESSAGES    [Toc]    [Back]

     Inetd logs	error messages using syslog(3B).  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 service
     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

	  service/protocol: 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.

	  too many services: open-file limit reached.

     The number	of services in the configuration file exceeds the number of
     file descriptors that inetd can keep open.	 Unnecessary services must be
     removed or	commented out or the kernel must be reconfigured to increase
     the limit (the NOFILES parameter in /var/sysgen/master.d/kernel.)

EXAMPLES    [Toc]    [Back]

     Here are several example service entries for the various types of

	  ftp	       stream tcp     nowait root  /usr/etc/ftpd	 ftpd -l
	  ntalk	       dgram  udp     wait   root  /usr/etc/talkd	 talkd
	  rusersd/1    dgram  rpc/udp wait   root  /usr/etc/rpc.rusersd	 rusersd
	  tcpmux/+date stream tcp     nowait guest /bin/date		 date

									Page 4

INETD(1M)							     INETD(1M)

NOTE    [Toc]    [Back]

     If	NIS is enabled on your system, inetd uses the NIS equivalents of
     /etc/services and /etc/rpc.  Make sure your NIS server's services and rpc
     databases contain the entries listed in these files.

NOTES    [Toc]    [Back]

     inetd has a limit of 512 characters per line of the configuration file.
     Exceeding this limit may cause inetd to terminate abnormally.

     If	both TCP and UDP services are listed for an RPC	service, the TCP
     service should be listed first.

SEE ALSO    [Toc]    [Back]

     ftpd(1M), rexecd(1M), rlogind(1M),	rshd(1M), telnetd(1M), tftpd(1M).

     sockets programming chapter in the	IRIX Network Programming Guide.
     RFCs are available	from the Network Information Center at SRI
     International, Menlo Park,	CA.

									PPPPaaaaggggeeee 5555
[ Back ]
 Similar pages
Name OS Title
named OpenBSD Internet domain name server
named FreeBSD Internet domain name server (DNS)
named IRIX internet domain name server (DNS)
named HP-UX Internet domain name server
named Tru64 Internet domain name server (DNS)
bootp IRIX server for Internet Bootstrap Protocol
telnetd IRIX internet TELNET protocol server
bootpd HP-UX Internet Boot Protocol server
bootptab FreeBSD Internet Bootstrap Protocol server database
bootpd FreeBSD Internet Boot Protocol server/gateway
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service