Sometimes, smbd CPU usage reaches 100% and remains there forever (or rather, until smbd is restated). I was not able to figure out the exact conditions of this. I have a suspicion that printing to the samba server may have something to do with that; however, I can also confirm that a couple times that happened when nothing was printed and shares weren't accessed. This is happening in 4.2.1, so I assume Bug 10663 is not applicable here.
P.S. 1) Nothing unusual in the logs. 2) This wasn't happening in 4.1.x
Info we need when it's in this state: strace -p <spinning-smbd-pid> and then attach to it with gdb -p <spinning-smbd-pid> and do a "bt" command to get a backtrace. Please build with -g before getting this info.
(In reply to Jeremy Allison from comment #2) Unable to do that. 1) strace is unavailable on my system (FreeBSD, remember?) 2) gdb sez: "internal-error: legacy_fetch_link_map_offsets called without legacy link_map support enabled.", and the stack trace is pretty much useless since it does not contain any labels, despite the fact that I `configure`d samba with --enable-debug. Talking of `configure`ation: --enable-debug --enable-fhs --exec-prefix=/usr/local --with-configdir=/usr/local/etc --prefix=/usr/local --with-piddir=/var/run --without-ad-dc --without-ldap --without-ads
> 1) strace is unavailable on my system (FreeBSD, remember?) http://lmgtfy.com/?q=strace+equivalent+on+freebsd should help. > 2) gdb sez: "internal-error: legacy_fetch_link_map_offsets called without legacy link_map support enabled.", http://lmgtfy.com/?q=freebsd+gdb+%22internal-error%3A+legacy_fetch_link_map_offsets+called+without+legacy+link_map+support+enabled.%22#seen also has a solution.
(In reply to Jeremy Allison from comment #4) Dear sir, I believe that you are competent enough to understand that it's always important to both give the precise instructions, and to follow the instructions given *exactly*. If someone is asked to run program A and give back the output, but instead I run a program B, how much help would be that? Yes, I can do my own investigation and find my own solutions. But the goal of this conversation is let me help *you* find the solution.
Actually in this case I just need the system call output, and the gdb backtrace. I think I just showed you how to do that on your given platform. But I can't gelp more until I get that info (that's why the bug status is still "NEEDINFO").
(In reply to Jeremy Allison from comment #2) Strange... as I said, I configured the build to include debug info (--enable-debug), but when I attach to the running process explicitly specifying the binary location, I'm still getting the backtrace without symbolds. Let me try to rebuild from a 100% clean slate. Meanwhile, I confirm that printing to a samba printer 100% triggers the behavior. It should be noted that the said printer is actually a https://wiki.samba.org/index.php/Virtual_PDF_Printer. While samba is spinning, nothing appears in the output, but once I restart samba, the output file finally appears as if nothing happened.
I rebuilt samba from scratch with --enable-debug, but gdb still gives me symbol-less stacktrace: gdb /usr/local/sbin/smbd 12345 [...] Attaching to program: /usr/local/sbin/smbd, process 12345 0x21cf0b1f in ?? () (gdb) bt #0 0x21cf0b1f in ?? () #1 0x2105dc82 in ?? () #2 0x22854bd0 in ?? () #3 0x00000004 in ?? () #4 0x0000ea48 in __FUNCTION__.31976 () Error accessing memory address 0xe9d2: Bad address. (gdb) q What am I doing wrong?
I don't know, sorry. You'll have to ask a FreeBSD expert.
New info: 1) 4.2.3 still has this issue. 2) 4.3.0rc2 does NOT seem to have this issue.
4.3.0 does NOT have this issue. Closing the bug/