SOLVED Samba: smbd processes using all available CPU, not responsive, don't react to signals

[anodos]

Try turning off your btsync jail and see if the problem still occurs.

 

[fsfsfs]

Turned it off for now. I will see how long I get by by running the sync once a day or so.

 

[fsfsfs]

I'd say this is unrelated to the btsync jail:

I have a new 100% CPU smbd process since yesterday 6PM without the btsync jail running. Also I haven't started the btsync jail manually. I was planning to sync once a day, but haven't done this so far.

 

[fsfsfs]

Is there a best practice way of installing a package with debug symbols on freenas?

I am really curious what smbd is doing there.

 

[anodos]

Is there a best practice way of installing a package with debug symbols on freenas?

I am really curious what smbd is doing there.

Check debug.txg here: https://download.freenas.org/11/11.1-U5/x64/
(or the correct version for what you are using). You can load the symbols for smbd in gdb.

 

[anodos]

Based on the pcaps, I'd say we're spinning at auth. Can you send a sig 6, generate a core for the smbd and send it to me via pm.

 

[fsfsfs]

Sorry for not being very responsive - my vacation started on Tuesday.

About debug.txg: Can I install this file additionally to my current OS using the Manual Upgrade button in the web UI? Or will it overwrite everything? Will it restart the NAS? Sorry for these plain questions - I couldn't find this info on the web and since I'm logging in from quite remote now... I'd rather not kill the system

Can you send a sig 6, generate a core for the smbd and send it to me via pm

You got it. Thank you again!

 

[anodos]

Sorry for not being very responsive - my vacation started on Tuesday.

About debug.txg: Can I install this file additionally to my current OS using the Manual Upgrade button in the web UI? Or will it overwrite everything? Will it restart the NAS? Sorry for these plain questions - I couldn't find this info on the web and since I'm logging in from quite remote now... I'd rather not kill the system

You can put the same version of FN in a VM, copy the debugging symbols txg file, extract it, copy the core file, then use the debugging symbols for smbd to investigate the core.

 

[fsfsfs]

Splendid idea, thanks for sharing! I can't do that ATM :( Time constraints and I don't have a capable machine at home.

Err. I just saw that it's a .txz file. I misread or misspelled it and didn't even understand it till now. I can just extract it on the NAS box itself. Sorry for being slow (it's hot here, lol)

I don't know the internals of smbd as you do, but with that I can also play around a little :)

 

[fsfsfs]

*bump* Back from my summer holiday :)

Could you see anything in that core dump, @anodos ?

I'll update to 11.1-U6 tonight, maybe upstream has already fixed this issue.

 

[fsfsfs]

Have been running 11.1-U6 now for a few days without this issue :)

The only hiccup, most probably unrelated: our Linux clients couldn't connect in the beginning because of some protocol mismatch. Took me a while to find out adding

Code:

client max protocol = SMB3_10

to their /etc/samba/smb.conf's

Code:

[global]

section resolved that.

Will test some more for a week or so and then mark as solved.

 

[fsfsfs]

11.1-U6 running stable for a full week now, seems the update resolved this issue. Don't know how though? Nevermind, marking as solved.

Thank you again @anodos @ewhac and everyone!