inetd man page on SmartOS

Man page or keyword search:  
man Server   16655 pages
apropos Keyword Search (all sections)
Output format
SmartOS logo
[printable version]

INETD(1M)							     INETD(1M)

       inetd  -	 Solaris Management Facility delegated restarter for inet ser‐

       inetd  [configuration-file] start |  stop |  refresh


       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
       requests 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
       either 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 lis‐
       tening on the same port. When this occurs, inetd	 logs  this  condition
       and continues trying to bind to the port at configured intervals a con‐
       figured number of times. See the property bind_fail_max under  "Service
       Properties," 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
       response	 to  an	 SMF request, or when it receives a SIGHUP signal. See
       the refresh description under "inetd Methods" for the behavior on  con‐
       figuration 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
       machine	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:


	   inetd has yet to process this service.


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


	   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.


	   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 dependen‐
		      cies become met the service's state  will	 be  re-evalu‐

	       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,

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

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


	   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.


	   A service is in this state because it is either malfunctioning  and
	   needs  adminstrator	attention  or  because	an  administrator  has
	   requested 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

	   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:


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


	   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
	   result in it ceasing listening. This method will be executed before
	   the disable method in the case an online/degraded service  is  dis‐
	   abled.  This	 method	 is required to be implemented for a wait-type


	   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.


	   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.


	   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,

	       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

       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

   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:


	   The address of the network interface to which the service should be
	   bound. An empty string value causes the service to  accept  connec‐
	   tions on any network interface.


	   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


	   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.


	   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.


	   The	backlog queue size. Represents a limit on the number of incom‐
	   ing client requests that can be queued at the  listening  endpoints
	   for servers.


	   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.


	   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.


	   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‐


	   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).


	   If true, this is an RPC service.


	   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.


	   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‐


	   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

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


	   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).  See	"Configuring  Protocols for Sockets-Based Ser‐
	   vices," below.


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


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


	   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).


	   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
	   incompatibilities 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

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


	   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
	 connection_backlog  10
	 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
       inetd 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'

       In addition to the special method tokens	 mentioned  in	smf_method(5),
       inetd  also  supports  the  :kill_process token for wait-type services.
       This results in behavior identical to that if the :kill token were sup‐
       plied,  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
       encompassing process contract (see process(4)).

   Configuring Protocols for Sockets-Based Services
       When  configuring  inetd	 for  a	 sockets-based	service,  you have the
       choice, depending on what is supported by the service, of the  alterna‐
       tives  described	 under	the  proto  property, above. The following are
       guidelines for which proto values to use:

	   o	  For a service that supports only IPv4: tcp and udp

	   o	  For a service that supports only IPv6: tcp6only and udp6only

	   o	  For a service that supports both IPv4 and IPv6:

	       o      Obsolete and not recommended: tcp6 and udp6

	       o      Recommended: use two separate entries that  differ  only
		      in  the proto field. One entry has tcp and the other has
		      tcp6only, or udp plus udp6only.

       See EXAMPLES for an example of a configuration of a service  that  sup‐
       ports both IPv4 and IPv6.

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


	   Causes inetd to start providing  service.  This  results  in	 inetd
	   beginning  to handle smf requests for its managed services and net‐
	   work requests for those services that are in either the  online  or
	   degraded 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.


	   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.


	   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 config‐
		      uration  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 con‐
		      figuration for the bind;

	       o      if it is in the online state and	a  re-binding  is  not
		      necessary, then the inetd_refresh method of the service,
		      if provided, will be run to allow online wait-type  ser‐
		      vices to consume any other changes.

       No options are supported.


	   Specifies  an  alternate  location  for  the	 legacy	 service  file


	   Specifies which of inetd's methods should be run.

       Example 1 Configuring a Service that Supports Both IPv4 and IPv6

       The following commands illustrate the existence of services  that  sup‐
       port both IPv4 and IPv6 and assign proto properties to those services.

	 example# svcs -a | grep mysvc
	 online		15:48:29 svc:/network/mysvc:dgram4
	 online		15:48:29 svc:/network/mysvc:dgram6
	 online		15:51:47 svc:/network/mysvc:stream4
	 online		15:52:10 svc:/network/mysvc:stream6

	 # inetadm -M network/rpc/mysvc:dgram4 proto=udp
	 # inetadm -M network/rpc/mysvc:dgram6 proto=udp6only
	 # inetadm -M network/rpc/mysvc:stream4 proto=tcp
	 # inetadm -M network/rpc/mysvc:stream6 proto=tcp6only

       See svcs(1) and inetadm(1M) for descriptions of those commands.

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

       │Interface Stability │ Evolving	      │

       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),
       attributes(5), smf(5), smf_method(5)

       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
       release,	 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
       ENABLE_TCP_WRAPPERS are now available as the tcp_trace and tcp_wrappers
       properties,  respectively.  These properties are described above, under
       "Service Properties".

				  Jul 5, 2007			     INETD(1M)

List of man pages available for SmartOS

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net