On Wed, 20 Jan 2016, Simpson Lachlan wrote:
Is there any coredump available with 389-ds crashing? I've asked you to use
http://www.port389.org/docs/389ds/FAQ/faq.html#debugging-crashes to enable
coredumps for 389-ds in one of previous discussions, was it done?
You seemed to get diverted to winbindd core (which was expected to coredump as
389-ds was not available), but if you see 389-ds disappearing in several hours
without any logging, this means there was a crash and we'd like to see the
coredump of it.
I did perform the "Debugging Crashes" steps when you asked, but there
are still no core dumps in /var/log/dirsrv/slapd-INSTANCENAME.
Well, perhaps it takes longer to get a crash than what you are
You can check also /var/log/audit/audit.log to see if there is a trace of a
may take different ways but one crash type is following:
type=ANOM_ABEND msg=audit(1453212583.746:2337): auid=4294967295
gid=980 ses=4294967295 subj=system_u:system_r:dirsrv_t:s0 pid=26079
comm="ns-slapd" exe="/usr/sbin/ns-slapd" sig=11
There are no instances of ns-slap in the audit.log, there are a dozen
sig=11s, all of them relate to a "memory violation" in httpd_t, and all
references to dirsrv look like this:
type=SERVICE_STOP msg=audit(1453174960.933:209): pid=1 uid=0
auid=4294967295 ses=4294967295 subj=kernel
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=?
What are the memory violation for httpd_t? Can you show exact line from
/ Alexander Bokovoy
Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project