man ulimit
hint: ulimit -c
Doug VanLeuven wrote:
Hi all,
Is there anyway to limit the new core dumping panics?
Can't find anything on it. (If I'd only looked in that )
Was my mistake, but winbindd filled up an entire volume
and froze out every process writing to that drive.
I started it from a shell and my soft limit is
already zero. (ulimit -S -c 0)
FC4 2.6.16-1.2069 smp, gcc 4.0.2-8
samba 3.0.23pre2-SVN-build-15162
Regards, Doug

Hi all,
Is there anyway to limit the new core dumping panics?
Can't find anything on it. (If I'd only looked in that )
Was my mistake, but winbindd filled up an entire volume
and froze out every process writing to that drive.
I started it from a shell and my soft limit is
already zero. (ulimit -S -c 0)

FC4 2.6.16-1.2069 smp, gcc 4.0.2-8
samba 3.0.23pre2-SVN-build-15162

Regards, Doug

Sorry Jeff, been there, done that, if you'd read the whole post.

Jeff Saxton wrote:
man ulimit
hint: ulimit -c

Doug VanLeuven wrote:
>Hi all,
>Is there anyway to limit the new core dumping panics?
>Can't find anything on it. (If I'd only looked in that )
>Was my mistake, but winbindd filled up an entire volume
>and froze out every process writing to that drive.
>I started it from a shell and my soft limit is
>already zero. (ulimit -S -c 0)
^^^^^^^^^^^^^^
>>
>FC4 2.6.16-1.2069 smp, gcc 4.0.2-8
>samba 3.0.23pre2-SVN-build-15162
>>
>Regards, Doug
>>

PGP SIGNED MESSAGE
Hash: SHA1

James,

This was your change right ?

Doug, I'm more interested in why winbindd is seg
faulting in the SAMBA_3_0 tree. Can you give me more
details?

cheers, jerry

Doug VanLeuven wrote:
Sorry Jeff, been there, done that, if you'd read the whole post.

Jeff Saxton wrote:
>man ulimit
>hint: ulimit -c
>>
>Doug VanLeuven wrote:
Hi all,
Is there anyway to limit the new core dumping panics?
Can't find anything on it. (If I'd only looked in that )
Was my mistake, but winbindd filled up an entire volume
and froze out every process writing to that drive.
I started it from a shell and my soft limit is
already zero. (ulimit -S -c 0)
^^^^^^^^^^^^^^

FC4 2.6.16-1.2069 smp, gcc 4.0.2-8
samba 3.0.23pre2-SVN-build-15162

Regards, Doug

>>

- --
Samba http://www.samba.org
Centeris http://www.centeris.com
"What man is a man who does not make the world better?"
PGP SIGNATURE
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

DXjzwA/Eh23lXwDMtA=
=06ek
PGP SIGNATURE

Jerry,
Mostly my fault. I switched over from idmap_ad from xos
to the relatively new option idmap backend = ad several months ago
around svn 12802 or maybe even earlier. Didn't delete the
old ad.so in lib/idmap so I could go back if I wanted.
Then forgot about it.

I've been running svn 12802 without any issue, but last night
I went to svn 15162 and filled up the volume with core dumps
while I was getting some coffee.
Everything is K now that I deleted it.

course, you might be curious why it loaded? I still have
some cores and panic output.

And of course I'm curious why you're overriding my ulimit,
and what I might do to override your override during normal
operations.

Regards, Doug

Gerald (Jerry) Carter wrote:
Doug, I'm more interested in why winbindd is seg
faulting in the SAMBA_3_0 tree. Can you give me more
details?

Doug VanLeuven wrote:
>Sorry Jeff, been there, done that, if you'd read the whole post.
>>
>>
>Jeff Saxton wrote:
man ulimit
hint: ulimit -c

Doug VanLeuven wrote:
Hi all,
Is there anyway to limit the new core dumping panics?
Can't find anything on it. (If I'd only looked in that )
Was my mistake, but winbindd filled up an entire volume
and froze out every process writing to that drive.
I started it from a shell and my soft limit is
already zero. (ulimit -S -c 0)
>^^^^^^^^^^^^^^
FC4 2.6.16-1.2069 smp, gcc 4.0.2-8
samba 3.0.23pre2-SVN-build-15162

Regards, Doug

- --
Samba http://www.samba.org
Centeris http://www.centeris.com
"What man is a man who does not make the world better?"
PGP SIGNATURE
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

