Bug 10119 - samba and smbd binaries do not respond when running as a "single" process
Summary: samba and smbd binaries do not respond when running as a "single" process
Status: RESOLVED FIXED
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: unspecified
Hardware: x64 Linux
: P5 normal (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-28 06:28 UTC by Michael DePaulo
Modified: 2017-01-03 07:30 UTC (History)
2 users (show)

See Also:


Attachments
Command line output and testing (19.35 KB, text/plain)
2013-08-28 06:28 UTC, Michael DePaulo
no flags Details
smb.conf used during the test (399 bytes, application/octet-stream)
2013-08-28 06:29 UTC, Michael DePaulo
no flags Details
log.samba (157.14 KB, text/plain)
2013-08-28 06:32 UTC, Michael DePaulo
no flags Details
log.smbd (315.23 KB, text/plain)
2013-08-28 06:33 UTC, Michael DePaulo
no flags Details
Command line output and testing without single process model (1.92 KB, text/plain)
2013-08-28 06:41 UTC, Michael DePaulo
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael DePaulo 2013-08-28 06:28:45 UTC
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.
Comment 1 Michael DePaulo 2013-08-28 06:29:38 UTC
Created attachment 9164 [details]
smb.conf used during the test
Comment 2 Michael DePaulo 2013-08-28 06:32:43 UTC
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
Comment 3 Michael DePaulo 2013-08-28 06:33:22 UTC
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
Comment 4 Michael DePaulo 2013-08-28 06:41:17 UTC
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
Comment 5 Michael DePaulo 2013-08-28 07:11:14 UTC
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.
Comment 6 Michael DePaulo 2013-08-28 14:37:08 UTC
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.
Comment 7 Andrew Bartlett 2017-01-03 07:30:14 UTC
(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.