On Feb 22, 2016, at 9:21 AM, Ludwig Krispenz 
<lkris...@redhat.com<mailto:lkris...@redhat.com>> wrote:

The crash is an abort because of a failed assertion in  the kerberos code

Thread 1 (Thread 0x7fa7d4c88700 (LWP 3125)):
#0  0x00007fa7e6ace5f7 in raise () from /lib64/libc.so.6
No symbol table info available.
#1  0x00007fa7e6acfce8 in abort () from /lib64/libc.so.6
No symbol table info available.
#2  0x00007fa7e6ac7566 in __assert_fail_base () from /lib64/libc.so.6
No symbol table info available.
#3  0x00007fa7e6ac7612 in __assert_fail () from /lib64/libc.so.6
No symbol table info available.
#4  0x00007fa7e8d71b83 in k5_mutex_lock.part.1 () from /lib64/libkrb5.so.3
No symbol table info available.
#5  0x00007fa7e8d7bda1 in k5_cc_mutex_lock () from /lib64/libkrb5.so.3
No symbol table info available.
#6  0x00007fa7e8d851bf in krb5_mcc_store () from /lib64/libkrb5.so.3
No symbol table info available.
#7  0x00007fa7e8d88070 in krb5_cc_store_cred () from /lib64/libkrb5.so.3
No symbol table info available.
#8  0x00007fa7e8d98be3 in complete () from /lib64/libkrb5.so.3
No symbol table info available.
#9  0x00007fa7e8d99ba1 in krb5_tkt_creds_step () from /lib64/libkrb5.so.3
No symbol table info available.
#10 0x00007fa7e8d9a637 in krb5_tkt_creds_get () from /lib64/libkrb5.so.3
No symbol table info available.
#11 0x00007fa7e8d9a75c in krb5_get_credentials () from /lib64/libkrb5.so.3
No symbol table info available.
#12 0x00007fa7e0f6736a in krb5_gss_init_sec_context_ext () from 
/lib64/libgssapi_krb5.so.2
No symbol table info available.
#13 0x00007fa7e0f67c97 in krb5_gss_init_sec_context () from 
/lib64/libgssapi_krb5.so.2
No symbol table info available.
#14 0x00007fa7e0f516ab in gss_init_sec_context () from 
/lib64/libgssapi_krb5.so.2
No symbol table info available.
#15 0x00007fa7e118ac44 in gssapi_client_mech_step () from 
/usr/lib64/sasl2/libgssapiv2.so
No symbol table info available.
#16 0x00007fa7e72847f5 in sasl_client_step () from /lib64/libsasl2.so.3
No symbol table info available.
#17 0x00007fa7e7284b76 in sasl_client_start () from /lib64/libsasl2.so.3
No symbol table info available.
#18 0x00007fa7e8475e73 in ldap_int_sasl_bind () from /lib64/libldap_r-2.4.so.2
No symbol table info available.
#19 0x00007fa7e8479492 in ldap_sasl_interactive_bind () from 
/lib64/libldap_r-2.4.so.2
No symbol table info available.
#20 0x00007fa7e84796bd in ldap_sasl_interactive_bind_s () from 
/lib64/libldap_r-2.4.so.2

Directory server tries to open a replication connetion usig GSSAPI. I don't 
know which assertion fails in krb, but
- could you try with the replication agreement disabled ?
- Rob, you have been discussing renewals of keytabs, would we have to renew the 
ds.keytab ?


What’s the established procedure to start a 389 instance without any 
replication agreements enabled?  The only thing that seemed close on google 
(http://directory.fedoraproject.org/docs/389ds/howto/howto-fix-and-reset-time-skew.html)
 seems risky and couldn’t be done
trivially in a production environment.

Thanks,


On 02/20/2016 07:57 AM, Timothy Geier wrote:

To update this thread..timeshifting to before the certs expired (Feb.
2) brings up the interesting issue of pki-tomcatd (sometimes) starting
while slapd crashes almost immediately after ipactl start is run..if it
doesn't crash right away, pki-tomcatd will start, but since slapd will
then go down right afterwards, the certs cannot be renewed.  After
returning to real time, slapd is just fine along with everything else
aside from pki-tomcatd.

A core dump is attached.


"This message and any attachments may contain confidential information. If you
have received this  message in error, any use or distribution is prohibited.
Please notify us by reply e-mail if you have mistakenly received this message,
and immediately and permanently delete it and any attachments. Thank you."



--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project





"This message and any attachments may contain confidential information. If you
have received this  message in error, any use or distribution is prohibited. 
Please notify us by reply e-mail if you have mistakenly received this message,
and immediately and permanently delete it and any attachments. Thank you."
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to