DXjzwA/Eh23lXwDMtA=
=06ek
PGP SIGNATURE

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.

Doug, I'm more interested in why winbindd is seg
faulting in the SAMBA_3_0 tree. Can you give me more
details?

Agreed. Please let's get a backtrace at least:

gdb `which winbindd` /path/to/core/file
(gdb) where
(quit)

Doug VanLeuven wrote:
Sorry Jeff, been there, done that, if you'd read the whole post.
--
Jeff Saxton wrote:
>man ulimit
>hint: ulimit -c

This probably won't work because in fault.c we explicitly set the core
size to 16MiM (IIRC).

>>
>Doug VanLeuven wrote:
Hi all,
Is there anyway to limit the new core dumping panics?
Can't find anything on it. (If I'd only looked in that )
Was my mistake, but winbindd filled up an entire volume
and froze out every process writing to that drive.

You should only get 1 core file per daemon unless you have some
system-specific core file naming facility enabled. If winbind is dumping
core often it should always be in LGBASE/cores/winbindd/core.

I started it from a shell and my soft limit is
already zero. (ulimit -S -c 0)
^^^^^^^^^^^^^^

FC4 2.6.16-1.2069 smp, gcc 4.0.2-8
samba 3.0.23pre2-SVN-build-15162

Regards, Doug

>>
>

James Peach wrote:
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?
winbindd cranked out hundreds of core dumps in less time than
it took to get a cup of coffee.
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.

Barring a compromise, I'll have to investigate and probably
recommend hard limits be inherited in the startup files.
, 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 long for the days long, long ago and far, far away
where there was a presumption of intelligence. Maybe it's
better this way and I need to just fade away. I don't know.

>Doug, I'm more interested in why winbindd is seg
>faulting in the SAMBA_3_0 tree. Can you give me more
>details?

Agreed. Please let's get a backtrace at least:

gdb `which winbindd` /path/to/core/file
(gdb) where
(quit)

It was an old xos idmap_ad ad.so in samba/lib which I deleted.
Still, why did samba load it instead of the internal ad module?
Still interested? If so, I have to find a copy on
an old DVD backup disc.

>Doug VanLeuven wrote:
Sorry Jeff, been there, done that, if you'd read the whole post.

Jeff Saxton wrote:
man ulimit
hint: ulimit -c

This probably won't work because in fault.c we explicitly set the core
size to 16MiM (IIRC).

Doug VanLeuven wrote:
Hi all,
Is there anyway to limit the new core dumping panics?
Can't find anything on it. (If I'd only looked in that )
Was my mistake, but winbindd filled up an entire volume
and froze out every process writing to that drive.

You should only get 1 core file per daemon unless you have some
system-specific core file naming facility enabled. If winbind is dumping
core often it should always be in LGBASE/cores/winbindd/core.

I started it from a shell and my soft limit is
already zero. (ulimit -S -c 0)
^^^^^^^^^^^^^^
FC4 2.6.16-1.2069 smp, gcc 4.0.2-8
samba 3.0.23pre2-SVN-build-15162

Regards, Doug

>>

Mon, 15 May 2006 09:40 pm, Doug VanLeuven wrote:
James Peach wrote:
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?

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

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
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.
, 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.

James Peach wrote:
Mon, 15 May 2006 09:40 pm, Doug VanLeuven wrote:
>James Peach wrote:
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?

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@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 ERRR: Signal 11 in pid 19692 (3.0.23pre2-SVN-build-15162)
Please read the Trouble-Shooting section of the Samba3-HWT
[2006/05/12 03:22:12, 0] lib/fault.c:fault_report(44)

