1.\" Copyright (c) 1985, 1991 The Regents of the University of California. 2.\" All rights reserved. 3.\" 4.\" Redistribution and use in source and binary forms, with or without 5.\" modification, are permitted provided that the following conditions 6.\" are met: 7.\" 1. Redistributions of source code must retain the above copyright 8.\" notice, this list of conditions and the following disclaimer. 9.\" 2. Redistributions in binary form must reproduce the above copyright 10.\" notice, this list of conditions and the following disclaimer in the 11.\" documentation and/or other materials provided with the distribution. 12.\" 3. All advertising materials mentioning features or use of this software 13.\" must display the following acknowledgement: 14.\" This product includes software developed by the University of 15.\" California, Berkeley and its contributors. 16.\" 4. Neither the name of the University nor the names of its contributors 17.\" may be used to endorse or promote products derived from this software 18.\" without specific prior written permission. 19.\" 20.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND 21.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 22.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 23.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE 24.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 25.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 26.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 27.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 28.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 29.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 30.\" SUCH DAMAGE. 31.\" 32.\" from: @(#)inetd.8 6.7 (Berkeley) 3/16/91 33.\" $Id: inetd.8,v 1.19 2001/08/22 17:44:27 beck Exp $ 34.\" 35.Dd March 16, 1991 36.Dt INETD 8 37.Os 38.Sh NAME 39.Nm inetd 40.Nd internet 41.Dq super-server 42.Sh SYNOPSIS 43.Nm inetd 44.Op Fl d 45.Op Fl R Ar rate 46.Op Ar configuration file 47.Sh DESCRIPTION 48.Nm inetd 49should be run at boot time by 50.Pa /etc/rc 51(see 52.Xr rc 8 ) . 53It then listens for connections on certain internet sockets. 54When a connection is found on one 55of its sockets, it decides what service the socket 56corresponds to, and invokes a program to service the request. 57After the program is 58finished, it continues to listen on the socket (except in some cases which 59will be described below). 60Essentially, 61.Nm inetd 62allows running one daemon to invoke several others, 63reducing load on the system. 64.Pp 65The options are as follows: 66.Bl -tag -width Ds 67.It Fl d 68Turns on debugging. 69.It Fl R Ar rate 70Specify the maximum number of times a service can be invoked 71in one minute; the default is 256. 72.El 73.Pp 74Upon execution, 75.Nm inetd 76reads its configuration information from a configuration 77file which, by default, is 78.Pa /etc/inetd.conf . 79There must be an entry for each field of the configuration 80file, with entries for each field separated by a tab or 81a space. 82Comments are denoted by a 83.Dq # 84at the beginning 85of a line. 86There must be an entry for each field. 87The fields of the configuration file are as follows: 88.Pp 89.Bd -unfilled -offset indent -compact 90service name 91socket type 92protocol 93wait/nowait[.max] 94user[.group] or user[:group] 95server program 96server program arguments 97.Ed 98.Pp 99To specify a Sun-RPC 100based service, the entry would contain these fields. 101.Pp 102.Bd -unfilled -offset indent -compact 103service name/version 104socket type 105rpc/protocol 106wait/nowait[.max] 107user[.group] or user[:group] 108server program 109server program arguments 110.Ed 111.Pp 112For internet services, the first field of the line may also have a host 113address specifier prefixed to it, separated from the service name by a 114colon. 115If this is done, the string before the colon in the first field 116indicates what local address 117.Nm 118should use when listening for that service. 119Multiple local addresses 120can be specified on the same line, separated by commas. 121Numeric IP 122addresses in dotted-quad notation can be used as well as symbolic 123hostnames. 124Symbolic hostnames are looked up using 125.Fn gethostbyname . 126If a hostname has multiple address mappings, inetd creates a socket 127to listen on each address. 128.Pp 129The single character 130.Dq \&* 131indicates 132.Dv INADDR_ANY , 133meaning 134.Dq all local addresses . 135To avoid repeating an address that occurs frequently, a line with a 136host address specifier and colon, but no further fields, causes the 137host address specifier to be remembered and used for all further lines 138with no explicit host specifier (until another such line or the end of 139the file). 140A line 141.Dl *: 142is implicitly provided at the top of the file; thus, traditional 143configuration files (which have no host address specifiers) will be 144interpreted in the traditional manner, with all services listened for 145on all local addresses. 146.Pp 147The 148.Em service-name 149entry is the name of a valid service in 150the file 151.Pa /etc/services . 152For 153.Dq internal 154services (discussed below), the service 155name 156.Em must 157be the official name of the service (that is, the first entry in 158.Pa /etc/services ) . 159When used to specify a Sun-RPC 160based service, this field is a valid RPC service name in 161the file 162.Pa /etc/rpc . 163The part on the right of the 164.Dq / 165is the RPC version number. 166This can simply be a single numeric argument or a range of versions. 167A range is bounded by the low version to the high version - 168.Dq rusers/1-3 . 169.Pp 170The 171.Em socket-type 172should be one of 173.Dq stream , 174.Dq dgram , 175.Dq raw , 176.Dq rdm , 177or 178.Dq seqpacket , 179depending on whether the socket is a stream, datagram, raw, 180reliably delivered message, or sequenced packet socket. 181.Pp 182The 183.Em protocol 184must be a valid protocol as given in 185.Pa /etc/protocols . 186Examples might be 187.Dq tcp 188or 189.Dq udp . 190RPC based services are specified with the 191.Dq rpc/tcp 192or 193.Dq rpc/udp 194service type. 195.Dq tcp 196and 197.Dq udp 198will be recognized as 199.Dq TCP or UDP over default IP version . 200It is currently IPv4, but in the future it will be IPv6. 201If you need to specify IPv4 or IPv6 explicitly, use something like 202.Dq tcp4 203or 204.Dq udp6 . 205.Pp 206The 207.Em wait/nowait 208entry is used to tell 209.Nm 210if it should wait for the server program to return, 211or continue processing connections on the socket. 212If a datagram server connects 213to its peer, freeing the socket so 214.Nm inetd 215can receive further messages on the socket, it is said to be 216a 217.Dq multi-threaded 218server, and should use the 219.Dq nowait 220entry. 221For datagram servers which process all incoming datagrams 222on a socket and eventually time out, the server is said to be 223.Dq single-threaded 224and should use a 225.Dq wait 226entry. 227.Xr comsat 8 228.Pq Xr biff 1 229and 230.Xr talkd 8 231are both examples of the latter type of 232datagram server. 233.Xr tftpd 8 234is an exception; it is a datagram server that establishes pseudo-connections. 235It must be listed as 236.Dq wait 237in order to avoid a race; 238the server reads the first packet, creates a new socket, 239and then forks and exits to allow 240.Nm inetd 241to check for new service requests to spawn new servers. 242The optional 243.Dq max 244suffix (separated from 245.Dq wait 246or 247.Dq nowait 248by a dot) specifies the maximum number of server instances that may be 249spawned from 250.Nm inetd 251within an interval of 60 seconds. 252When omitted, 253.Dq max 254defaults to 256. 255.Pp 256Stream servers are usually marked as 257.Dq nowait 258but if a single server process is to handle multiple connections, it may be 259marked as 260.Dq wait . 261The master socket will then be passed as fd 0 to the server, which will then 262need to accept the incoming connection. 263The server should eventually time 264out and exit when no more connections are active. 265.Nm 266will continue to 267listen on the master socket for connections, so the server should not close 268it when it exits. 269.Xr identd 8 270is usually the only stream server marked as wait. 271.Pp 272The 273.Em user 274entry should contain the user name of the user as whom the server 275should run. 276This allows for servers to be given less permission 277than root. 278An optional group name can be specified by appending a dot to 279the user name followed by the group name. 280This allows for servers to run with 281a different (primary) group ID than specified in the password file. 282If a group 283is specified and user is not root, the supplementary groups associated with 284that user will still be set. 285.Pp 286The 287.Em server-program 288entry should contain the pathname of the program which is to be 289executed by 290.Nm inetd 291when a request is found on its socket. 292If 293.Nm inetd 294provides this service internally, this entry should 295be 296.Dq internal . 297.Pp 298The 299.Em server program arguments 300should be just as arguments 301normally are, starting with argv[0], which is the name of 302the program. 303If the service is provided internally, the word 304.Dq internal 305should take the place of this entry. 306.Pp 307.Nm inetd 308provides several 309.Dq trivial 310services internally by use of routines within itself. 311These services are 312.Dq echo , 313.Dq discard , 314.Dq chargen 315(character generator), 316.Dq daytime 317(human readable time), and 318.Dq time 319(machine readable time, 320in the form of the number of seconds since midnight, January 3211, 1900). 322All of these services are TCP based. 323For details of these services, consult the appropriate 324.Tn RFC 325from the Network Information Center. 326.Pp 327.Nm inetd 328rereads its configuration file when it receives a hangup signal, 329.Dv SIGHUP . 330Services may be added, deleted or modified when the configuration file 331is reread. 332.Nm inetd 333creates a file 334.Em /var/run/inetd.pid 335that contains its process identifier. 336.Ss IPv6 TCP/UDP behavior 337If you wish to run a server for IPv4 and IPv6 traffic, 338you'll need to run two separate process for the same server program, 339specified as two separate lines on 340.Pa inetd.conf , 341for 342.Dq tcp4 343and 344.Dq tcp6 . 345.Pp 346Under various combination of IPv4/v6 daemon settings, 347.Nm 348will behave as follows: 349.Bl -bullet -compact 350.It 351If you have only one server on 352.Dq tcp4 , 353IPv4 traffic will be routed to the server. 354IPv6 traffic will not be accepted. 355.It 356If you have two servers on 357.Dq tcp4 358and 359.Dq tcp6 , 360IPv4 traffic will be routed to the server on 361.Dq tcp4 , 362and IPv6 traffic will go to server on 363.Dq tcp6 . 364.It 365If you have only one server on 366.Dq tcp6 , 367only IPv6 traffic will be routed to the server. 368.El 369.Sh BUGS 370Host address specifiers, while they make conceptual sense for RPC 371services, do not work entirely correctly. 372This is largely because the 373portmapper interface does not provide a way to register different ports 374for the same service on different local addresses. 375Provided you never 376have more than one entry for a given RPC service, everything should 377work correctly. 378(Note that default host address specifiers do apply to 379RPC lines with no explicit specifier.) 380.Pp 381.Dq rpc 382or 383.Dq tcpmux 384on IPv6 is not tested enough. 385Kerberos support on IPv6 is not tested. 386.Sh SEE ALSO 387.Xr comsat 8 , 388.Xr fingerd 8 , 389.Xr ftpd 8 , 390.Xr ftp-proxy 8 , 391.Xr rexecd 8 , 392.Xr rlogind 8 , 393.Xr rshd 8 , 394.Xr telnetd 8 , 395.Xr tftpd 8 396.Sh HISTORY 397The 398.Nm 399command appeared in 400.Bx 4.3 . 401Support for Sun-RPC 402based services is modeled after that 403provided by SunOS 4.1. 404IPv6 support and IPsec hack was made by KAME project, in 1999. 405