On Wed, Jun 10, 1998 at 07:11:38PM -0400, Eloy A. Paris wrote:
> Hi again Norbert,
>
> just one question: do you know if xinetd will continue to listen at
> traffic in a service's port after it has already forked the server for
> that service and wait=no?
Hm........ it will not answer the request for that service, but it will
not release the port either. I found this out using in.ntalkd:
Here are the results:
from master.debian.org, I run talk nveber@vtech.dyn.ml.org, in the local log
file:
Jun 11 18:40:53 vtech xinetd[22062]: START: ntalk pid=14282
from=205.229.104.5
the talk daemon runs:
nveber@vtech[~]$ ps aux | grep talk
nveber 14297 0.0 1.0 800 312 p1 R < 18:41 0:00 grep talk
root 14282 0.0 1.5 848 464 ? S < 18:40 0:00 in.ntalkd
root@vtech[~]# fuser ntalk/udp
ntalk/udp: 14282 22062
process 14282 is in.ntalkd, process 22062 is xinetd, it seems they can both
have the port open in the same time (somehow).
Any subsequent talk requests are ignored by xinetd (nothing in the log file)
and are handled by in.ntalkd (untill activity on the port stops, and
in.ntalkd exits)
With inetd:
Jun 11 18:58:09 vtech in.ntalkd[14574]: connect from debian.novare.net
root@vtech[~]# fuser ntalk/udp
ntalk/udp: 14559 14574
root@vtech[~]# ps aux | grep 14559
root 14559 0.0 1.4 868 456 ? S < 18:57 0:00 /usr/sbin/inetd
root@vtech[~]# ps aux | grep 14574
root 14574 0.0 1.5 848 464 ? S < 18:58 0:00 in.ntalkd
so it behaves the same way!
>
> Let's forget about the flags=RESUSE workaround. If this is the case
> nmbd gives this error message and exists:
>
> bind failed on port 137 socket_addr=130.89.222.95 (Address already in
> use)
Hmm.. perhaps the problem is with the way nmbd opens the port, although this
doesnt explain why it works in inetd and not xinetd..
>
> To me it looks like xinetd still has the socket open so nmbd can't open
> it and then it fails.
yes, that is what the error message means
>
> xinetd.conf's man page says about the wait parameter:
>
> wait This attribute determines if the service
> is single-threaded or multi-threaded. If
> its value is yes the service is single-
> threaded; this means that xinetd will
> start the server and then it will stop
> handling requests for the service until
> the server dies. If the attribute value
> is no, the service is multi-threaded and
> xinetd will keep handling new service
> requests.
>
> See where it says "if wait==yes then xinetd will start the server
> and then it will stop handling requests".
>
> The entry for nmbd in xinetd.conf should be:
>
> service netbios-ns
> {
> socket_type = dgram
> protocol = udp
> wait = yes
> user = root
> server = /usr/sbin/nmbd
> server_args = -a
> # flags = REUSE
> }
>
> See the setting for "wait" (yes).
>
> Do you think the error that is causing nmbd to exit (address already
> in use) is because xinetd is still listening at the netbios-ns port
> after is has forked nmbd?
I dont know anything about network programming, but I would imagine that
there is more than one way to open a port.. perhaps nmbd is doing something
odd which doesnt bother inetd, but xinetd doesnt like. The posibility that
this is an xinetd problem still exists though..
Attachment:
pgp_Tdc9QD9iV.pgp
Description: PGP signature