[Samba] Can one set limits on new core dump?

Tue May 16 07:05:24 GMT 2006

James Peach wrote:
> On Mon, 15 May 2006 09:40 pm, Doug VanLeuven wrote:
>> James Peach wrote:
>>> On Sat, 13 May 2006 12:16 am, Gerald (Jerry) Carter wrote:
>>>> James,
>>>>
>>>> This was your change right ?
>>> Yup. It's deliberately not configurable so that we can always get
>>> *something* that might help with fault diagnosis.
>>>
>> Is there a chance for some kind of compromise?
> 
> Of course.
> 
>> winbindd cranked out hundreds of core dumps in less time than
>> it took to get a cup of coffee.
> 
> Do you have some core-naming facility that renames the core files
> something other than "core"? I'm trying to understand why you ended up
> with more that one core file ....

I running FC4, I didn't invoke any core naming facility, but
sometimes Fedora adds functionality I'm not aware of.
The samba core dumps for winbindd ended up core.<pid>

Partial list
[root at gate var]# l cores/winbindd
total 18076
-rw-------  1 root root 1069056 May 12 03:22 core.19692
-rw-------  1 root root 1028096 May 12 03:22 core.19693
-rw-------  1 root root 1044480 May 12 03:22 core.19696
-rw-------  1 root root 1028096 May 12 03:22 core.19697
-rw-------  1 root root 1044480 May 12 03:23 core.19703
-rw-------  1 root root 1028096 May 12 03:23 core.19704
-rw-------  1 root root 1044480 May 12 03:23 core.19710
-rw-------  1 root root 1028096 May 12 03:23 core.19711
-rw-------  1 root root 1175552 May 12 03:24 core.19714
-rw-------  1 root root 1163264 May 12 03:24 core.19715
-rw-------  1 root root 1122304 May 12 02:03 core.6081
-rw-------  1 root root 1081344 May 12 02:03 core.6082
-rw-------  1 root root 1097728 May 12 02:04 core.6090
-rw-------  1 root root 1081344 May 12 02:04 core.6091
-rw-------  1 root root 1097728 May 12 02:04 core.6101
-rw-------  1 root root 1081344 May 12 02:04 core.6102
-rw-------  1 root root 1224704 May 12 02:04 core.6111

log.winbindd-idmap:
[2006/05/12 03:22:12, 0] lib/fault.c:fault_report(42)
   INTERNAL ERROR: Signal 11 in pid 19692 (3.0.23pre2-SVN-build-15162)
   Please read the Trouble-Shooting section of the Samba3-HOWTO
[2006/05/12 03:22:12, 0] lib/fault.c:fault_report(44)

   From: http://www.samba.org/samba/docs/Samba3-HOWTO.pdf
[2006/05/12 03:22:12, 0] lib/fault.c:fault_report(45)
   ===============================================================
[2006/05/12 03:22:12, 0] lib/util.c:smb_panic(1592)
   PANIC (pid 19692): internal error
[2006/05/12 03:22:12, 0] lib/util.c:log_stack_trace(1699)
   BACKTRACE: 24 stack frames:
    #0 /usr/local/samba3/sbin/winbindd(log_stack_trace+0x26) [0x837b1a]
    #1 /usr/local/samba3/sbin/winbindd(smb_panic+0x5e) [0x8379e2]
    #2 /usr/local/samba3/sbin/winbindd [0x826420]
    #3 /usr/local/samba3/sbin/winbindd [0x82642e]
    #4 [0x110420]
    #5 /usr/local/samba3/sbin/winbindd(sid_binstring+0x1d) [0x8325a5]
    #6 /usr/local/samba3/lib/idmap/ad.so [0xb684f3]
    #7 /usr/local/samba3/sbin/winbindd(idmap_set_mapping+0x26c) [0x9044c9]
    #8 /usr/local/samba3/sbin/winbindd(winbindd_dual_idmapset+0xb0) [0x7e86c2]
    #9 /usr/local/samba3/sbin/winbindd [0x7e7155]
    #10 /usr/local/samba3/sbin/winbindd [0x7e8135]
    #11 /usr/local/samba3/sbin/winbindd [0x7e6db8]
    #12 /usr/local/samba3/sbin/winbindd(async_request+0x14e) [0x7e6a22]
    #13 /usr/local/samba3/sbin/winbindd [0x7e8373]
    #14 /usr/local/samba3/sbin/winbindd(idmap_sid2gid_async+0xd1) [0x7e8f0b]
    #15 /usr/local/samba3/sbin/winbindd [0x7eb780]
    #16 /usr/local/samba3/sbin/winbindd [0x7e96b4]
    #17 /usr/local/samba3/sbin/winbindd [0x7e8277]
    #18 /usr/local/samba3/sbin/winbindd [0x7e6d73]
    #19 /usr/local/samba3/sbin/winbindd [0x7c6988]
    #20 /usr/local/samba3/sbin/winbindd [0x7c7560]
    #21 /usr/local/samba3/sbin/winbindd(main+0x641) [0x7c7eac]
    #22 /lib/libc.so.6(__libc_start_main+0xdf) [0x1c1d7f]
    #23 /usr/local/samba3/sbin/winbindd [0x7c6125]
[2006/05/12 03:22:12, 0] lib/fault.c:dump_core(164)
   dumping core in /usr/local/samba3/var/cores/winbindd
[2006/05/12 03:22:13, 0] lib/fault.c:fault_report(41)

> 
>> My vmware machines all died for lack of temporary file space.
>> Ultimately, it required a reboot to get back to normal
>> because a lot of daemons require var space.
>>
>> If it's repeatable, the common process is to re-enable core
>> dumps and run a monitored test.
> 
> Unfortunately not all  problems are easily repeatable, and not all

I was going to say "If a problem doesn't repeat, was it really
a problem?" but I noticed you said easily.
Look, I just bought a 1984 Corvette.  Bright red. I love that car.
Needs some TLC, but I'm going to love fixing it.
I'm having a real hard time being serious here.

> sites have people with the time and expertise to be able to do this
> sort of testing.
> 
>> Barring a compromise, I'll have to investigate and probably
>> recommend hard limits be inherited in the startup files.
>> Otherwise, run the risk of having samba take down the entire
>> machine for the benefit of the developers on a Murphey.
>> The way I've done it for 30 years is limit core dumps for
>> normal day to day, re-enable it during problem determination.
> 
> I could certainly add a "enable core files" knob to smb.conf. I'd prefer
> it to be on by default.

I think that's fantastic.  I  looked at the patch.  Mucho Bueno!