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 Will do...
(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: (gdb) where #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 (gdb) 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...
is this still an issue with the latest Samba versions?