Geert Hendrickx wrote:
On Fri, Jul 04, 2008 at 11:39:33AM +1000, Sarton O'Brien wrote:Though it does seem to depend on the query. When being queried by samba it can fall over every .5 of a second but now I am able to traverse the database using php-ldapadmin which was near impossible before the latest update.Does it still happen when you increase (double) the stacksize ulimit? My slapd on sparc64 crashed (only) when I searched in a non-existing subtree, and doubling the stacksize ulimit solved the problem.
I thought you were onto something but it seems it still happens. Increasing the default 2048 (which isn't the same as the default listed in login.conf) to 4096 allowed it to function but setting the new limit in login.conf and rebooting resulted in slapd dumping on boot still.
It still happens when increasing it further.It does seem to run more stably when manually launched as I've yet to be able to kill it with samba, so it could be the way I'm setting the value on boot ...
Does the 'default' entry in login.conf take effect on processes launched from rc.d? I've not defined any classes in passwd.
I suspect the change is just masking the real problem which is triggered more easily at boot ... but I could easily be wrong.
Starting cron. Fri Jul 4 16:41:15 EST 2008Jul 4 16:41:18 spike /netbsd: pid 313 (slapd), uid 1001: exited on signal 11 (core not dumped, err = 1)
NetBSD/amd64 (spike.internal) (console) login: root Terminal type is vt100. We recommend creating a non-root account and using su(1) for root access. spike# ulimit -a time(cpu-seconds) unlimited file(blocks) unlimited coredump(blocks) unlimited data(kbytes) 524288 stack(kbytes) 8192 lockedmem(kbytes) 166113 memory(kbytes) 498340 nofiles(descriptors) 64 processes 64 sbsize(bytes) unlimited Sarton