[Freeipa-users] IPA wont start, all services fail

[thierry bordaz]

On 01/20/2016 09:20 AM, Alexander Bokovoy wrote:
> On Tue, 19 Jan 2016, Simpson Lachlan wrote:
>>> -----Original Message-----
>>
>>> From: Alexander Bokovoy [mailto:abokovoy at redhat.com]
>>> Let's start from the beginning:
>>>
>>>  - What distribution you are running?
>>
>> Centos, Linux release 7.2.1511 (Core)
>>
>>
>>>  - What IPA packages are installed?
>>
>> [root at vmts-linuxidm ~]# yum list installed | grep ipa
>> ipa-admintools.x86_64 4.2.0-15.el7.centos.3           @updates
>> ipa-client.x86_64 4.2.0-15.el7.centos.3           @updates
>> ipa-python.x86_64 4.2.0-15.el7.centos.3           @updates
>> ipa-server.x86_64 4.2.0-15.el7.centos.3           @updates
>> ipa-server-dns.x86_64 4.2.0-15.el7.centos.3           @updates
>> ipa-server-trust-ad.x86_64 4.2.0-15.el7.centos.3           @updates
>> libipa_hbac.x86_64 1.13.0-40.el7_2.1               @updates
>> python-iniparse.noarch 0.4-9.el7                       @anaconda
>> python-libipa_hbac.x86_64 1.13.0-40.el7_2.1               @updates
>> sssd-ipa.x86_64 1.13.0-40.el7_2.1               @updates
>>
>>>  - What 389-ds-base package is installed?
>>
>> [root at vmts-linuxidm ~]# yum list installed | grep 389
>> 389-admin.x86_64 1.1.38-1.el7                    @epel
>> 389-adminutil.x86_64 1.1.21-2.el7                    @epel
>> 389-adminutil-devel.x86_64 1.1.21-2.el7                    @epel
>> 389-ds-base.x86_64 1.3.4.0-21.el7_2                @updates
>> 389-ds-base-debuginfo.x86_64 1.3.4.0-21.el7_2                
>> @base-debuginfo
>> 389-ds-base-libs.x86_64 1.3.4.0-21.el7_2                @updates
>>
>>
>>>  - What slapi-nis package is installed?
>>
>> slapi-nis.x86_64 0.54-6.el7_2                    @updates
> Ok, thanks. I've looked at 4.2.0-15.el7.centos.3, it only has debranding
> patch (change from Red Hat branding to a plain one and adding of CentOS
> 'OS'), this shouldn't be a problem.
>
> 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.
>
> You can check also /var/log/audit/audit.log to see if there is a trace
> of a crash. It may take different ways but one crash type is following:
>
> type=ANOM_ABEND msg=audit(1453212583.746:2337): auid=4294967295 uid=983
> gid=980 ses=4294967295 subj=system_u:system_r:dirsrv_t:s0 pid=26079
> comm="ns-slapd" exe="/usr/sbin/ns-slapd" sig=11
>
> it is a crash with SIGSEGV (segmentation fault, a.k.a. null-pointer
> dereference).
>
> Thierry, is there any known issue with 1.3.4.0-21.el7_2 that might cause
> 389-ds crash?
>

No known crash are fixed between 1.3.4.0-21.el7_2 and 1.3.4.0-24.el7_2.
We really need a core/pstack to match any known crash. Does it occur 
frequently, so you may wait for the next occurrence to get a core/pstack.

thanks
thierry