Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
inetd(1M)		System Administration Commands		     inetd(1M)

NAME
       inetd  -	 Solaris Management Facility delegated restarter for inet ser-
       vices

SYNOPSIS
       inetd [configuration-file]  start | stop	| refresh

	svc:/network/inetd:default

DESCRIPTION
       inetd is	the delegated restarter	for internet services for the  Service
       Management  Facility  (SMF).  Its  basic	responsibilities are to	manage
       service states in response to administrative requests, system failures,
       and  service failures; and, when	appropriate, to	listen for network re-
       quests for services.

       Services	are no longer managed by editing the inetd configuration file,
       inetd.conf(4).  Instead,	you use	inetconv(1M) to	convert	the configura-
       tion file content into SMF format services, then	manage these  services
       using  inetadm(1M) and svcadm(1M). Once a service has been converted by
       inetconv, any changes to	the legacy data	in the inetd config file  will
       not  become effective. However, inetd does alert	the administrator when
       it notices change in the	configuration file. See	the start  description
       under the "inetd	Methods" section for further information.

       Also  note  that	 the current inetd cannot be run from outside the SMF.
       This means it cannot be run from	the command line, as was supported  by
       the  previous  inetd.  If  you attempt to do this, a message is sent to
       stderr displaying mappings between the options supported	by the	previ-
       ous inetd to the	SMF version of inetd.

       inetd listens for connections on	behalf of all services that are	in ei-
       ther the	online or degraded state. A service enters one of these	states
       when  the service is enabled by the user	and inetd manages to listen on
       its behalf.  A listen attempt  can  fail	 if  another  server  (whether
       standalone  or  a third-party internet service) is already listening on
       the same	port. When this	occurs,	inetd logs this	condition and  contin-
       ues  trying  to	bind  to the port at configured	intervals a configured
       number of times.	See the	property bind_fail_max under "Service  Proper-
       ties," below, for more details.

       The  configuration  of all inetd's managed SMF services is read when it
       is started. It is reread	when inetd is refreshed, which occurs  in  re-
       sponse  to an SMF request, or when it receives a	SIGHUP signal. See the
       refresh description under "inetd	Methods" for the behavior on  configu-
       ration refresh.

       You  can	use the	inetadm(1M) or svccfg(1M) utilities to make configura-
       tion changes to Internet	services within	the  SMF  repository.  inetadm
       has  the	advantage over svccfg in that it provides an Internet/RPC ser-
       vice context.

   Service States
       As part of its service management duties, inetd implements a state  ma-
       chine  for each of its managed services.	The states in this machine are
       made up of the smf(5) set of states. The	semantics of these states  are
       as follows:

       uninitialized

	   inetd has yet to process this service.

       online

	   The	service	is handling new	network	requests and might have	exist-
	   ing connections active.

       degraded

	   The service has entered this	state because it was  able  to	listen
	   and process requests	for some, but not all, of the protocols	speci-
	   fied	for the	service, having	exhausted its listen retries. Existing
	   network connections might be	active.

       offline

	   Connections might be	active,	but no new requests are	being handled.
	   This	is a transient state. A	service	might be offline  for  any  of
	   the following reasons:

	     o	The  service's	dependencies  are unmet. When its dependencies
		become met the service's state will be re-evaluated.

	     o	The service has	exceeded its configured	connection rate	limit,
		max_con_rate.  The  service's  state  is re-evaluated when its
		connection offline timer, con_rate_offline, expires.

	     o	The service has	reached	its allowed number of  active  connec-
		tions,	max_copies.  The  service's state is re-evaluated when
		the number of active connections drops below max_copies.

	     o	inetd failed to	listen on behalf of the	 service  on  all  its
		protocols.  As	mentioned above, inetd retries up to a config-
		ured maximum number of times, at configured intervals.The ser-
		vice's	state  is re-evaluated when either a listen attempt is
		successful or the retry	limit is reached.

       disabled

	   The service has been	turned off by an administrator,	is not accept-
	   ing	new  connections, and has none active. Administrator interven-
	   tion	is required to exit this state.

       maintenance

	   A service is	in this	state because it is either malfunctioning  and
	   needs  adminstrator	attention  or because an administrator has re-
	   quested it.

	   Events constituting malfunctioning include:	inetd's	 inability  to
	   listen on behalf on any of the service's protocols before exceeding
	   the service's bind retry limit, non-start  methods  returning  with
	   non-success	return	values,	 and the service exceeding its failure
	   rate.

	   You request the maintenance state to	 perform  maintenance  on  the
	   service,  such  as applying a patch.	No new requests	are handled in
	   this	state, but existing connections	might be active. Administrator
	   intervention	is required to exit this state.

       Use inetadm(1M) to obtain the current state of a	managed	service.

   Service Methods
       As  part	 of certain state transitions inetd will execute, if supplied,
       one of a	set of methods provided	by the service.	The set	 of  supported
       methods are:

       inetd_start

	   Executed  to	 handle	 a  request for	an online or degraded service.
	   Since there is no separate state to distinguish a service with  ac-
	   tive	 connections,  this  method is not executed as part of a state
	   transition.

       inetd_offline

	   Executed when a service is taken from the online or degraded	 state
	   to  the  offline state. For a wait-type service that	at the time of
	   execution is	performing its own listening, this method  should  re-
	   sult	 in  it	ceasing	listening. This	method will be executed	before
	   the disable method in the case an online/degraded service  is  dis-
	   abled.

       inetd_online

	   Executed  when  a service transitions from the offline state	to the
	   online state. This method allows a service author to	carry out some
	   preparation prior to	a service starting to handle requests.

       inetd_disable

	   Executed  when  a service transitions from the offline state	to the
	   disabled state. It should result in any active  connections	for  a
	   service being terminated.

       inetd_refresh

	   Executed when both of the following conditions are met:

	     o	inetd  is refreshed, by	means of the framework or a SIGHUP, or
		a request comes	in to refresh the service, and

	     o	the service is currently in the	online state and there are  no
		configuration changes that would result	in the service needing
		to be taken offline and	brought	back again.

       The only	compulsory method is the inetd_start method. In	the absence of
       any  of	the others, inetd runs no method but behaves as	if one was run
       successfully.

   Service Properties
       Configuration for SMF-managed services is stored	in the SMF repository.
       The  configuration  is made up of the basic configuration of a service,
       the configuration for each of the service's methods,  and  the  default
       configuration applicable	to all inetd-managed services.

       For details on viewing and modifying the	configuration of a service and
       the defaults, refer to inetadm(1M).

       The basic configuration of a service is	stored	in  a  property	 group
       named inetd in the service. The properties comprising the basic config-
       uration are as follows:

       bind_fail_interval

	   The time interval in	seconds	between	a failed bind  attempt	and  a
	   retry.  The	values	0 and -1 specify that no retries are attempted
	   and	the  first  failure  is	 handled   the	 same	as   exceeding
	   bind_fail_max.

       bind_fail_max

	   The	maximum	 number	 of times inetd	retries	binding	to a service's
	   associated port before giving up. The value -1  specifies  that  no
	   retry  limit	 is  imposed.  If none of the service's	protocols were
	   bound to before any imposed limit is	reached, the service  goes  to
	   the	maintenance state; otherwise, if not all of the	protocols were
	   bound to, the service goes to the degraded state.

       con_rate_offline

	   The time in seconds a service will remain offline if	it exceeds its
	   configured  maximum connection rate,	max_con_rate. The values 0 and
	   -1 specify that connection rate limiting is disabled.

       endpoint_type

	   The type of the socket used by the service or the value tli to sig-
	   nify	 a  TLI-based  service.	 Valid socket type values are: stream,
	   dgram, raw, seqpacket.

       failrate_cnt

	   The count portion of	the service's failure rate limit. The  failure
	   rate	 limit applies to wait-type services and is reached when count
	   instances of	the service are	started	within a given time. Exceeding
	   the	rate  results in the service being transitioned	to the mainte-
	   nance state.	This is	different from the behavior  of	 the  previous
	   inetd, which	continued to retry every 10 minutes, indefinitely. The
	   failrate_cnt	check accounts for badly behaving  servers  that  fail
	   before  consuming  the service request and which would otherwise be
	   continually restarted, taxing system	 resources.  Failure  rate  is
	   equivalent to the -r	option of the previous inetd. The values 0 and
	   -1 specify that this	feature	is disabled.

       failrate_interval

	   The time portion in seconds of the service's	failure	rate. The val-
	   ues	0  and	-1 specify that	the failure rate limit feature is dis-
	   abled.

       inherit_env

	   If true, pass inetd's environment on	to the service's start method.
	   Regardless  of this setting,	inetd will set the variables SMF_FMRI,
	   SMF_METHOD, and SMF_RESTARTER in the	start method's environment, as
	   well	 as any	environment variables set in the method	context. These
	   variables are described in smf_method(5).

       isrpc

	   If true, this is an RPC service.

       max_con_rate

	   The maximum allowed connection rate,	in connections per second, for
	   a  nowait-type  service. The	values 0 and -1	specify	that that con-
	   nection rate	limiting is disabled.

       max_copies

	   The maximum number of copies	of a nowait service that can run  con-
	   currently. The values 0 and -1 specify that copies limiting is dis-
	   abled.

       name

	   Can be set to one of	the following values:

	     o	a service name understood by getservbyname(3SOCKET);

	     o	if isrpc is set	to true, a service name	 understood  by	 getr-
		pcbyname(3NSL);

	     o	if isrpc is set	to true, a valid RPC program number.

       proto

	   In  the  case of socket-based services, this	is a list of protocols
	   supported by	the service. Valid protocols are: tcp, tcp6, tcp6only,
	   udp,	 udp6,	and  udp6only.	In the case of TLI services, this is a
	   list	of netids recognized by	getnetconfigent(3NSL) supported	by the
	   service,  plus  the	values tcp6only	and udp6only. RPC/TLI services
	   also	support	nettypes in this list, and inetd first tries to	inter-
	   pret	the list member	as a nettype for these service types. The val-
	   ues tcp6only	and udp6only are new to	inetd;	these  values  request
	   that	inetd listen only for and pass on true IPv6 requests (not IPv4
	   mapped ones).

       rpc_low_version

	   Lowest supported RPC	version. Required when isrpc is	set to true.

       rpc_high_version

	   Highest supported RPC version. Required when	isrpc is set to	true.

       tcp_trace

	   If true, and	this is	a nowait-type service, inetd logs the client's
	   IP address and TCP port number, along with the name of the service,
	   for each incoming connection, using the syslog(3C) facility.	 inetd
	   uses	the syslog facility code daemon	and notice priority level. See
	   syslog.conf(4) for a	description of syslog codes and	severity  lev-
	   els.	 This  logging	is  separate  from the logging done by the TCP
	   wrappers facility.

	   tcp_trace is	equivalent to the previous inetd's -t option (and  the
	   /etc/default/inetd property ENABLE_CONNECTION_LOGGING).

       tcp_wrappers

	   If  true,  enable TCP wrappers access control. This applies only to
	   services with endpoint_type set to streams and wait set  to	false.
	   The	syslog facility	code daemon is used to log allowed connections
	   (using the notice severity level) and  denied  traffic  (using  the
	   warning  severity  level).  See syslog.conf(4) for a	description of
	   syslog codes	and severity levels. The stability level  of  the  TCP
	   wrappers  facility  and its configuration files is External.	As the
	   TCP wrappers	facility is not	controlled by Sun,  intra-release  in-
	   compatibilities are not uncommon. See attributes(5).

	   For	more information about configuring TCP wrappers, you can refer
	   to the tcpd(1M) and hosts_access(4) man pages, which	are  delivered
	   as  part  of	 the  Solaris  operating system	at /usr/sfw/man. These
	   pages are not part of the standard Solaris man pages, available  at
	   /usr/man.

	   tcp_wrappers	is equivalent to the previous inetd's /etc/default/in-
	   etd property	ENABLE_TCPWRAPPERS.

       wait

	   If true this	is a wait-type service,	otherwise it is	a  nowait-type
	   service. A wait-type	service	has the	following characteristics:

	     o	Its  inetd_start method	will take over listening duties	on the
		service's bound	endpoint when it is executed.

	     o	inetd will wait	for it to exit after it	is executed before  it
		resumes	listening duties.

	   Datagram  servers must be configured	as being of type wait, as they
	   are always invoked with the original	datagram  endpoint  that  will
	   participate	in  delivering the service bound to the	specified ser-
	   vice. They do not have separate "listening" and  "accepting"	 sock-
	   ets.	 Connection-oriented services, such as TCP stream services can
	   be designed to be either of type wait or nowait.

       A number	of the basic properties	are optional for a service.  In	 their
       absence,	 their values are taken	from the set of	default	values present
       in the defaults property	group in the inetd service. These  properties,
       with  their  seed  values, are listed below. Note that these values are
       configurable through inetadm(1M).

       bind_fail_interval  -1
       bind_fail_max	   -1
       con_rate_offline	   -1
       failrate_count	   40
       failrate_time	   60
       inherit_env	   true
       max_con_rate	   -1
       max_copies	   -1
       tcp_trace	   false
       tcp_wrappers	   false

       Each method specified for a service will	have its configuration	stored
       in  the SMF repository, within a	property group of the same name	as the
       method. The set of properties  allowable	 for  these  methods  includes
       those  specified	 for  the  services  managed  by  svc.startd(1M). (See
       svc.startd(1M) for further details.) Additionally, for the  inetd_start
       method, you can set the arg0 property.

       The  arg0 property allows external wrapper programs to be used with in-
       etd services. Specifically, it allows the first argument,  argv[0],  of
       the  service's  start method to be something other than the path	of the
       server program.

       In the case where you want to use an external wrapper program and  pass
       arguments to the	service's daemon, the arguments	should be incorporated
       as arguments to the wrapper program in the exec property. For example:

       exec='/path/to/wrapper/prog service_daemon_args'
       arg0='/path/to/service/daemon'

       In addition to the special method tokens	 mentioned  in	smf_method(5),
       inetd  also  supports the :kill_proc token for wait-type	services. This
       results in behavior identical to	that if	the :kill token	were supplied,
       except  that  the kill signal is	sent only to the parent	process	of the
       wait-type service's start method, not to	all members of its  encompass-
       ing process contract (see process(4)).

   inetd Methods
       inetd  provides	the methods listed below for consumption by the	master
       restarter, svc.startd(1M).

       start

	   Causes inetd	to start providing service. This results in inetd  be-
	   ginning to handle smf requests for its managed services and network
	   requests for	those services that are	in either the  online  or  de-
	   graded state.

	   In addition,	inetd also checks if the inetd.conf(4)-format configu-
	   ration file it is monitoring	 has  changed  since  the  last	 inet-
	   conv(1M)  conversion	 was  carried  out.  If	it has,	then a message
	   telling the administrator to	re-run inetconv	to effect the  changes
	   made	is logged in syslog.

       stop

	   Causes  inetd to stop providing service. At this point, inetd tran-
	   sitions each	of its services	that are not in	either the maintenance
	   or  disabled	 states	 to the	offline	state, running any appropriate
	   methods in the process.

       refresh

	   Results in a	refresh	being performed	for each of its	 managed  ser-
	   vices and the inetd.conf(4) format configuration file being checked
	   for change, as in the start method. When a  service	is  refreshed,
	   its behavior	depends	on its current state:

	     o	if  it	is in the maintenance or disabled states, no action is
		performed because the configuration will be read and  consumed
		when the service leaves	the state;

	     o	if  it is in the offline state,	the configuration will be read
		and any	changes	consumed immediately;

	     o	if it is in the	online or degraded state and the configuration
		has  changed such that a re-binding is necessary to conform to
		it, then the service will be transitioned to the offline state
		and back again,	using the new configuration for	the bind;

	     o	if  it	is  in the online state	and a re-binding is not	neces-
		sary, then the inetd_refresh method of the  service,  if  pro-
		vided,	will be	run to allow online wait-type services to con-
		sume any other changes.

