inetd [configuration-file] start | stop | refresh
Services are no longer managed by editing the inetd configuration 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 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(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.
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.
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.
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:
tcp_trace is equivalent to the previous inetd's -t option (and the /etc/default/inetd property ENABLE_CONNECTION_LOGGING).
tcp_wrappers is equivalent to the previous inetd's /etc/default/inetd property ENABLE_TCPWRAPPERS.
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, 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_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(4)).
See EXAMPLES for an example of a configuration of a service that supports both IPv4 and IPv6.
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.
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
|ATTRIBUTE TYPE||ATTRIBUTE VALUE|
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||OmniOS|