Bug 3779 - Potential hang in nmbd
Potential hang in nmbd
Product: Samba 3.0
Classification: Unclassified
Component: nmbd
x86 Linux
: P3 normal
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2006-05-16 03:51 UTC by john williams
Modified: 2006-05-19 21:11 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description john williams 2006-05-16 03:51:56 UTC
I'm reporting this for the version of Samba that I'm running (Debian stable), but I don't think the issue is unique to that version.

The code of the nmbd program calls select() in the listen_for_packets() function
in nmbd/nmb_packets.c. If this returns successfully, it then calls read_packet()
to read from a socket. The read_packet() function in libsmb/nmblib.c calls
read_udp_socket() in lib/util_sock.c, which calls sys_recvfrom() which is a 
wrapper around the recvfrom() system call.

The problem is that the recvfrom() is a blocking call, so if there is no
datagram waiting to be read, the program ends up waiting forever. I haven't
puzzled out yet why this is happening on my machine, but the man page for
select() explicitly warns that a read might block when select() had reported the
handle as ready for reading, so read following a select() should always be
non-blocking. So I think the blocking read is a bug in the Samba code, at least in the Linux version.
Comment 1 Christian Perrier 2006-05-17 23:05:16 UTC
This bug is Debian bug #367472 (http://bugs.debian.org/367472).

The bug submitter confirmed that the bug is still in 3.0.22
Comment 2 Jeremy Allison 2006-05-17 23:08:28 UTC
Ok, I know what to do here. We need to make the udp sockets used in nmbd non-blocking and handle EWOULDBLOCK/EAGAIN. No biggie - I should be able to have this done for 3.0.23 RC1.
Comment 3 Jeremy Allison 2006-05-19 21:11:32 UTC
Fixed for 3.0.23.