Currently I'm trying to reproduce this in the test environment, but it
will take some time. Are you getting the same error using regular user
account (with sufficient rights to move an object) and directory
manager?
On Wed, 2012-11-14 at 16:56 +0100, Ludwig Krispenz wrote:
On 11/14/2012 04:39
Hello,
First of all I'd say that most likely this segfault is a result of
badly designed application and/or bad coding. The segfault occurs while
this application tries to move an entry to non-existing LDAP container.
Unfortunately I don't have access to the source code of this app. The
segfault
Edward Z. Yang wrote:
Excerpts from Rich Megginson's message of Fri Oct 08 18:59:52 -0400 2010:
Try running with the SHELL (1024) debug error log level. This should
give more information about the principal, keytab, etc. that directory
server is using.
More logs:
Done.
https://bugzilla.redhat.com/show_bug.cgi?id=642046
Cheers,
Edward
--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
Excerpts from Rich Megginson's message of Fri Oct 08 18:59:52 -0400 2010:
Try running with the SHELL (1024) debug error log level. This should
give more information about the principal, keytab, etc. that directory
server is using.
More logs:
[09/Oct/2010:04:29:48 -0400] - Listening on
Edward Z. Yang wrote:
After manually attaching GDB, we caught a segfault on one of the dirsrvs. The
server's name is old-faithful. Here's the backtrace (with one set of
debugging
info missing; I can grab that and reload the core dump if you want me to.)
File a bug, or do you think it's an
Ok, I backtraced the coredump, the problem was in /usr/lib64/libssl3.so.
I updated from nss-3.12.6-1.el5_4.x86_64 to nss-3.12.7-2.el5.x86_64
and now all seems to work fine!
Thank you.
Regards,
Dael Maselli.
On 08/09/10 15.16, Rich Megginson wrote:
Dael Maselli wrote:
It worked!
I
Dael Maselli wrote:
Ok, I backtraced the coredump, the problem was in /usr/lib64/libssl3.so.
I updated from nss-3.12.6-1.el5_4.x86_64 to
nss-3.12.7-2.el5.x86_64 and now all seems to work fine!
Thanks, good to know.
Thank you.
Regards,
Dael Maselli.
On 08/09/10 15.16, Rich
Excerpts from Rich Megginson's message of Mon Sep 20 11:37:32 -0400 2010:
What platform? What version of 389-ds-base? Can you install the
389-ds-base-debuginfo package?
Platform: Fedora 11 (yes, I know it's EOL'd, we're migrating this weekend)
[r...@pancake-bunny etc]# ns-slapd --version
Edward Z. Yang wrote:
We've had ns-slapd segfault on us recently twice; we don't have
a core dump (since the daemon script turns off core dumps, but
hopefully we'll have one next time it happens) and I was wondering
if anyone had seen this before:
ns-slapd[2725]: segfault at 10a310af ip
On Tuesday 07 September 2010 17:25:05 Dael Maselli wrote:
.. I can simulate a crash with kill -QUIT.
maybe the sleep command doesn't trap this signal, thus generating a core file
like in # man 7 signal.
But if I kill -QUIT ns-slapd no file is created.
slapd will trap the QUIT and treat it as
It worked!
I wrote fs.suid_dumpable=1 in /etc/sysctl.conf, `sysctl -p` and
restarted dirsrv. Now it dumps.
Thank you!
I will report here the backtrace when it occurs.
Regards,
Dael Maselli.
On 07/09/10 19.44, Ulf Weltman wrote:
On 9/7/2010 8:25 AM, Dael Maselli wrote:
Hi Rich,
Hi Rich,
On 07/09/10 16.56, Rich Megginson wrote:
Do you see seg fault messages in /var/log/messages?
Sure: ns-slapd[13737]: segfault at 00bc rip 003abb420375
rsp 580d85d0 error 4
The directory server dumps core in the log file directory, which by
default is
...@lists.fedoraproject.org] On Behalf Of Rich Megginson
Sent: Tuesday, September 07, 2010 10:56 AM
To: General discussion list for the 389 Directory server project.
Subject: Re: [389-users] Segfault Core Dumps
Dael Maselli wrote:
Hi,
I'm experiencing a lot of segmentation fault on my installations, I
have
Hi,
I'm experiencing a lot of segmentation fault on my installations, I have
the latest release on EPEL on SL 5.4 (389-Directory/1.2.5 B2010.012.2034).
I'm trying to get core dumps but without success. Is there a specific
configuration that prevents/allows 389-ds to core dump?
The default on
15 matches
Mail list logo