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