OPTIONS
       No options are supported.

OPERANDS
       configuration-file

	   Specifies an	alternate location for the legacy  service  file  (in-
	   etd.conf(4)).

       start|stop|refresh

	   Specifies which of inetd's methods should be	run.

ATTRIBUTES
       See attributes(5) for descriptions of the following attributes:

       +-----------------------------+-----------------------------+
       |      ATTRIBUTE	TYPE	     |	    ATTRIBUTE VALUE	   |
       +-----------------------------+-----------------------------+
       |Availability		     |SUNWcsu			   |
       +-----------------------------+-----------------------------+
       |Interface Stability	     |Evolving			   |
       +-----------------------------+-----------------------------+

SEE ALSO
       fmd(1M),	 inetadm(1M),  inetconv(1M),  svcadm(1M), svccfg(1M), svcs(1),
       svc.startd(1M), syslog(3C), getnetconfigent(3NSL),  getrpcbyname(3NSL),
       getservbyname(3SOCKET),	inetd.conf(4), process(4), syslog.conf(4), at-
       tributes(5), smf(5), smf_method(5)

NOTES
       The inetd daemon	performs the same function as, but is implemented sig-
       nificantly  differently	from, the daemon of the	same name in Solaris 9
       and prior Solaris operating system releases. In the current Solaris re-
       lease,  inetd  is  part of the Solaris Management Facility (see smf(5))
       and will	run only within	that facility.

       The /etc/default/inetd file has been deprecated.	The functionality rep-
       resented	  by   the   properties	  ENABLE_CONNECTION_LOGGING   and  EN-
       ABLE_TCP_WRAPPERS are now available as the tcp_trace  and  tcp_wrappers
       properties,  respectively.  These properties are	described above, under
       "Service	Properties".

SunOS 5.10			  16 Dec 2004			     inetd(1M)

NAME | SYNOPSIS | DESCRIPTION | OPTIONS | OPERANDS | ATTRIBUTES | SEE ALSO | NOTES

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=inetd&sektion=1m&manpath=SunOS+5.10>

home | help