On 09/29/2013 06:11 PM, Michael R. Gettes wrote:
we are able to get a backtrace via gdb
(gdb) bt
#0 0x7fc637cd5bd8 in attrlist_find () from /usr/lib64/dirsrv/libslapd.so.0
#1 0x7fc637ce70b2 in slapi_entry_attr_find ()
from /usr/lib64/dirsrv/libslapd.so.0
#2 0x7fc62c7f34e4 in ?
we are able to get a backtrace via gdb
(gdb) bt
#0 0x7fc637cd5bd8 in attrlist_find () from /usr/lib64/dirsrv/libslapd.so.0
#1 0x7fc637ce70b2 in slapi_entry_attr_find ()
from /usr/lib64/dirsrv/libslapd.so.0
#2 0x7fc62c7f34e4 in ?? ()
from /usr/lib64/dirsrv/plugins/libretrocl-pl
I've turned heavy trace output but nothing seems all that unusual when it dies.
suggestions for errorlog-level to be able to narrow in on also appreciated.
we can't seem to find a core file - not sure what needs to be tickled in RHEL6
to get core files generated.
/mrg
On Sep 29, 2013, at 19:54
oh, right. it shows nothing other than the usual start-up messages. ns-slapd
seems to die fairly quickly after start-up
/mrg
On Sep 29, 2013, at 19:54, Paul Whitney wrote:
> What about the error log? (/var/log/dirsrv/slapd-/errors)
>
>
> Paul M. Whitney
> email: paul.whit...@mac.com
>
>>
What about the error log? (/var/log/dirsrv/slapd-/errors)
Paul M. Whitney
email: paul.whit...@mac.com
> On Sep 29, 2013, at 19:27, "Michael R. Gettes" wrote:
>
> We try to start the service and it dies very quickly. See trace below.
>
> This is one of our 2 masters running in MMR. Both mast
We try to start the service and it dies very quickly. See trace below.
This is one of our 2 masters running in MMR. Both masters feed the same 3
replicas.
we even rebooted the system to no effect.
suggestions appreciated. we've been running on this version of 389 and OS for
about 3 weeks no
