Question on daemon's under inetd

Question on daemon's under inetd

Post by Vikas Aggarw » Fri, 25 Dec 1992 15:40:05



In the past, I have come across several inetd daemons that are
started up by inetd when a connection on the particular port
comes in, and then *wait* for a small period of time
listening for any more incoming connections on their port before
exiting after a period of inactivity.

To me, this seems like an excellent idea- achieves the best of both
arguments (standalone via inetd daemon-- startup time vs. inactivity).

However (obviously), when I tried to do the same with a TCP daemon
that I wrote, the 'accept' call errored with 'socket not connected'.
I was doing an 'accept' on the file descriptor 0 handed to me by
'inetd'. Processing the first connection worked fine, but then I went
back to listening on the stdin (file desc 0 handed by inetd), the
accept() call returned immediately.

I tried playing around with the 'wait' vs. 'nowait' in the inetd.conf
file, but that did not help. Do I have to set some option on the
stdin/socket or open another socket and bind to it (as I would do in
a standalone server) ? Can't I reuse the file descr 0 handed to me by
'inetd' ??

Thanks, and appreciate emailing responses back to me also. Apologies if
this is an easy one and been discussed already.

-vikas                                                  Network Engineering

...rutgers!jvncnet!vikas                                (609) 258-2424 (fax)
                        JvNCnet, Princeton, NJ
-----------------------------------------------------------------------------

 
 
 

Question on daemon's under inetd

Post by Kartik Subbar » Sat, 26 Dec 1992 01:17:16



>In the past, I have come across several inetd daemons that are
>started up by inetd when a connection on the particular port
>comes in, and then *wait* for a small period of time
>listening for any more incoming connections on their port before
>exiting after a period of inactivity.

>To me, this seems like an excellent idea- achieves the best of both
>arguments (standalone via inetd daemon-- startup time vs. inactivity).

>However (obviously), when I tried to do the same with a TCP daemon
>that I wrote, the 'accept' call errored with 'socket not connected'.
>I was doing an 'accept' on the file descriptor 0 handed to me by
>'inetd'. Processing the first connection worked fine, but then I went
>back to listening on the stdin (file desc 0 handed by inetd), the
>accept() call returned immediately.

>I tried playing around with the 'wait' vs. 'nowait' in the inetd.conf
>file, but that did not help. Do I have to set some option on the
>stdin/socket or open another socket and bind to it (as I would do in
>a standalone server) ? Can't I reuse the file descr 0 handed to me by
>'inetd' ??

You can't issue an accept() on a socket given to you by inetd.

There are two different types of sockets at work here. One type of socket
is the one connected to the remote end of the connection. It is used as an
endpoint of communication, to which you can read and write arbitrary data.

The other type, which I'll call a "server socket", is used to maintain a queue
of incoming connections from different hosts to that port. When you issue the
listen() call on a socket, it sets the SO_ACCEPTCON flag in it, thus enabling
you to accept() on that socket. Writing to or reading from this kind of
sockets is useless. The only purpose of this socket is to return you
another socket (from accept()) through which you CAN read and write to the
remote host.

Inetd sets up a bunch of these server sockets on the well known ports. When
an incoming connection from another host is detected, accept() returns
a socket of the "normal" (read/write type) to inetd, and inetd gives you
this socket on fd's 0, 1 and 2. Note, this socket is bound to a different TCP
port than the server socket, so that you can potentially have multiple remote
hosts accessing your service. Here's where the wait/nowait comes in. If you
specify wait in /etc/inetd.conf, inetd will NOT allow multiple instances of
your daemon to run. That is, it will wait until the process is terminated
before it forks off another instance. If you specify nowait, then it will
fork off as many requests as it can handle, without waiting for any of them
to finish. Once again, the socket that inetd returns to you is a normal
read/write socket, so you cannot accept() on it, even after the connection is
closed. Even if you could, it would be useless, since it is not bound to the
well-known port.

        -Kartik

 
 
 

Question on daemon's under inetd

Post by Kartik Subbar » Tue, 29 Dec 1992 03:30:29


Once again, I must flame myself for a hastily submitted article (I had to
get on a plane in 30 minutes)



>>? Can't I reuse the file descr 0 handed to me by 'inetd' ??

>You can't issue an accept() on a socket given to you by inetd.

>There are two different types of sockets at work here. One type of socket
>is the one connected to the remote end of the connection. It is used as an
>endpoint of communication, to which you can read and write arbitrary data.

>The other type, which I'll call a "server socket", is used to maintain a queue
>of incoming connections from different hosts to that port. When you issue the
>listen() call on a socket, it sets the SO_ACCEPTCON flag in it, thus enabling
>you to accept() on that socket. Writing to or reading from this kind of
>sockets is useless. The only purpose of this socket is to return you
>another socket (from accept()) through which you CAN read and write to the
>remote host.

>Inetd sets up a bunch of these server sockets on the well known ports. When
>an incoming connection from another host is detected, accept() returns
>a socket of the "normal" (read/write type) to inetd, and inetd gives you
>this socket on fd's 0, 1 and 2.

Everything up to here is correct.

Quote:>Note, this socket is bound to a different TCP
>port than the server socket, so that you can potentially have multiple remote
>hosts accessing your service.

This is bullshit. The reader socket is bound to the same port as the
server socket. As far as the remote host is connected, it's the same
connection. You can still have multiple remote connections accessing your
service since the REMOTE port will be different for each connection.

