System Administration Commands                          inetd(1M)

NAME
     inetd - Solaris Management Facility delegated restarter  for
     inet services

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 responsi-
     bilities are to manage service states in response to  admin-
     istrative  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  confi-
     guration  file, inetd.conf(4). Instead, you use inetconv(1M)
     to convert the configuration 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 adminis-
     trator 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 previous 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 listening on the same
     port. When this occurs, inetd logs this condition  and  con-
     tinues  trying to bind to the port at configured intervals a
     configured 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 descrip-
     tion under "inetd Methods" for the behavior on configuration
     refresh.

     You can use the inetadm(1M) or svccfg(1M) utilities to  make
     configuration  changes  to  Internet services within the SMF
     repository. inetadm has the advantage over svccfg in that it
     provides an Internet/RPC service 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:

     uninitialized

         inetd has yet to process this service.



     online

         The service is handling new network requests  and  might
         have existing 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  specified  for   the   service,   having
         exhausted  its  listen retries. Existing network connec-
         tions 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 connections, max_copies. The service's state
              is re-evaluated when the number of  active  connec-
              tions 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 configured maximum number of times,
              at  configured intervals.The service's state is re-
              evaluated when either a listen attempt is  success-
              ful or the retry limit is reached.



     disabled

         The service has been turned off by an administrator,  is
         not  accepting  new  connections,  and  has none active.
         Administrator intervention  is  required  to  exit  this
         state.



     maintenance

         A service is in this state because it is either malfunc-
         tioning  and  needs adminstrator attention or because an
         administrator has requested it.

         Events constituting malfunctioning include: inetd's ina-
         bility  to listen on behalf on any of the service's pro-
         tocols 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 connec-
         tions  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 active 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 result in it ceasing
         listening. This method will be executed before the  dis-
         able  method  in  the case an online/degraded service is
         disabled.



     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 ser-
              vice, 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 confi-
     guration 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 configuration 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  connec-
         tion rate limiting is disabled.



     endpoint_type

         The type of the socket used by the service or the  value
         tli  to  signify  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  maintenance
         state. This is different from the behavior of the previ-
         ous 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 res-
         tarted,  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 values 0 and -1 specify that the failure rate
         limit feature is disabled.



     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 environ-
         ment variables set in the method  context.  These  vari-
         ables 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 connection rate limiting is disabled.



     max_copies

         The maximum number of copies of a  nowait  service  that
         can  run  concurrently. The values 0 and -1 specify that
         copies limiting is disabled.



     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 getrpcbyname(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 recog-
         nized 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  interpret  the  list  member as a nettype for
         these service types. The values  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 levels. This logging is separate from the  log-
         ging 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 incom-
         patibilities 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/inetd 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 follow-
         ing 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 service. They do not
         have  separate  "listening"  and  "accepting"   sockets.
         Connection-oriented  services,  such  as TCP stream ser-
         vices 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 configura-
     tion  stored  in the SMF repository, within a property group
     of the same name as the method. The set of properties allow-
     able for these methods includes those specified for the ser-
     vices 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 some-
     thing other than the path of the server program.

     In the case where you want to use an external  wrapper  pro-
     gram  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  beginning  to handle smf requests for its managed
         services and network requests for  those  services  that
         are in either the online or degraded state.

         In addition, inetd also  checks  if  the  inetd.conf(4)-
         format  configuration  file it is monitoring has changed
         since the last inetconv(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  transitions  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 services and the inetd.conf(4) format configura-
         tion 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 necessary, then the inetd_refresh method of the
              service, if provided, will be run to  allow  online
              wait-type services to consume any other changes.



OPTIONS
     No options are supported.

OPERANDS
     configuration-file

         Specifies an alternate location for the  legacy  service
         file (inetd.conf(4)).



     start|stop|refresh

         Specifies which of inetd's methods should be run.



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

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

NOTES
     The inetd daemon performs  the  same  function  as,  but  is
     implemented  significantly  differently  from, the daemon of
     the same name in Solaris 9 and prior Solaris operating  sys-
     tem  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  func-
     tionality       represented      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".