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
[EMAIL PROTECTED] 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!
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
