Re: how to start ftp daemon - the whole scoop

["Binand Raj S." <binand@xxxxxxxxxxxxxx>]

Dr. P. Sriram forced the electrons to say:
> well, smily apart, it depends. if a machine is used as an ftp server
> (repository), i will bet ftpd is started as part of boot sequence. so

OK, that is true. And in the case of inetd also, the port number is bound to,
the moment inetd is started. That is, instead of the program, (eg. ftpd on
port 21) it is inetd that is listening on that port. When a connection comes
in, inetd hands control of the port to the program that is actually supposed
to listen there. So, when I said telnetd is not started at boot time, what I
meant was that the program telnetd is not started, but the telnet port is
bound to; ie, the service on the telnet port is started.

> daemon) or as a start-on-demand call through inetd. inetd will start the
> appropriate server daemon on demand and upon completion of the job, the
> daemon will quit. the next time a connection is made, inetd will go over

I hate to be seen cribbing, but there is a fundamental difference here.
Stevens defines a daemon process as "a program started at boot time, and
typically living though the entire uptime of the system, offering specialised
services" (not the exact wording, though - quoting from memory). So, in this
case, inetd is the server daemon - and it just starts a process whose lifetime
is very short - for example, the time it takes you to download a file, in the
case of ftpd.

> various things it does, sendmail is rather slow to start and hence, it is
> usually not a good idea to start sendmail from inetd.conf. otherwise, it

Thus we have an example of a service that can be either started standalone, or
from inetd - sendmail is standalone, whereas qmail runs from inetd.

One of the reasons people choose to write programs that run from inetd is that
since almost all of the network programs' startup code is the same, it is
quite pointless for every process to execute the same instructions. Even
though http and smtp are quite different services, the initial parts of the
code for apache and sendmail will be essentially the same. So, this part of
the code is separated from the actual server, and is incorporated in the
superserver, inetd. Thus, you can forget your worries about the socket system
call, forget about errno = EINTR and so on. You can have shell scripts as tcp
servers! and a lot of other things.

OTOH, if we run something like squid from inetd, just think of the number of
processes needed - every incoming request, for a HTML page and for all the
images in it (let us say there are 20 of them) there will be 21 squid
processes running, each spawning their children to actually fetch the URLs!

This is the essential difference between these two methods of offering
internet services. If the service offered is simple, then run it from inetd,
and if the service is very resource consuming, offer it as standalone. I have
been running a dynamic DNS update service from inetd with an entry each in
/etc/services and /etc/inetd.conf, and ever since, I haven't had to worry
about the select system call. :-)

For more info, there is a section on inetd in Unix Network Programming
Vol I by Stevens.

Binand

PS: Here is an example of a shell script that runs as a network
server. You can replace the fingerd line in /etc/inetd.conf with this
program, and now everytime someone fingers you, he gets to see a new plan!

#! /bin/sh

(echo ""; /usr/games/fortune -s) > /home/binand/.plan
exec /usr/sbin/in.fingerd

---
Send e-mail to 'ilugc-request@xxxxxxxxxxxxxxxxxx' with 'unsubscribe' 
in either the subject or the body to unsubscribe from this list.