How does inetd transfer control to respective services?

Question

How does inetd transfer control to the service, Below is my understanding

inetd listens on every port mentioned in /etc/inetd.conf
If a client make a request to one of the port that inetd listens then inetd transfers control of that request to a service by spinning it as a child process by looking /etc/inetd.conf
It is acts as multiplexer.

My doubt is below

How the request is handover to the child process (respective service daemon)?
Already connection is made on the port by inetd so child process can't that port again until the inetd releases that port. If inetd releases that port then existing client connection will be droped (kindly correct me if my understanding is wrong).

score 2 · Accepted Answer · edited Jun 11 '20 at 14:16

2

inetd listens on a port, and then connects it to the stdin, stdout, and stderr of the service that will process it.

How does it do it

After accepting the connection, it has a socket on one of its fds.
It will then duplicate the fd to 0,1,and 2.
It will then fork. All file descriptors will remain open, unless some action is taken to close them (so 0,1, and 2 remain open).
The child process will then call exec, fds still remain open.
The service is now running with the remote client connected to stdin (0), stdout (1), and stderr (2).
The service just needs to know that the client is on these file-descriptors, and not do a listen of its own.

(I did some searching, but can't see inetd telling the service program that it was called by inetd. I would expect a command line argument.)

edited Jun 11 '20 at 14:16

Community

1

answered Mar 14 '20 at 17:24

ctrl-alt-delor

27,473
9
58
102

You shouldn't really expect a command-line argument. Interacting with standard I/O is not some special non-default mode. Even picking up the port and address information can be done within the normal Unix framework. http://jdebp.uk./FGA/UCSPI.html – JdeBP Mar 14 '20 at 20:35
@JdeBP so how does the server know that it has been started with the client on stdin/out/err? Does the process have to introspect the fd, to see what type it is? – ctrl-alt-delor Mar 14 '20 at 21:30
You are still assuming modality. This is not a special non-default mode that a program has to detect and enter. This is the program behaving normally, interacting with its standard I/O, which just happens to be sockets but for most application protocols does not actually have to be. – JdeBP Mar 16 '20 at 10:16
@JdeBP yes most programs interact with stdin/out/err. But a network server, may be used with or without inetd. If without, then it would not use stdin/out. – ctrl-alt-delor Mar 16 '20 at 13:00
If used without inetd it still uses standard I/O, and ends up speaking its protocol with something that isn't a socket, or terminating with a fatal error because some socket API call has failed on file descriptor 0 (as, for example, `in.talkd` does). – JdeBP Mar 20 '20 at 20:24

score 0 · Answer 2 · edited Mar 14 '20 at 16:43

0

Consider actions like this:

[parent]

sfd = socket(), listen(), connect(), fork();

For other descriptors that should not be inherited by child processes, close() or previously set them to FD_CLOEXEC; after fork, parent could close this sfd

[child]

execve(); copy of connected socket descriptor inherited, can use for client I/O

edited Mar 14 '20 at 16:43

ctrl-alt-delor

27,473
9
58
102

answered Mar 14 '20 at 12:25

forest

129
2

ahhh, nice point. tnx @forest. – Karthik Nedunchezhiyan Mar 14 '20 at 13:27
I don't understand this answer, and I know roughly what happens. – ctrl-alt-delor Mar 14 '20 at 16:44

score 0 · Answer 3 · answered Mar 16 '20 at 07:00

0

It is neatly explained in Que-Linux-Socket-Programming under the section The Design Parameters of inetd Servers

answered Mar 16 '20 at 07:00

Karthik Nedunchezhiyan

737
9
22

How does inetd transfer control to respective services?

3 Answers3

How does it do it