[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: xinetd and portmap



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.-

-- 

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: