<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Chapter5. Ôhe Internet Super Server inetd</title>
<link rel="stylesheet" type="text/css" href="/global.css">
<meta name="generator" content="DocBook XSL Stylesheets VX.X.X">
<link rel="home" href="index.html" title="The NetBSD Guide">
<link rel="up" href="part-net.html" title="Part ÉV. Îetworking and related issues">
<link rel="prev" href="chap-net-practice.html" title="Chapter4. Óetting up TCP/IP on NetBSD in practice">
<link rel="next" href="chap-dns.html" title="Chapter6. Ôhe Domain Name System">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<div class="navheader">
<table width="100%" summary="Navigation header">
<tr><th colspan="3" align="center">Chapter5. Ôhe Internet Super Server inetd</th></tr>
<tr>
<td width="20%" align="left">
<a accesskey="p" href="chap-net-practice.html">Prev</a>/td>
<th width="60%" align="center">Part ÉV. Îetworking and related issues</th>
<td width="20%" align="right">a accesskey="n" href="chap-dns.html">Next</a>
</td>
</tr>
</table>
<hr>
</div>
<div class="chapter">
<div class="titlepage"><div><div><h2 class="title">
<a name="chap-inetd"></a>Chapter5. Ôhe Internet Super Server inetd</h2></div></div></div>
<div class="toc">
<p><b>Table of Contents</b></p>
<dl class="toc">
<dt><span class="sect1"><a href="chap-inetd.html#chap-inetd-overview">25.1. Overview</a></span></dt>
<dt><span class="sect1"><a href="chap-inetd.html#chap-inetd-whats-inetd">25.2. What is inetd?</a></span></dt>
<dt><span class="sect1"><a href="chap-inetd.html#chap-inetd-inetd">25.3. Configuring inetd - <code class="filename">/etc/inetd.conf</code></a></span></dt>
<dt><span class="sect1"><a href="chap-inetd.html#chap-inetd-services">25.4. Services - <code class="filename">/etc/services</code></a></span></dt>
<dt><span class="sect1"><a href="chap-inetd.html#chap-inetd-protocols">25.5. Protocols - <code class="filename">/etc/protocols</code></a></span></dt>
<dt><span class="sect1"><a href="chap-inetd.html#chap-inetd-rpc">25.6. Remote Procedure Calls (RPC) - <code class="filename">/etc/rpc</code></a></span></dt>
<dt><span class="sect1"><a href="chap-inetd.html#chap-inetd-tcpwrap">25.7. Allowing and denying hosts
- <code class="filename">/etc/hosts.{allow,deny}</code></a></span></dt>
<dt><span class="sect1"><a href="chap-inetd.html#chap-inetd-adding-service">25.8. Adding a Service</a></span></dt>
<dt><span class="sect1"><a href="chap-inetd.html#chap-inetd-use-or-not-use">25.9. When to use or not to use inetd</a></span></dt>
<dt><span class="sect1"><a href="chap-inetd.html#chap-inetd-resources">25.10. Other Resources</a></span></dt>
</dl>
</div>
<p>The "internet super server", or <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a>, is available on all
Unix(like) systems, providing many of the basic network services
available. This chapter describes the relationship between the
daemon and several of the config files in the
<code class="filename">/etc/</code> directory.</p>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="chap-inetd-overview"></a>25.1. Ïverview</h2></div></div></div>
<p>In this document we will look at a simple definition of
<a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a>,
how several files that relate to <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a> work (not that these
files are not related to other software), how to add a service
to <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a> and some considerations both to use <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a> for a
particular service and times when a service might be better
off running outside of <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a>.</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="chap-inetd-whats-inetd"></a>25.2. ×hat is inetd?</h2></div></div></div>
<p>In traditional Unix scenarios, one server (daemon) process
watches for connections on a particular port, and handles
incoming requests. Now if a machine offers many services, many
daemon processes would be needed, mostly running idle but still
wasting resources like memory. The internet super server,
inetd, is an approach to this problem. It listens on a number of
ports, and when it receives a request it then determines which
program to run to handle the request and starts an instance of
that program.</p>
<p>Following is a very simple diagram to illustrate
<a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a>:</p>
<div class="literallayout"><p> pop3 ------ |<br>
|<br>
ftpd------ | ÉNETD ü--- Énternet ÄMZ Ówitch ×hatever<br>
|<br>
ãvsupserver |</p></div>
<p>In the above diagram you can see the general idea. The
<a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a> process receives a request and then starts the
appropriate server process. What <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a> is doing is
software multiplexing. An important note here, regarding
security: On many other UNIX-like systems, a package called
tcpwrappers is used as a security enhancement for
<a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a>. On NetBSD the tcpwrapper functionality is built
into <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a> using libwrap.</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="chap-inetd-inetd"></a>25.3. Ãonfiguring inetd - <code class="filename">/etc/inetd.conf</code>
</h2></div></div></div>
<p>The operation of <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a> is controlled by its own config
file, surprisingly named <code class="filename">/etc/inetd.conf</code>,
see <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd.conf+5.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd.conf</span>(5)</span></a>.
The <code class="filename">inetd.conf</code> file basically provides
enabling and mapping of services the systems administrator
would like to have multiplexed through <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a>, indicating
which program should be started for incoming requests on which
port. </p>
<p><a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd.conf+5.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd.conf</span>(5)</span></a> is an ascii file containing one service per
line, and several fields per line. The basic field layout is:</p>
<pre class="programlisting">service-name socket-type protocol wait/nowait user:group server-program arguments</pre>
<div class="variablelist"><dl class="variablelist">
<dt><span class="term">service-name:</span></dt>
<dd><p>The service name indicates the port <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a> should
listen on. It is either a decimal number, or a name
matching a service name given in
<code class="filename">/etc/services</code>.</p></dd>
<dt><span class="term">socket-type:</span></dt>
<dd><p>The communications socket type, the different types are
"stream" for a TCP stream, "dgram" for an UDP service,
"raw" for a raw socket, "rdm" for reliably delivered
message and "seqpacket" for a sequenced packet socket. The
most common socket types are "stream" and "dgram".</p></dd>
<dt><span class="term">protocol</span></dt>
<dd><p>The protocol used, mostly "tcp", "tcp6", "udp" and "udp6"
for stream-oriented services via the Transmission Control
Protocol, or datagram-oriented services via the User
Datagram Protocol. It is worth noting that "tcp" and
"udp" mean they use the default (currently IPv4), "tcp4"
specifically means communication via IPv4 only, and "tcp6"
and "udp6" are IPv6-only. In addition to those, protocols
based on Remote Procedure Calls (<acronym class="acronym">RPC</acronym>)
can be specified as either "rpc/tcp" or "rpc/udp".</p></dd>
<dt><span class="term">wait/nowait</span></dt>
<dd><p>This field tells <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a> if it should wait for a server
program to return or to continue processing new connections
immediately. Many connections to server processes require
answers after data transfers are complete, where other types
can keep transmitting on a connection continuously, the
latter is a "nowait" and the former "wait". In most cases,
this entry corresponds to the socket-type, for example
a streaming connection would (most of the time) have a
"nowait" value in this field.</p></dd>
<dt><span class="term">user[:group]</span></dt>
<dd><p>This field gives the user name and optionally a group name
that the server process which <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a> starts up runs
as.</p></dd>
<dt><span class="term">server-program</span></dt>
<dd><p>This field is the full path of the program that gets started.</p></dd>
<dt><span class="term">program-arguments</span></dt>
<dd><p>This field contains the argument vector argv[] of the
program started, including the program name and additional
arguments the systems administrator may need to specify
for the server program that is started.</p></dd>
</dl></div>
<p>That is all a lot to digest and there are other things the
systems administrator can do with some of the fields. Here is a
sample line from an <code class="filename">inetd.conf</code> file:</p>
<pre class="programlisting">ftp stream tcp nowait root /usr/libexec/ftpd ftpd -ll</pre>
<p>From the left, the service-name is "ftp", socket-type is "stream",
protocol is "tcp", <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a> won't wait for the server
process to terminate ("nowait"), the process runs as user "root",
path is <code class="filename">/usr/libexec/ftpd</code> and program name
and arguments are "ftpd -ll".
Notice in the last field, the program name is different
from the service-name.</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="chap-inetd-services"></a>25.4. Óervices - <code class="filename">/etc/services</code>
</h2></div></div></div>
<p>The next file to consider is the service name data base that can
be found in <code class="filename">/etc/services</code>. This file
basically contains information mapping a service name to a port
number. The format of the <code class="filename">/etc/services</code>
file is: </p>
<pre class="programlisting">service-name port-number/protocol-name [aliases]</pre>
<p>"service-name" is the name of the service, "port-number" is the
port number assigned to the service, "protocol-name" is either
"tcp" or "udp", and if alias names for a port are needed, they
can be added as "aliases", separated by white spaces. Comments
may be added after a hash mark (#). </p>
<p>Let's take a look at the "ssh" entries as an example:</p>
<pre class="programlisting">ssh 22/tcp # Secure Shell
ssh 22/udp</pre>
<p>As we can see, from the left, the service name is "ssh",
the port number is "22", the protocols are both "tcp" and "udp".
Notice that there is a separate entry for every protocol a
service can use (even on the same port).</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="chap-inetd-protocols"></a>25.5. Ðrotocols - <code class="filename">/etc/protocols</code>
</h2></div></div></div>
<p>Another file read by <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a> is
<code class="filename">/etc/protocols</code>. This file has the information
pertaining to DARPA Internet protocols.
The format of the protocols name data base is:</p>
<pre class="programlisting">protocol-name number [aliases]</pre>
<p>where "protocol-name" describes the payload of an IP packet,
e.g. "tcp" or "udp". "number" is the official protocol number
assigned by IANA, and optional alias names can be added after
that. </p>
<p>Let's look at the seventh entry in the
<code class="filename">/etc/protocols</code>
db as an example:</p>
<pre class="programlisting">tcp 6 TCP # transmission control protocol</pre>
<p>Starting from the left, we see that the protocol name is "tcp",
the number is "6" and the only aliases listed is "TCP",
belonging to the Transmission Control Protocol as indicated by
the comment in that line. </p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="chap-inetd-rpc"></a>25.6. Òemote Procedure Calls (RPC) - <code class="filename">/etc/rpc</code>
</h2></div></div></div>
<p>The rpc program number data base used by services with the "rpc"
protocol type in <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd.conf+5.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd.conf</span>(5)</span></a> is kept in
<code class="filename">/etc/rpc</code> and contains name mappings to rpc
program numbers. The format of the file is:</p>
<pre class="programlisting">server-name program-number aliases</pre>
<p>For example, here is the nfs entry:</p>
<pre class="programlisting">nfs 100003 nfsprog</pre>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="chap-inetd-tcpwrap"></a>25.7. Állowing and denying hosts
- <code class="filename">/etc/hosts.{allow,deny}</code>
</h2></div></div></div>
<p>As mentioned above, NetBSD's <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a> has the tcpwrapper
package built in via the libwrap library. As such, <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a>
can allow or deny access to each service on a more fine-grained
base than just allowing a service to everyone, or not enabling
it at all. The access control is defined in the files
<code class="filename">/etc/hosts.allow</code> and
<code class="filename">/etc/hosts.deny</code>, see the
<a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?hosts_access+5.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">hosts_access</span>(5)</span></a> manpage. </p>
<p>Each of the two files contains several lines that describe
access restrictions for a certain server. Access is allowed if
permission is given in <code class="filename">/etc/hosts.allow</code>. If
the service is not listened in
<code class="filename">/etc/hosts.allow</code> but in
<code class="filename">/etc/hosts.deny</code>, it is denied. If a service
is listed in neither file, it is allowed, giving standard
<a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a> behaviour. </p>
<p>Each line in <code class="filename">/etc/hosts.allow</code> and
<code class="filename">/etc/hosts.deny</code> contains a service either
by name (as given in the field for argv[0] in
<code class="filename">/etc/inetd.conf</code>, e.g. "ftpd" instead of
"ftp"), or the special service "ALL" which obviously applies to
all services. Following the service name is - separated by a
colon - a number of access restrictions, which can be hostnames,
domains, single IP addresses, whole IP subnets or some other
restrictions, please check <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?hosts_access+5.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">hosts_access</span>(5)</span></a> for all the
details.</p>
<p>An example configuration that is mostly open but denies access
to services to a certain host and all machines from a certain
domain would look like this:</p>
<pre class="programlisting"># /etc/hostname.deny:
ALL: some.host.name, .some.domain</pre>
<p>Another example that would be mostly closed, denying access to
all but very few machines would need entries in both
<code class="filename">/etc/hosts.allow</code> and
<code class="filename">/etc/hosts.deny</code>. The entry for
<code class="filename">/etc/hosts.deny</code> would be:</p>
<pre class="programlisting"># /etc/hosts.deny
ALL: ALL</pre>
<p>The entry to allow a few hosts would be put into
<code class="filename">/etc/hosts.allow</code>: </p>
<pre class="programlisting"># /etc/hosts.allow
ALL: friend.host.domain otherfriend.otherhost.otherdomain</pre>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="chap-inetd-adding-service"></a>25.8. Ádding a Service</h2></div></div></div>
<p>Many times a systems administrator will find that they need
to add a service to their system that is not already in
<a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a> or they may wish to move a service to it because it
does not get very much traffic. This is usually pretty
simple, so as an example we will look at adding a version
of POP3 on a NetBSD system.</p>
<p>In this case we have retrieved and installed the "cucipop"
package, which can be found in
<code class="filename">pkgsrc/mail/cucipop</code>.
This server is pretty simple to use, the only oddities are
different path locations. Since it is POP3 we know it is a
stream oriented connection with "nowait". Running as "root" will
be fine, the only item that is different is the location of the
program and the name of the program itself.</p>
<p>So the first half of the new entry in
<code class="filename">/etc/inetd.conf</code> looks like this: </p>
<pre class="programlisting">pop3 stream tcp nowait root</pre>
<p>After installation, pkgsrc deposited cucipop in
<code class="filename">/usr/pkg/sbin/cucipop</code>.
So with the next field we have:</p>
<pre class="programlisting">pop3 stream tcp nowait root /usr/pkg/sbin/cucipop</pre>
<p>Last, we want to use the Berkeley mailbox format,
so our server program must be called with the
<code class="option">-Y</code> option.
This leaves the entire entry looking like so:</p>
<pre class="programlisting">pop3 stream tcp nowait root /usr/pkg/sbin/cucipop cucipop -Y</pre>
<p>We have added the service named "pop3" to
<code class="filename">/etc/inetd.conf</code>. Next item to check is that
the system can map the service name to a port number in
<code class="filename">/etc/services</code>:</p>
<pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>grep ^pop3 /etc/services</code></strong>
pop3 110/tcp # POP version 3
pop3 110/udp
pop3s 995/tcp # pop3 protocol over TLS/SSL (was spop3)
pop3s 995/udp # pop3 protocol over TLS/SSL (was spop3)</pre>
<p>The "pop3" entries here are of interest, i.e. they are already
contained in the <code class="filename">/etc/services</code> file shipped
with NetBSD.</p>
<p>Now, to have <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a> use the new entry, we simply restart
it using the rc script:</p>
<pre class="screen"><code class="prompt">#</code> <strong class="userinput"><code>sh /etc/rc.d/inetd restart</code></strong></pre>
<p>All done, in most cases, the software you are using has
documentation that will specify the entry, in the off case
it does not, sometimes it helps to try and find something
similar to the server program you will be adding. A
classic example of this is a MUD server which has built-in telnet.
You can pretty much borrow the telnet entry and change parts
where needed.</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="chap-inetd-use-or-not-use"></a>25.9. ×hen to use or not to use inetd</h2></div></div></div>
<p>The decision to add or move a service into or out of <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a>
is usually based on server load. As an example,
on most systems the telnet daemon does not require as
many new connections as say a mail server. Most of the
time the administrator has to feel out if a service should be moved.</p>
<p>A good example I have seen is mail services such as smtp and pop.
I had setup a mail server in which pop3 was in <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a> and
exim was running in standalone, I mistakenly assumed it
would run fine since there was a low amount of users,
namely myself and a diagnostic account. The server was also
setup to act as a backup MX and relay in case another
heavily used one went down. When I ran some tests I
discovered a huge time lag for pop connections remotely.
This was because of my steady fetching of mail and the
diagnostic user constantly mailing diagnostics back and forth.
In the end I had to move the pop3 service out of <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a>.</p>
<p>The reason for moving the service is actually quite interesting.
When a particular service becomes heavily used, of course,
it causes a load on the system. In the case of a service
that runs within the <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a> meta daemon the effects of a heavily
loaded service can also harm other services that use <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a>.
If the multiplexor is getting too many requests for one
particular service, it will begin to affect the performance of
other services that use <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a>. The fix, in a situation like
that, is to make the offending service run outside of <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a>
so the response time of both the service and <a class="citerefentry" href="http://netbsd.gw.com/cgi-bin/man-cgi?inetd+8.i386+NetBSD-7.1.1"><span class="citerefentry"><span class="refentrytitle">inetd</span>(8)</span></a> will increase.</p>
</div>
<div class="sect1">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="chap-inetd-resources"></a>25.10. Ïther Resources</h2></div></div></div>
<p>Following is some additional reading and information
about topics covered in this document.</p>
<p>NetBSD manual pages:</p>
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
<li class="listitem"><p><a class="ulink" href="http://netbsd.gw.com/cgi-bin/man-cgi/man?inetd+8+NetBSD-current" target="_top">inetd(8)</a></p></li>
<li class="listitem"><p><a class="ulink" href="http://netbsd.gw.com/cgi-bin/man-cgi/man?protocols+5+NetBSD-current" target="_top">protocols(5)</a></p></li>
<li class="listitem"><p><a class="ulink" href="http://netbsd.gw.com/cgi-bin/man-cgi/man?rpc+5+NetBSD-current" target="_top">rpc(5)</a></p></li>
<li class="listitem"><p><a class="ulink" href="http://netbsd.gw.com/cgi-bin/man-cgi/man?services+5+NetBSD-current" target="_top">services(5)</a></p></li>
<li class="listitem"><p><a class="ulink" href="http://netbsd.gw.com/cgi-bin/man-cgi/man?hosts_access+5+NetBSD-current" target="_top">hosts_access(5)</a></p></li>
</ul></div>
<p>Miscellaneous links:</p>
<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; ">
<li class="listitem"><p><a class="ulink" href="http://www.iana.org/numbers.htm" target="_top">IANA: Protocol Numbers and Assignment Services</a></p></li>
<li class="listitem"><p><a class="ulink" href="http://www.isi.edu/in-notes/rfc1700.txt" target="_top">RFC1700: Assigned Numbers</a></p></li>
</ul></div>
</div>
</div>
<div class="navfooter">
<hr>
<table width="100%" summary="Navigation footer">
<tr>
<td width="40%" align="left">
<a accesskey="p" href="chap-net-practice.html">Prev</a>/td>
<td width="20%" align="center"><a accesskey="u" href="part-net.html">Up</a></td>
<td width="40%" align="right">a accesskey="n" href="chap-dns.html">Next</a>
</td>
</tr>
<tr>
<td width="40%" align="left" valign="top">Chapter4. Óetting up TCP/IP on NetBSD in practice/td>
<td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td>
<td width="40%" align="right" valign="top"> Ãhapter6. Ôhe Domain Name System</td>
</tr>
</table>
</div>
</body>
</html>
![[BACK]](/icons/back.gif){kind=icon}
Return to chap-inetd.html CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [cvs.NetBSD.org] / htdocs / docs / guide / en