From:
[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 / [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 /
[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.
>, 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!

Tue, 16 May 2006 08:27 am, James Peach wrote:
[snip]
I could certainly add a "enable core files" knob to smb.conf. I'd prefer
it to be on by default.
something like this

Gerald (Jerry) Carter wrote:
PGP SIGNED MESSAGE
Hash: SHA1

James,

This was your change right ?

Doug, I'm more interested in why winbindd is seg
faulting in the SAMBA_3_0 tree. Can you give me more
details?

Jerry, I was wrong before. Please read.
Sometime in the last 8 months, idmap_ad doesn't
build by default anymore. My memory being what it is,
I wouldn't swear it ever did, but I thought it used to.

samba Version 3.0.23pre2-SVN-build-15864
FC4 - Linux 2.6.16-1.2096_FC4smp
gcc-4.0.2-8.fc4

Configure.log
configure:48191: checking how to build idmap_ldap
configure:48219: result: static
configure:48228: checking how to build idmap_tdb
configure:48256: result: static
configure:48265: checking how to build idmap_rid
configure:48297: result: not
configure:48302: checking how to build idmap_ad
configure:48330: result: not

if I define it static, with ""
I get a build error:

sam/idmap.o(.text+0x2d7): In function `idmap_init':
idmap.c: undefined reference to `idmap_ad_init'
collect2: ld returned 1 exit status
make: [bin/net] Error 1
make: Waiting for unfinished jobs
pam_smbpass/support.c: In function '_smb_verify_password':
pam_smbpass/support.c:401: warning: pointer targets in passing argument 2 of 'si
d_to_uid' differ in signedness
Linking bin/testparm
sam/idmap.o(.text+0x2d7): In function `idmap_init':
idmap.c: undefined reference to `idmap_ad_init'
collect2: ld returned 1 exit status
make: [bin/winbindd] Error 1

if I define it shared, with ""
I get a clean build, but then I start core dumping again.

May 31 01:19:14 gate winbindd[5355]: [2006/05/31 01:19:14, 0] lib/fault.c:fault_report(41)
May 31 01:19:14 gate winbindd[5355]:

May 31 01:19:14 gate winbindd[5355]: [2006/05/31 01:19:14, 0] lib/fault.c:fault_report(42)
May 31 01:19:14 gate winbindd[5355]: INTERNAL ERRR: Signal 6 in pid 5355
(3.0.23pre2-SVN-build-15864)
May 31 01:19:14 gate winbindd[5355]: Please read the Trouble-Shooting section of the Samba3-HWT
May 31 01:19:14 gate winbindd[5355]: [2006/05/31 01:19:14, 0] lib/fault.c:fault_report(44)
May 31 01:19:14 gate winbindd[5355]:
May 31 01:19:14 gate winbindd[5355]: From:
May 31 01:19:14 gate winbindd[5355]: [2006/05/31 01:19:14, 0] lib/fault.c:fault_report(45)
May 31 01:19:14 gate winbindd[5355]:

May 31 01:19:14 gate winbindd[5355]: [2006/05/31 01:19:14, 0] lib/util.c:smb_panic(1592)
May 31 01:19:14 gate winbindd[5355]: PANIC (pid 5355): internal error
May 31 01:19:14 gate winbindd[5355]: [2006/05/31 01:19:14, 0] lib/util.c:log_stack_trace(1699)
May 31 01:19:14 gate winbindd[5355]: BACKTRACE: 27 stack frames:
May 31 01:19:14 gate winbindd[5355]: #0 /usr/local/samba3/sbin/winbindd(log_stack_trace+0x26)
[0xdd5496]
May 31 01:19:14 gate winbindd[5355]: #1 /usr/local/samba3/sbin/winbindd(smb_panic+0x5e)
[0xdd535e]
May 31 01:19:14 gate winbindd[5355]: #2 /usr/local/samba3/sbin/winbindd [0xdc3cac]
May 31 01:19:14 gate winbindd[5355]: #3 /usr/local/samba3/sbin/winbindd [0xdc3cba]
May 31 01:19:14 gate winbindd[5355]: #4 [0x2cf420]
May 31 01:19:14 gate winbindd[5355]: #5 /lib/libc.so.6(abort+0xf8) [0x3b2678]
May 31 01:19:14 gate winbindd[5355]: #6 /usr/local/samba3/sbin/winbindd [0xdda5cf]
May 31 01:19:14 gate winbindd[5355]: #7 /usr/local/samba3/sbin/winbindd(talloc_free+0x2a)
[0xddacc0]
May 31 01:19:14 gate winbindd[5355]: #8
/usr/local/samba3/sbin/winbindd() [0xea8726]
May 31 01:19:14 gate winbindd[5355]: #9 /usr/local/samba3/sbin/winbindd [0xd7fb76]
May 31 01:19:14 gate winbindd[5355]: #10 /usr/local/samba3/sbin/winbindd [0xd823ae]
May 31 01:19:14 gate winbindd[5355]: #11 /usr/local/samba3/sbin/winbindd [0xd6d43f]
May 31 01:19:14 gate winbindd[5355]: #12 /usr/local/samba3/sbin/winbindd [0xd6d8e6]
May 31 01:19:14 gate winbindd[5355]: #13 /usr/local/samba3/sbin/winbindd [0xd704ba]
May 31 01:19:14 gate winbindd[5355]: #14
/usr/local/samba3/sbin/winbindd() [0xd78336]
May 31 01:19:14 gate winbindd[5355]: #15 /usr/local/samba3/sbin/winbindd [0xd841c9]
May 31 01:19:14 gate winbindd[5355]: #16 /usr/local/samba3/sbin/winbindd [0xd854c4]
May 31 01:19:14 gate winbindd[5355]: #17 /usr/local/samba3/sbin/winbindd [0xd83e2c]
May 31 01:19:14 gate winbindd[5355]: #18 /usr/local/samba3/sbin/winbindd(async_request+0x14e)
[0xd83a96]
May 31 01:19:14 gate winbindd[5355]: #19
/usr/local/samba3/sbin/winbindd(init_child_connection+0x219) [0xd6a439]
May 31 01:19:14 gate winbindd[5355]: #20
/usr/local/samba3/sbin/winbindd(async_domain_request+0xf3) [0xd83f76]
May 31 01:19:14 gate winbindd[5355]: #21 /usr/local/samba3/sbin/winbindd [0xd69ec3]
May 31 01:19:14 gate winbindd[5355]: #22
/usr/local/samba3/sbin/winbindd(rescan_trusted_domains+0x44) [0xd6a210]
May 31 01:19:14 gate winbindd[5355]: #23 /usr/local/samba3/sbin/winbindd [0xd63be6]
May 31 01:19:14 gate winbindd[5355]: #24 /usr/local/samba3/sbin/winbindd(main+0x654) [0xd6474b]
May 31 01:19:14 gate winbindd[5355]: #25 /lib/libc.so.6(__libc_start_main+0xdf) [0x39dd7f]
May 31 01:19:14 gate winbindd[5355]: #26 /usr/local/samba3/sbin/winbindd [0xd629ad]
May 31 01:19:14 gate winbindd[5355]: [2006/05/31 01:19:14, 0] lib/fault.c:dump_core(173)
May 31 01:19:14 gate winbindd[5355]: dumping core in /
May 31 01:19:14 gate winbindd[5355]:

And immediately starts spawning more dumps:

May 31 01:19:14 gate winbindd[5441]: [2006/05/31 01:19:14, 0] lib/fault.c:fault_report(41)
May 31 01:19:14 gate winbindd[5441]:

May 31 01:19:14 gate winbindd[5441]: [2006/05/31 01:19:14, 0] lib/fault.c:fault_report(42)
May 31 01:19:14 gate winbindd[5441]: INTERNAL ERRR: Signal 6 in pid 5441
(3.0.23pre2-SVN-build-15864)
May 31 01:19:14 gate winbindd[5441]: Please read the Trouble-Shooting section of the Samba3-HWT
May 31 01:19:14 gate winbindd[5441]: [2006/05/31 01:19:14, 0] lib/fault.c:fault_report(44)
May 31 01:19:14 gate winbindd[5441]:
May 31 01:19:14 gate winbindd[5441]: From:
May 31 01:19:14 gate winbindd[5441]: [2006/05/31 01:19:14, 0] lib/fault.c:fault_report(45)
May 31 01:19:14 gate winbindd[5441]:

May 31 01:19:14 gate winbindd[5441]: [2006/05/31 01:19:14, 0] lib/util.c:smb_panic(1592)
May 31 01:19:14 gate winbindd[5441]: PANIC (pid 5441): internal error
May 31 01:19:14 gate winbindd[5441]: [2006/05/31 01:19:14, 0] lib/util.c:log_stack_trace(1699)
May 31 01:19:15 gate winbindd[5441]: BACKTRACE: 23 stack frames:
May 31 01:19:15 gate winbindd[5441]: #0 /usr/local/samba3/sbin/winbindd(log_stack_trace+0x26)
[0xdd5496]
May 31 01:19:15 gate winbindd[5441]: #1 /usr/local/samba3/sbin/winbindd(smb_panic+0x5e)
[0xdd535e]
May 31 01:19:15 gate winbindd[5441]: #2 /usr/local/samba3/sbin/winbindd [0xdc3cac]
May 31 01:19:15 gate winbindd[5441]: #3 /usr/local/samba3/sbin/winbindd [0xdc3cba]
May 31 01:19:15 gate winbindd[5441]: #4 [0x2cf420]
May 31 01:19:15 gate winbindd[5441]: #5 /lib/libc.so.6(abort+0xf8) [0x3b2678]
May 31 01:19:15 gate winbindd[5441]: #6 /usr/local/samba3/sbin/winbindd [0xdda5cf]
May 31 01:19:15 gate winbindd[5441]: #7 /usr/local/samba3/sbin/winbindd(talloc_free+0x2a)
[0xddacc0]
May 31 01:19:15 gate winbindd[5441]: #8
/usr/local/samba3/sbin/winbindd() [0xea8726]
May 31 01:19:15 gate winbindd[5441]: #9 /usr/local/samba3/sbin/winbindd [0xd7fb76]
May 31 01:19:15 gate winbindd[5441]: #10 /usr/local/samba3/sbin/winbindd [0xd823ae]
May 31 01:19:15 gate winbindd[5441]: #11 /usr/local/samba3/sbin/winbindd [0xd6d43f]
May 31 01:19:15 gate winbindd[5441]: #12 /usr/local/samba3/sbin/winbindd [0xd6d8e6]
May 31 01:19:15 gate winbindd[5441]: #13 /usr/local/samba3/sbin/winbindd [0xd70835]
May 31 01:19:15 gate winbindd[5441]: #14 /usr/local/samba3/sbin/winbindd [0xd84908]
May 31 01:19:15 gate winbindd[5441]: #15 /usr/local/samba3/sbin/winbindd(run_events+0x12b)
[0xdebbe5]
May 31 01:19:15 gate winbindd[5441]: #16 /usr/local/samba3/sbin/winbindd [0xd8525d]
May 31 01:19:15 gate winbindd[5441]: #17 /usr/local/samba3/sbin/winbindd [0xd83e2c]
May 31 01:19:15 gate winbindd[5441]: #18
/usr/local/samba3/sbin/winbindd(winbind_child_died+0xd2) [0xd843d9]
May 31 01:19:15 gate winbindd[5441]: #19 /usr/local/samba3/sbin/winbindd [0xd640d7]
May 31 01:19:15 gate winbindd[5441]: #20 /usr/local/samba3/sbin/winbindd(main+0x654) [0xd6474b]
May 31 01:19:15 gate winbindd[5441]: #21 /lib/libc.so.6(__libc_start_main+0xdf) [0x39dd7f]
May 31 01:19:15 gate winbindd[5441]: #22 /usr/local/samba3/sbin/winbindd [0xd629ad]
May 31 01:19:15 gate winbindd[5441]: [2006/05/31 01:19:15, 0] lib/fault.c:dump_core(173)
May 31 01:19:15 gate winbindd[5441]: dumping core in /

Sorry for the delay. I've been distracted and only just realized.
I saved these two core dumps.

Help. My entire system (and the governmental ones I built and left behind) are dependent
on the SFU schema extension.

My systems still work for users that own the directory without the ad plugin.
group writable issues have surfaced.

Regards, Doug

PGP SIGNED MESSAGE
Hash: SHA1

Doug VanLeuven wrote:

Jerry, I was wrong before. Please read.
Sometime in the last 8 months, idmap_ad doesn't
build by default anymore. My memory being what it is,
I wouldn't swear it ever did, but I thought it used to.

I don't believe it was ever built by default.
It was included in some packages by default, but
never a basic ./configure && make && make install.

if I define it static, with ""
I get a build error:

It should be built as a shared module

if I define it shared, with ""
I get a clean build, but then I start core dumping again.

May 31 01:19:14 gate winbindd[5355]: [2006/05/31 01:19:14, 0]
lib/fault.c:fault_report(41)
May 31 01:19:14 gate winbindd[5355]:

May 31 01:19:14 gate winbindd[5355]: [2006/05/31 01:19:14, 0]
lib/fault.c:fault_report(42)
May 31 01:19:14 gate winbindd[5355]: INTERNAL ERRR: Signal 6 in pid
5355 (3.0.23pre2-SVN-build-15864)

Looks like an abort in the talloc code called by the sfu idmap
support. I agree this would be guenther's code.

Can you add some comments to the bug report Bob mentioned?

cheers, jerry

Samba http://www.samba.org
Centeris http://www.centeris.com
"What man is a man who does not make the world better?"
PGP SIGNATURE
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

3cA7CNLh6fprAxubINsXHlo=
=4ajo
PGP SIGNATURE