xinetd

Hi,

I've been looking at xinetd, and I was wondering if the following is
possible.
I have a service that waits for incoming TCP requests and sends a
response to a client. Say that the service listens at port 10000.
The configuration is as follows:

service myservice
{
disable = no
socket_type = stream
wait = yes
user = root
server = /path/to/myservice
port = 10000
protocol = tcp
}

The objective is to have xinetd listening at port 10000 and when the
first request comes in to start up 'myservice'. This all works. The
problem is that I want 'myservice' to listen at port 10000 once it's
started. But that fails because xinetd does not close the socket it is
listening on while waiting for 'myservice' to finish (so bind in
'myservice' fails).
Is there a workaround to take over control of the listening socket?
Setting wait to no is not an option as this generates multiple instances
of 'myservice' and that is not what I want.

Kind regards,
Sigrid

Sigrid Thijs wrote:
> Hi,
>
> I've been looking at xinetd, and I was wondering if the following is
> possible.
> I have a service that waits for incoming TCP requests and sends a
> response to a client. Say that the service listens at port 10000.
> The configuration is as follows:
>
> service myservice
> {
> disable = no
> socket_type = stream
> wait = yes
> user = root
> server = /path/to/myservice
> port = 10000
> protocol = tcp
> }
>
> The objective is to have xinetd listening at port 10000 and when the
> first request comes in to start up 'myservice'. This all works. The
> problem is that I want 'myservice' to listen at port 10000 once it's
> started. But that fails because xinetd does not close the socket it is
> listening on while waiting for 'myservice' to finish (so bind in
> 'myservice' fails).
> Is there a workaround to take over control of the listening socket?
> Setting wait to no is not an option as this generates multiple instances
> of 'myservice' and that is not what I want.
>
> Kind regards,
> Sigrid
xinetd is more about starting "one-shot" services on demand rather than
starting up a permanent daemon.

If you want to start a continuously listening daemon, start it from the
rc scripts.

B.

Sigrid Thijs wrote:

> Hi,
>
> I've been looking at xinetd, and I was wondering if the following is
> possible.
> I have a service that waits for incoming TCP requests and sends a
> response to a client. Say that the service listens at port 10000.
> The configuration is as follows:
>
> service myservice
> {
> disable = no
> socket_type = stream
> wait = yes
> user = root
> server = /path/to/myservice
> port = 10000
> protocol = tcp
> }
try
wait = no

--
Michael T. Pogoreltsev, Astronomical observatory
38 (044) 2162391, Observatorna st. 3, Kiev 04053

On Wed, 11 May 2005 07:13:03 +0000, Buzzbomb wrote:


> xinetd is more about starting "one-shot" services on demand rather than
> starting up a permanent daemon.
>
> If you want to start a continuously listening daemon, start it from the
> rc scripts.

That's what I thought so. It would have been nice if it was possible
to delay the startup of the service until it was necessary.

Kind regards,
Sigrid

Hi Sigrid,

On 2005-05-10, Sigrid Thijs <(E-Mail Removed)> wrote:
> Hi,
>
> I've been looking at xinetd, and I was wondering if the following is
> possible.
> I have a service that waits for incoming TCP requests and sends a
> response to a client. Say that the service listens at port 10000.
> The configuration is as follows:
>
> [snipped]
>
> The objective is to have xinetd listening at port 10000 and when the
> first request comes in to start up 'myservice'. This all works. The
> problem is that I want 'myservice' to listen at port 10000 once it's
> started. But that fails because xinetd does not close the socket it is
> listening on while waiting for 'myservice' to finish (so bind in
> 'myservice' fails).
>
This is expected. (x)inetd really shunts things that would use STDIN/STDOUT
but throw it through a network socket instead. Think of it more like netcat
if you are familar with that tool.

If you look at using samba/dictd/whatever via (x)inetd you will notice that
you have to pass a parameter to it to tell it to go into inetd mode, you
might also notice it then takes input/output on STDIN/STDOUT.

> Is there a workaround to take over control of the listening socket?
> Setting wait to no is not an option as this generates multiple instances
> of 'myservice' and that is not what I want.
>
Personally I would not worry. If it truely is a service that is rarely used
then it will load, wait for an incoming connection and then service that
request. If its un-used it will get swapped out and not bother anything.

Cheers

Alex

> Kind regards,
> Sigrid

On Thu, 12 May 2005 21:43:38 +0000, Sigrid Thijs wrote:

> On Wed, 11 May 2005 07:13:03 +0000, Buzzbomb wrote:
>
>
>> xinetd is more about starting "one-shot" services on demand rather than
>> starting up a permanent daemon.
>>
>> If you want to start a continuously listening daemon, start it from the
>> rc scripts.
>
> That's what I thought so. It would have been nice if it was possible to
> delay the startup of the service until it was necessary.
>
> Kind regards,
> Sigrid
How about having xinetd execute a script that then executes that permanent
daemon? The script would die but if the daemon kept working. Maybe ?

I can't get openSSH to work for the same reason and I would like CUPS to
work the same way : Rarely needed so don't have them running until they
are needed.