Quote:>Here's where the wait/nowait comes in. If you
>specify wait in /etc/inetd.conf, inetd will NOT allow multiple instances of
>your daemon to run. That is, it will wait until the process is terminated
>before it forks off another instance. If you specify nowait, then it will
>fork off as many requests as it can handle, without waiting for any of them
>to finish. Once again, the socket that inetd returns to you is a normal
>read/write socket, so you cannot accept() on it, even after the connection is
>closed.

This is correct.

Quote:>Even if you could, it would be useless, since it is not bound to the
>well-known port.

This is wrong, just as before.

Sorry 'bout that folks.  Happy holidays! :-)

        -Kartik

 
 
 

Question on daemon's under inetd

Post by Vikas Aggarw » Tue, 29 Dec 1992 19:44:12



>Once again, I must flame myself for a hastily submitted article (I had to
>get on a plane in 30 minutes)


>>>? Can't I reuse the file descr 0 handed to me by 'inetd' ??

>>You can't issue an accept() on a socket given to you by inetd.

... stuff deleted

Quote:>>Note, this socket is bound to a different TCP
>>port than the server socket, so that you can potentially have multiple remote
>>hosts accessing your service.
>This is bullshit. The reader socket is bound to the same port as the
>server socket. As far as the remote host is connected, it's the same
>connection. You can still have multiple remote connections accessing your
>service since the REMOTE port will be different for each connection.
>>Here's where the wait/nowait comes in. If you
>>specify wait in /etc/inetd.conf, inetd will NOT allow multiple instances of
>>your daemon to run. That is, it will wait until the process is terminated
>>before it forks off another instance. If you specify nowait, then it will
>>fork off as many requests as it can handle, without waiting for any of them
>>to finish. Once again, the socket that inetd returns to you is a normal
>>read/write socket, so you cannot accept() on it, even after the connection is
>>closed.
>This is correct.
>>Even if you could, it would be useless, since it is not bound to the
>>well-known port.
>This is wrong, just as before.

Back to my original question.. can I reuse the file descriptor handed to
me by inetd ? Specifying 'wait' in the inetd.conf file would essentially
tell inetd to wait for the original program to exit.. and if possible,
I would like to tell the inetd forked process to bind to the port and
handle all future requests.

Incidentally, I *have* been using bootp and tftp code that actually
does what I had described (server hangs around for a period of time
before exiting). Both are UDP datagram services, and they set an
alarm before entering an endless loop.. I am attaching the relevant
code below.

 -vikas                                                     (609) 258-2403

--------------------------------------------------------------------------

Dec 26 16:42:32 nisc bootpd[9822]: server starting
Dec 26 16:42:32 nisc bootpd[9822]: from 162.58.1.2.
Dec 26 16:42:32 nisc bootpd[9822]: (re)reading /etc/bootptab
Dec 26 16:42:32 nisc bootpd[9822]: Searching for 656d61696
Dec 26 16:42:32 nisc bootpd[9822]: No match by hardware addr
Dec 26 16:47:20 nisc bootpd[9822]: from 162.58.1.2.
Dec 26 16:47:20 nisc bootpd[9822]: Searching for 656d61696
Dec 26 16:47:20 nisc bootpd[9822]: No match by hardware addr
Dec 26 16:49:20 nisc bootpd[9822]: from 162.58.1.2.
Dec 26 16:49:20 nisc bootpd[9822]: Searching for 656d61696
Dec 26 16:49:20 nisc bootpd[9822]: No match by hardware addr
Dec 26 16:54:33 nisc bootpd[9822]: Server exiting after 300 secs inactivity

        signal(SIGALRM, onalarm);
        lastmsgtime = time(0);
        alarm(15);
        for (;;) {
                fromlen = sizeof(from);
                n = recvfrom(0, buf, sizeof (buf)-1, 0, &from, &fromlen);
                if (n < 0) {
                        if (errno != EINTR)
                                sleep(1);
                        syslog(LOG_INFO, "recvfrom failed %d (%s)",
                               n, sys_errlist[errno]);
                        errno = 0;
                        continue;
                }
                syslog(LOG_INFO, "from %s.\n", inet_ntoa( from.sin_addr ));
                bp = (struct bootp *) buf;
                if (n < sizeof *bp)
                    continue;
                readtab();                      /* (re)read the bootptab */
                sigblock(1<<SIGALRM);
                lastmsgtime = time(0);
                switch (bp->bp_op) {
                case BOOTREQUEST:
i                        request();
                        break;

                case BOOTREPLY:
                        reply();
                        break;
                }
                sigsetmask(0);
        }

 
 
 

1. Q inetd/sockets: how to run my daemon from inetd???

Hi all,

I  wrote  this  really  insignificant program that listens on a port and
writes  a fortune message down the socket, and now I want to run it from
inetd.  So  I  made  entries in /etc/inetd.conf and /etc/services and it
doesn't work.

The  problem  is I guess that I my daemon creates a socket and listen on
it,  then  accepts connections, does its thing and exits. However, inetd
is  listening  on  that  port and execl()'s my fortuned which then finds
the socket in use already and dies on a failed bind.

So  how  can  I  make it so that it knows which file descriptors it gets
from  inetd?  Or,  should  I  rather  have  it run in the background and
fork()  to serve every connection without ever exiting?

Bo.

--
        "Heisenberg may have been here".

2. Father and son

3. Internet can't connect to non inetd daemons

4. Install printer

5. super super daemon inetd question ..

6. pci=biosirq at boot hang

7. Question about 'inetd' -- where is stdin/stdout?

8. HTTP_PAYMENT_REQUIRED

9. questions about lpc - what does 'no daemon present' mean?

10. Daemon vs inetd

11. What daemons started in inetd.conf ? Any command ?

12. programming daemons spawned by inetd

13. Daemons started by Inetd