Tribblix: manual page: inetd.8

INETD(8) Maintenance Commands and Procedures INETD(8)

NAME

inetd - Service 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 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(5). Instead, you use inetconv(8) to convert the
configuration file content into SMF format services, then manage
these services using inetadm(8) and svcadm(8). 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
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 continues 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 description under "inetd Methods" for the behavior on
configuration refresh.

You can use the inetadm(8) or svccfg(8) 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(7) 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 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
connections, 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 configured maximum number of times, at configured
intervals.The service'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
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 malfunctioning
and needs administrator 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 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(8) 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 disable method in the case an online/degraded
service is disabled. This method is required to be implemented
for a wait-type service.

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

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_addr

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

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.

connection_backlog

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

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 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
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 environment variables set in the
method context. These variables are described in smf_method(7).

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

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(5) for a description of syslog
codes and severity levels. 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(5) 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(7).

For more information about configuring TCP wrappers, refer to
tcpd(8) and hosts_access(5).

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 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
service. They do not have separate "listening" and "accepting"
sockets. 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(8).

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(8).
(See svc.startd(8) 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'
arg0='/path/to/service/daemon'

In addition to the special method tokens mentioned in smf_method(7),
inetd also supports the :kill_process 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 encompassing process contract (see process(5)).

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
alternatives 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
supports both IPv4 and IPv6.

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

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(5)-format
configuration file it is monitoring has changed since the last
inetconv(8) 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(5) 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
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(5)).

start|stop|refresh

Specifies which of inetd's methods should be run.

EXAMPLES

Example 1: Configuring a Service that Supports Both IPv4 and IPv6

The following commands illustrate the existence of services that
support 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(8) for descriptions of those commands.

ATTRIBUTES

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 system releases. In the current
Solaris release, inetd is part of the Service Management Facility
(see smf(7)) and will run only within that facility.

The /etc/default/inetd file has been deprecated. The functionality
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".

May 13, 2017 INETD(8)