The Samba-Bugzilla – Bug 11886
smbclient goes into a tight loop after connecting
Last modified: 2016-06-19 16:36:17 UTC
Created attachment 12055 [details]
Output of smbclient running with `-d 10'
For years I've been using Samba-3 client to push FreeBSD backups onto a harddrive inside a set-top box running Samba-server (3.0.30).
After a recent upgrade of the client to 4.3.8 (without any changes to the server), I see the client going into a tight loop upon connecting -- consuming 100% of the CPU, not doing anything, and requiring a SIGKILL to kill.
If I run it interactively, I can see it connecting and giving me the command-prompt -- and THEN becoming unresponsive.
Created attachment 12056 [details]
Last 1000 lines of the kdump trace of smbclient process
Samba is compiled here with the options set thus:
ACL_SUPPORT : on
ADS : off
AD_DC : off
AIO_SUPPORT : on
AVAHI : off
BIND910 : off
BIND99 : off
CUPS : on
DEBUG : off
DEVELOPER : off
DNSUPDATE : off
DOCS : off
EXP_MODULES : off
FAM : on
LDAP : off
MANPAGES : on
MDNSRESPONDER : off
NSUPDATE : off
PAM_SMBPASS : off
PTHREADPOOL : off
QUOTAS : off
SYSLOG : on
UTMP : on
FWIW, recompiling with AIO_SUPPORT set to "off" didn't help either... Here is the full set of configure-arguments:
--mandir="/opt/man" --sysconfdir="/opt/etc" --includedir="/opt/include/samba4" --datadir="/opt/share/samba43" --libdir="/opt/lib" --with-pammodulesdir="/opt/lib" --with-privatelibdir="/opt/lib/samba" --with-modulesdir="/opt/lib/shared-modules" --with-pkgconfigdir="/opt/libdata/pkgconfig" --localstatedir="/var" --with-piddir="/var/run/samba4" --with-sockets-dir="/var/run/samba4" --with-privileged-socket-dir="/var/run/samba4" --with-lockdir="/var/db/samba4" --with-statedir="/var/db/samba4" --with-cachedir="/var/db/samba4" --with-privatedir="/var/db/samba4/private" --with-logfilebase="/var/log/samba4" --with-pam --with-iconv --with-winbind --without-gettext --with-sendfile-support --builtin-libraries=smbclient --with-acl-support --without-ad-dc --without-aio-support --disable-avahi --disable-dnssd --enable-cups --enable-iprint --without-dnsupdate --with-fam --without-pam_smbpass --disable-pthreadpool --without-quotas --with-syslog --with-utmp --without-ads --without-ldap --bundled-libraries="!talloc,!tevent,!tdb,!ldb,com_err" --with-shared-modules="vfs_zfsacl,vfs_zfsacl" --prefix=/opt -j4
FreeBSD builds Samba-ports against a separately built port of tevent. That port currently builds tevent-0.9.28, whereas the version bundled with samba-4.3.8 is only 0.9.25.
Thinking, that might be the problem, I rebuilt Samba with the bundled tevent and tried again. Did not help...
I have another machine on another network, which backs up to an identical set-top box -- those backups continued to work properly after the same upgrade. I can not identify anything different between the working and the non-working smbclients. If there is a particular detail you'd like me to check/compare on them, I'm eager to try.
I can also arrange for a Unix login on either or both systems -- they are Internet-accessible. Just post your desired /etc/passwd line and the public ssh-key here. Thanks!
Upgrading to 4.3.9 did not help either -- same problem. Bumping the "Version" field of this ticket.
Can you get a system call log whilst it's looping ? Also, build with -g and then get a full backtrace again whilst smbclient is looping.
(In reply to Jeremy Allison from comment #5)
> Can you get a system call log whilst it's looping ?
That's exactly, why my second attachment contains already.
> build with -g and then get a full backtrace again whilst smbclient is looping
(In reply to Jeremy Allison from comment #5)
> Also, build with -g and then get a full backtrace again whilst smbclient is looping.
This is proving harder, than we expected. Although the entire samba is compiled with -g, and neither the smbclient nor the just-built shared libraries are stripped, the stack is not readable:
#0 0x000000080453132a in ?? ()
#1 0x00000008055fb29b in ?? ()
#2 0x00007fffffffda40 in ?? ()
#3 0x00000000572b638d in ?? ()
#4 0x00000000000882ca in ?? ()
#5 0x00000008100c7160 in ?? ()
#6 0x0000000810039320 in ?? ()
#7 0x0000000000000001 in ?? ()
#8 0x00000008100c7160 in ?? ()
#9 0x00000008055fdc07 in ?? ()
#10 0x00007fffffffdab0 in ?? ()
#11 0x00000008055f905e in ?? ()
#12 0x0000000800000000 in ?? ()
#13 0x00000000d6938587 in ?? ()
#14 0x000000000036ee78 in ?? ()
#15 0x000000000003066b in ?? ()
#16 0x0000000000000000 in ?? ()
(gdb) info threads
The already posted syscall trace may have to suffice...
OK, poll() returns EINVAL. Is there a setting on your strace that allows dumping of the contents of the parameters to the poll() call ?
(In reply to Jeremy Allison from comment #8)
I think, it is trying to talk to DBUS -- and failing, because DBUS-daemon is not running...