Re: xinetd and portmap (fwd)
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?
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)
To me it looks like xinetd still has the socket open so nmbd can't open
it and then it fails.
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?
See ya!
E.-
----- Forwarded message from eparis -----
>From eparis Wed Jun 10 10:59:10 1998
Subject: Re: xinetd and portmap
In-Reply-To: <19980609203630.A20445@vtech.dyn.ml.org> from Norbert Veber at "Jun 9, 98 08:36:30 pm"
To: nveber@vtech.dyn.ml.org (Norbert Veber)
Date: Wed, 10 Jun 1998 10:59:10 -0400 (VET)
Cc: debian-devel@lists.debian.org
X-Mailer: ELM [version 2.4ME+ PL39 (25)]
Hi Norbert,
> It used to be there, but then it was rejected :) I am fixing it now as we
> speak (along with some other fixes). It should be uploaded again by
> tomorrow at the latest (tonight is more likely).
Great, I got it and installed it. Using it right now.
> Hurray, hurray !
>
> I find today a solution, you need add " flag=REUSE" for nmbd (service
> netbios-ns) section in xinetd.conf. nmbd is started from xinetd and I see
> that it runs.
Uhhmmm, not quite. Adding "flags=REUSE" to service netbios-ns in
xinetd.conf prevents the problem described in the bugs reported against
xinetd and samba to happen. However, the way it leaves nmbd running is
not the way it should be.
Normally, when nmbd is run from inetd, nmbd is started by inetd when
there is traffic in the netbios-ns port (UDP port 137). nmbd is
started with wait because nmbd is supposed to stay running forever
(or until killed with SIGTERM), so inetd _must not_ fork another nmbd
process.
Then, when nmbd starts it starts listening at the NetBIOS Datagram
service port (netbios-dgm - UDP port 138).
If when running from inetd nmbd receives a SIGTERM signal it'll shut
down and exit. Later, inetd will start another nmbd but only if there
is activity on the netbios-ns port.
With xinetd running nmbd and with flags=REUSE, xinetd restarts another
nmbd process without waiting for activity on the netbios-ns port:
polux:~# ps ax|grep nmbd
2054 ? S 0:00 nmbd -a
polux:~# killall nmbd
polux:~# ps ax|grep nmbd
2071 ? S 0:00 nmbd -a
The above was done without connection to the Ethernet.
So, summarizing, the behavior is not exactly the same as with inetd.
Also, I don't understand why "flags=REUSE" is needed so nmbd can run
from xinetd. Any ideas?
> Add this to docs and close this bug :)
I agree with you that you do not close this bug (and I won't close the
one reported against Samba) until we figure out what's going on here.
I do think you need to decrease the severity level of your bug from
Critical/Important to Normal because it is preventing Hamm to be
released.
> This does fix the bug, or I guess its more of a workaround?
It looks to me like a workaround (see above to know why I think so).
> PS. I havent tested this fix yet as I dont have/use samba, could you please
> confirm that this works?
Yup, the works around work but it does not work as with inetd (the
expected behavior, I think).
> PPS. After writing all of the above crap, I realized that you are the samba
> maintainer and probably allready know most of what I said above :)
I know a little about Samba but until yesterday I did not know
anything about xinetd. Now I think I do :-)
Bye for now.
peloy.-
----- End of forwarded message from eparis -----
--
Eloy A. Paris
Information Technology Department
Rockwell Automation Venezuela
Telephone: +58-2-9432311 Fax: +58-2-9431645
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: