Bug 11263 - smbd 100% CPU usage
Summary: smbd 100% CPU usage
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.2.1
Hardware: x64 FreeBSD
: P5 normal (vote)
Target Milestone: ---
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
Depends on:
Reported: 2015-05-07 22:43 UTC by samba
Modified: 2015-09-22 06:42 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description samba 2015-05-07 22:43:49 UTC
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.
Comment 1 samba 2015-05-07 22:49:07 UTC

1) Nothing unusual in the logs.
2) This wasn't happening in 4.1.x
Comment 2 Jeremy Allison 2015-05-07 22:50:35 UTC
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.
Comment 3 samba 2015-05-08 02:53:23 UTC
(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
Comment 4 Jeremy Allison 2015-05-08 15:27:41 UTC
> 1) strace is unavailable on my system (FreeBSD, remember?)


should help.

> 2) gdb sez: "internal-error: legacy_fetch_link_map_offsets called without legacy link_map support enabled.",


also has a solution.
Comment 5 samba 2015-05-08 15:37:48 UTC
(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.
Comment 6 Jeremy Allison 2015-05-08 15:46:05 UTC
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").
Comment 7 samba 2015-05-08 15:59:31 UTC
(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.
Comment 8 samba 2015-05-08 21:37:40 UTC
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?
Comment 9 Jeremy Allison 2015-05-08 21:38:54 UTC
I don't know, sorry. You'll have to ask a FreeBSD expert.
Comment 10 samba 2015-08-05 20:55:39 UTC
New info:

1) 4.2.3 still has this issue.
2) 4.3.0rc2 does NOT seem to have this issue.
Comment 11 samba 2015-09-22 06:42:10 UTC
4.3.0 does NOT have this issue. Closing the bug/