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: <[EMAIL PROTECTED]> from Norbert Veber at "Jun 9, 98 08:36:30 pm" To: [EMAIL PROTECTED] (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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]