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.
This bug is Debian bug #367472 (http://bugs.debian.org/367472).
The bug submitter confirmed that the bug is still in 3.0.22
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.
Fixed for 3.0.23.