Created attachment 9163 [details] Command line output and testing Running Samba 4.2.0pre1-GIT-3ddb77f on Fedora 19 64-bit, none of the samba or smbd binary services appear to respond when I start the samba binary under the single process model (-M single) Attached is the command line output, including various tests from the samba4 HOWTO wiki page, my smb.conf, and the 2 log files at log level = 9.
Created attachment 9164 [details] smb.conf used during the test
Created attachment 9165 [details] log.samba The logging that corresponds to the test in command-line-testing.txt starts around 2013/08/28 2:12:40
Created attachment 9166 [details] log.smbd The logging that corresponds to the test in command-line-testing.txt starts around 2013/08/28 2:12:40
Created attachment 9167 [details] Command line output and testing without single process model Although "wbinfo --online-status" did not work, the following tests do work when I start the samba binary without "-M single": wbinfo -u smbclient -L localhost -U% host -t SRV _ldap._tcp.samba4test.depaulo.org wbinfo -p kinit administrator@SAMBA4TEST.DEPAULO.ORG
I forgot to mention that my testing was done on a VM. The VM is hosted by Fedora 19 64-bit's Virt-Manager using qemu-kvm.
1. When I was producing this bug, I was launching samba with this command: ./samba -M single However, much to my surprise, this bug does NOT occur when I launch samba in interactive mode also: ./samba -i -M single Specifically, the same tests passed as when I was not using the single process model: wbinfo -u smbclient -L localhost -U% host -t SRV _ldap._tcp.samba4test.depaulo.org wbinfo -p kinit administrator@SAMBA4TEST.DEPAULO.ORG 2. When this bug does occur, netstat lists the samba binary's internal DNS server (port 53 on UDP) as having a large receive queue. At one point the receive queue was 198144. The send queue was 0. There were no other queues on my system with a value larger than 0.
(In reply to Michael DePaulo from comment #6) It is quite likely that we have a DNS lookup that is blocking, or does not share the same event context as the DNS server. Depending on what is blocking, because nested event loops (as needed to answer these queries) cause their own troubles, this may never be able to be fixed. However, I'm going to dare to mark it fixed with Samba 4.3, as the change to use the source3 winbindd code will have pushed the most likely DNS client into a distinct process. If you still want to chase it down, get a gdb backtrace with 'bt full' on any 'stuck' process and it will be very illuminating.