Re: [Freeipa-users] ns-slapd hang/segfault
On Wed, 2011-12-21 at 17:39 -0500, Dan Scott wrote: This is possible... oops. I tried a few times to add another replica (fileserver3) which failed as I mentioned above. The replication process got most of the way through and showed up on one of the servers, but not the other, so I removed the replica. It's possible that I force removed fileserver2 by mistake. In this case the only way out is to reinstall fileserver2. Can you look into cn=config and see if you have references toi fileserver2 ? Maybe it is just a bug in displaying actually active replicas. I'm using 'jxplore' LDAP browser (my command line LDAP skills aren't very good, I can't seem to get the kerberos authentication working properly. In any case, I'm having trouble authenticating because of the problems mentioned above) and did an unauthenticated search for cn=config on fileserver1, no results. cn=config is a separate tree within DS it is not a subtree of the data partition, you need to use that as the basedn in jxplore. In cn=ipa,cn=etc there are: cn=masters which contains an entry for fileserver1 and cn=replicas which is empty. This strongly indicate you force deleted fileserver2, which is very unfortunate. Be careful with --force we imposed such a flag for a very good reason. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ns-slapd hang/segfault
On Thu, Dec 22, 2011 at 10:12, Simo Sorce s...@redhat.com wrote: On Wed, 2011-12-21 at 17:39 -0500, Dan Scott wrote: This is possible... oops. I tried a few times to add another replica (fileserver3) which failed as I mentioned above. The replication process got most of the way through and showed up on one of the servers, but not the other, so I removed the replica. It's possible that I force removed fileserver2 by mistake. In this case the only way out is to reinstall fileserver2. Which would be fine, if I were confident of being able to create a new replica. However, my attempts to create new replicas are failing miserably as explained previously. I'm extremely reluctant to wipe fileserver2 unless I can get another replica of fileserver1 up and running first. If I can get another replica up and running I would be fine. However, the slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't contact LDAP server) error is causing problems during replication. When a replica is initialised, I guess that it replicates only from the master server? So I need to figure out the replication problem first, then I can re-install fileserver2 Can you look into cn=config and see if you have references toi fileserver2 ? Maybe it is just a bug in displaying actually active replicas. I'm using 'jxplore' LDAP browser (my command line LDAP skills aren't very good, I can't seem to get the kerberos authentication working properly. In any case, I'm having trouble authenticating because of the problems mentioned above) and did an unauthenticated search for cn=config on fileserver1, no results. cn=config is a separate tree within DS it is not a subtree of the data partition, you need to use that as the basedn in jxplore. OK, thanks. cn=config only contains a SNMP entry, no references to the other server. Thanks, Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ns-slapd hang/segfault
On Thu, Dec 22, 2011 at 12:10, Rich Megginson rmegg...@redhat.com wrote: On 12/22/2011 08:42 AM, Dan Scott wrote: On Thu, Dec 22, 2011 at 10:12, Simo Sorces...@redhat.com wrote: On Wed, 2011-12-21 at 17:39 -0500, Dan Scott wrote: This is possible... oops. I tried a few times to add another replica (fileserver3) which failed as I mentioned above. The replication process got most of the way through and showed up on one of the servers, but not the other, so I removed the replica. It's possible that I force removed fileserver2 by mistake. In this case the only way out is to reinstall fileserver2. Which would be fine, if I were confident of being able to create a new replica. However, my attempts to create new replicas are failing miserably as explained previously. I'm extremely reluctant to wipe fileserver2 unless I can get another replica of fileserver1 up and running first. If I can get another replica up and running I would be fine. However, the slapi_ldap_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -1 (Can't contact LDAP server) error is causing problems during replication. When a replica is initialised, I guess that it replicates only from the master server? So I need to figure out the replication problem first, then I can re-install fileserver2 Can you look into cn=config and see if you have references toi fileserver2 ? Maybe it is just a bug in displaying actually active replicas. I'm using 'jxplore' LDAP browser (my command line LDAP skills aren't very good, I can't seem to get the kerberos authentication working properly. In any case, I'm having trouble authenticating because of the problems mentioned above) and did an unauthenticated search for cn=config on fileserver1, no results. cn=config is a separate tree within DS it is not a subtree of the data partition, you need to use that as the basedn in jxplore. OK, thanks. cn=config only contains a SNMP entry, no references to the other server. That's the only entry that you can view with anonymous credentials. You'll need to use an authenticated admin user (e.g. cn=Directory Manager) to see the rest of the tree. Ahh, OK, thanks. I can see a lot more now. There's no replication agreement with fileserver2 showing up. I managed to 'mostly' replicate with a new Fedora 16 IPA fileserver3 (using the updates-testing release of FreeIPA freeipa-server-2.1.4-2.fc16.x86_64). But it failed with: 2011-12-22 11:37:49,053 DEBUG done configuring dirsrv. 2011-12-22 11:37:52,058 DEBUG args=/bin/systemctl restart dirsrv.target 2011-12-22 11:37:52,059 DEBUG stdout= 2011-12-22 11:37:52,059 DEBUG stderr= 2011-12-22 11:37:52,183 DEBUG args=/bin/systemctl restart krb5kdc.service 2011-12-22 11:37:52,184 DEBUG stdout= 2011-12-22 11:37:52,184 DEBUG stderr=Job failed. See system logs and 'systemctl status' for details. 2011-12-22 11:37:52,188 DEBUG Command '/bin/systemctl restart krb5kdc.service' returned non-zero exit status 1 File /usr/sbin/ipa-replica-install, line 484, in module main() File /usr/sbin/ipa-replica-install, line 460, in main ipaservices.knownservices.krb5kdc.restart() File /usr/lib/python2.7/site-packages/ipapython/platform/systemd.py, line 85, in restart ipautil.run([/bin/systemctl, restart, self.service_instance(instance_name)], capture_output=capture_output) File /usr/lib/python2.7/site-packages/ipapython/ipautil.py, line 273, in run raise CalledProcessError(p.returncode, args) I can send the full log file directly to someone off list if this would help. The data seems to be replicating mostly, so I'm less concerned than I was previously. However there still seem to be a few problems. Is it dangerous to update my fileserver1 to freeipa-server-2.1.4-2.fc16.x86_64. I'm a little concerned about the slapd-PKI-IPA replication now, since I haven't been able to replicate that properly. I'm going to try and replicate the PKI directory now, with the 2.1.4 version into fileserver4. Thanks, Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ns-slapd hang/segfault
On Thu, 22 Dec 2011, Dan Scott wrote: Ahh, OK, thanks. I can see a lot more now. There's no replication agreement with fileserver2 showing up. I managed to 'mostly' replicate with a new Fedora 16 IPA fileserver3 (using the updates-testing release of FreeIPA freeipa-server-2.1.4-2.fc16.x86_64). But it failed with: 2011-12-22 11:37:49,053 DEBUG done configuring dirsrv. 2011-12-22 11:37:52,058 DEBUG args=/bin/systemctl restart dirsrv.target 2011-12-22 11:37:52,059 DEBUG stdout= 2011-12-22 11:37:52,059 DEBUG stderr= 2011-12-22 11:37:52,183 DEBUG args=/bin/systemctl restart krb5kdc.service 2011-12-22 11:37:52,184 DEBUG stdout= 2011-12-22 11:37:52,184 DEBUG stderr=Job failed. See system logs and 'systemctl status' for details. 2011-12-22 11:37:52,188 DEBUG Command '/bin/systemctl restart krb5kdc.service' returned non-zero exit status 1 File /usr/sbin/ipa-replica-install, line 484, in module main() File /usr/sbin/ipa-replica-install, line 460, in main ipaservices.knownservices.krb5kdc.restart() File /usr/lib/python2.7/site-packages/ipapython/platform/systemd.py, line 85, in restart ipautil.run([/bin/systemctl, restart, self.service_instance(instance_name)], capture_output=capture_output) File /usr/lib/python2.7/site-packages/ipapython/ipautil.py, line 273, in run raise CalledProcessError(p.returncode, args) I can send the full log file directly to someone off list if this would help. Please send the log to me. Also please include /etc/sysconfig/krb5kdc, output of 'stat /etc/sysconfig/krb5kdc', and output of 'ls -l /etc/systemd/system/' The data seems to be replicating mostly, so I'm less concerned than I was previously. However there still seem to be a few problems. Is it dangerous to update my fileserver1 to freeipa-server-2.1.4-2.fc16.x86_64. I'm a little concerned about the slapd-PKI-IPA replication now, since I haven't been able to replicate that properly. Did you install Fedora 16 from scratch or was it upgrade from Fedora 15? The latter might explain some of these issues. -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ns-slapd hang/segfault
On Wed, 2011-12-21 at 15:33 -0500, Dan Scott wrote: On Wed, Dec 21, 2011 at 14:10, Dan Scott danieljamessc...@gmail.com wrote: On Mon, Dec 19, 2011 at 15:26, Dan Scott danieljamessc...@gmail.com wrote: On Mon, Dec 19, 2011 at 14:14, Simo Sorce s...@redhat.com wrote: On Mon, 2011-12-19 at 11:01 -0500, Dan Scott wrote: On Thu, Dec 15, 2011 at 11:51, Rich Megginson rmegg...@redhat.com wrote: On 12/15/2011 09:48 AM, Dan Scott wrote: Hi, On Thu, Dec 15, 2011 at 10:58, Rich Megginsonrmegg...@redhat.com wrote: On 12/15/2011 08:41 AM, Dan Scott wrote: Hi, On my Fedora 15 FreeIPA server, I'm having some problems with stability. The server appears to 'hang' and stops responding to LDAP lookups. When I restart the dirsrv service, I get: Dec 15 09:40:02 ohm kernel: [254566.011404] ns-slapd[28910]: segfault at 17d ip 7f00dbc0208c sp 7fff929b7848 error 4 in libc-2.14.so[7f00dbb87000+18f000] and the /var/log/dirsrv/slapd-EXAMPLE-COM/errors contains [15/Dec/2011:09:47:35 -0500] set_krb5_creds - Could not get initial credentials for principal [ldap/example@example.com] in keytab [WRFILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) [15/Dec/2011:09:47:35 -0500] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_496' not found)) This is happening very frequently, I'm having to restart the dirsrv process once an hour, otherwise people start complaining. I experienced similar problems with FreeIPA 1, when I was using Fedora 14 and earlier, and had to regularly (also once per hour) restart the dirsrv process. Could this be related? I also noticed this: https://bugzilla.redhat.com/show_bug.cgi?id=730387 There are updates in 'updates-testing' which I believe fix the above issue, but I'm reluctant to install from a testing repo on my production server, can anyone report any feedback on this? The above bug does not cause a segfault. What version of 389-ds-base are you using? [root@ohm ~]# rpm -qa|grep 389 389-ds-base-libs-1.2.10-0.4.a4.fc15.x86_64 389-ds-base-1.2.10-0.4.a4.fc15.x86_64 [root@ohm ~]# a4 is alpha software. Not sure how that got released to stable. Please enable the collection of core dumps so we can debug the crash - see http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes OK. I think there is a small typo in the instructions: 'debuginfo-install 389-ds-base-debuginfo' should be 'debuginfo-install 389-ds-base' Thanks. Fixed. I managed to get the core dump (attached - so I only sent this message to you, not the list as well), but it doesn't contain much information. This is https://bugzilla.redhat.com/show_bug.cgi?id=755725 Will be fixed in 1.2.10.a6 But this still doesn't explain your kerberos errors. An additional problem is also occurring. I've been finding that the: /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif file is empty and prevents dirsrv from starting. I can restore it from dse.ldif.bak or dse.ldif.startOK, but this may be related to the LDAP problems that I'm having? This is an upgrade time problem, it should be fixed in latest packages. Did you recently upgrade freeipa packages if so from what version to what version ? The 0 length file doesn't appear related to upgrades. Possibly it only happens on the first service restart after an upgrade? It's happened at least 4 times since the last freeipa package upgrade on 4th November, so it seems to be happening too regularly to be the result of an upgrade. [root@curie ~]# grep freeipa /var/log/yum.log Sep 06 16:56:51 Installed: freeipa-python-2.0.1-2.fc15.x86_64 Sep 06 17:00:13 Installed: freeipa-client-2.0.1-2.fc15.x86_64 Sep 06 17:00:14 Installed: freeipa-admintools-2.0.1-2.fc15.x86_64 Sep 06 17:01:52 Installed: freeipa-server-selinux-2.0.1-2.fc15.x86_64 Sep 06 17:01:56 Installed: freeipa-server-2.0.1-2.fc15.x86_64 Sep 08 11:23:35 Updated: freeipa-python-2.1.0-1.fc15.x86_64 Sep 08 11:23:41 Updated: freeipa-client-2.1.0-1.fc15.x86_64 Sep 08 11:23:41 Updated: freeipa-admintools-2.1.0-1.fc15.x86_64 Sep 08 11:25:00 Updated: freeipa-server-selinux-2.1.0-1.fc15.x86_64 Sep 08 11:26:06 Updated: freeipa-server-2.1.0-1.fc15.x86_64 Nov 04 15:46:43 Updated: freeipa-python-2.1.3-2.fc15.x86_64 Nov 04 15:52:48 Updated: freeipa-client-2.1.3-2.fc15.x86_64 Nov 04 15:52:48 Updated: freeipa-admintools-2.1.3-2.fc15.x86_64 Nov 04 15:54:47 Updated: freeipa-server-2.1.3-2.fc15.x86_64 Nov 04 15:56:02 Updated: freeipa-server-selinux-2.1.3-2.fc15.x86_64 Dan I'm still having fairly serious
Re: [Freeipa-users] ns-slapd hang/segfault
On Thu, Dec 15, 2011 at 11:51, Rich Megginson rmegg...@redhat.com wrote: On 12/15/2011 09:48 AM, Dan Scott wrote: Hi, On Thu, Dec 15, 2011 at 10:58, Rich Megginsonrmegg...@redhat.com wrote: On 12/15/2011 08:41 AM, Dan Scott wrote: Hi, On my Fedora 15 FreeIPA server, I'm having some problems with stability. The server appears to 'hang' and stops responding to LDAP lookups. When I restart the dirsrv service, I get: Dec 15 09:40:02 ohm kernel: [254566.011404] ns-slapd[28910]: segfault at 17d ip 7f00dbc0208c sp 7fff929b7848 error 4 in libc-2.14.so[7f00dbb87000+18f000] and the /var/log/dirsrv/slapd-EXAMPLE-COM/errors contains [15/Dec/2011:09:47:35 -0500] set_krb5_creds - Could not get initial credentials for principal [ldap/example@example.com] in keytab [WRFILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) [15/Dec/2011:09:47:35 -0500] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_496' not found)) This is happening very frequently, I'm having to restart the dirsrv process once an hour, otherwise people start complaining. I experienced similar problems with FreeIPA 1, when I was using Fedora 14 and earlier, and had to regularly (also once per hour) restart the dirsrv process. Could this be related? I also noticed this: https://bugzilla.redhat.com/show_bug.cgi?id=730387 There are updates in 'updates-testing' which I believe fix the above issue, but I'm reluctant to install from a testing repo on my production server, can anyone report any feedback on this? The above bug does not cause a segfault. What version of 389-ds-base are you using? [root@ohm ~]# rpm -qa|grep 389 389-ds-base-libs-1.2.10-0.4.a4.fc15.x86_64 389-ds-base-1.2.10-0.4.a4.fc15.x86_64 [root@ohm ~]# a4 is alpha software. Not sure how that got released to stable. Please enable the collection of core dumps so we can debug the crash - see http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes OK. I think there is a small typo in the instructions: 'debuginfo-install 389-ds-base-debuginfo' should be 'debuginfo-install 389-ds-base' Thanks. Fixed. I managed to get the core dump (attached - so I only sent this message to you, not the list as well), but it doesn't contain much information. This is https://bugzilla.redhat.com/show_bug.cgi?id=755725 Will be fixed in 1.2.10.a6 But this still doesn't explain your kerberos errors. An additional problem is also occurring. I've been finding that the: /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif file is empty and prevents dirsrv from starting. I can restore it from dse.ldif.bak or dse.ldif.startOK, but this may be related to the LDAP problems that I'm having? Thanks, Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ns-slapd hang/segfault
On 12/19/2011 09:01 AM, Dan Scott wrote: On Thu, Dec 15, 2011 at 11:51, Rich Megginsonrmegg...@redhat.com wrote: On 12/15/2011 09:48 AM, Dan Scott wrote: Hi, On Thu, Dec 15, 2011 at 10:58, Rich Megginsonrmegg...@redhat.comwrote: On 12/15/2011 08:41 AM, Dan Scott wrote: Hi, On my Fedora 15 FreeIPA server, I'm having some problems with stability. The server appears to 'hang' and stops responding to LDAP lookups. When I restart the dirsrv service, I get: Dec 15 09:40:02 ohm kernel: [254566.011404] ns-slapd[28910]: segfault at 17d ip 7f00dbc0208c sp 7fff929b7848 error 4 in libc-2.14.so[7f00dbb87000+18f000] and the /var/log/dirsrv/slapd-EXAMPLE-COM/errors contains [15/Dec/2011:09:47:35 -0500] set_krb5_creds - Could not get initial credentials for principal [ldap/example@example.com] in keytab [WRFILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) [15/Dec/2011:09:47:35 -0500] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_496' not found)) This is happening very frequently, I'm having to restart the dirsrv process once an hour, otherwise people start complaining. I experienced similar problems with FreeIPA 1, when I was using Fedora 14 and earlier, and had to regularly (also once per hour) restart the dirsrv process. Could this be related? I also noticed this: https://bugzilla.redhat.com/show_bug.cgi?id=730387 There are updates in 'updates-testing' which I believe fix the above issue, but I'm reluctant to install from a testing repo on my production server, can anyone report any feedback on this? The above bug does not cause a segfault. What version of 389-ds-base are you using? [root@ohm ~]# rpm -qa|grep 389 389-ds-base-libs-1.2.10-0.4.a4.fc15.x86_64 389-ds-base-1.2.10-0.4.a4.fc15.x86_64 [root@ohm ~]# a4 is alpha software. Not sure how that got released to stable. Please enable the collection of core dumps so we can debug the crash - see http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes OK. I think there is a small typo in the instructions: 'debuginfo-install 389-ds-base-debuginfo' should be 'debuginfo-install 389-ds-base' Thanks. Fixed. I managed to get the core dump (attached - so I only sent this message to you, not the list as well), but it doesn't contain much information. This is https://bugzilla.redhat.com/show_bug.cgi?id=755725 Will be fixed in 1.2.10.a6 But this still doesn't explain your kerberos errors. An additional problem is also occurring. I've been finding that the: /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif file is empty and prevents dirsrv from starting. I can restore it from dse.ldif.bak or dse.ldif.startOK, but this may be related to the LDAP problems that I'm having? I don't know. What is the sequence of operations that causes dse.ldif to become empty? Thanks, Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ns-slapd hang/segfault
On Mon, Dec 19, 2011 at 11:03, Rich Megginson rmegg...@redhat.com wrote: On 12/19/2011 09:01 AM, Dan Scott wrote: On Thu, Dec 15, 2011 at 11:51, Rich Megginsonrmegg...@redhat.com wrote: On 12/15/2011 09:48 AM, Dan Scott wrote: Hi, On Thu, Dec 15, 2011 at 10:58, Rich Megginsonrmegg...@redhat.com wrote: On 12/15/2011 08:41 AM, Dan Scott wrote: Hi, On my Fedora 15 FreeIPA server, I'm having some problems with stability. The server appears to 'hang' and stops responding to LDAP lookups. When I restart the dirsrv service, I get: Dec 15 09:40:02 ohm kernel: [254566.011404] ns-slapd[28910]: segfault at 17d ip 7f00dbc0208c sp 7fff929b7848 error 4 in libc-2.14.so[7f00dbb87000+18f000] and the /var/log/dirsrv/slapd-EXAMPLE-COM/errors contains [15/Dec/2011:09:47:35 -0500] set_krb5_creds - Could not get initial credentials for principal [ldap/example@example.com] in keytab [WRFILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) [15/Dec/2011:09:47:35 -0500] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_496' not found)) This is happening very frequently, I'm having to restart the dirsrv process once an hour, otherwise people start complaining. I experienced similar problems with FreeIPA 1, when I was using Fedora 14 and earlier, and had to regularly (also once per hour) restart the dirsrv process. Could this be related? I also noticed this: https://bugzilla.redhat.com/show_bug.cgi?id=730387 There are updates in 'updates-testing' which I believe fix the above issue, but I'm reluctant to install from a testing repo on my production server, can anyone report any feedback on this? The above bug does not cause a segfault. What version of 389-ds-base are you using? [root@ohm ~]# rpm -qa|grep 389 389-ds-base-libs-1.2.10-0.4.a4.fc15.x86_64 389-ds-base-1.2.10-0.4.a4.fc15.x86_64 [root@ohm ~]# a4 is alpha software. Not sure how that got released to stable. Please enable the collection of core dumps so we can debug the crash - see http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes OK. I think there is a small typo in the instructions: 'debuginfo-install 389-ds-base-debuginfo' should be 'debuginfo-install 389-ds-base' Thanks. Fixed. I managed to get the core dump (attached - so I only sent this message to you, not the list as well), but it doesn't contain much information. This is https://bugzilla.redhat.com/show_bug.cgi?id=755725 Will be fixed in 1.2.10.a6 But this still doesn't explain your kerberos errors. An additional problem is also occurring. I've been finding that the: /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif file is empty and prevents dirsrv from starting. I can restore it from dse.ldif.bak or dse.ldif.startOK, but this may be related to the LDAP problems that I'm having? I don't know. What is the sequence of operations that causes dse.ldif to become empty? Can I find this in the logs? The dirsrv process is crashing regularly, so I have to regularly restart it. Occasionally (seemingly randomly) it fails to restart because the dse.ldif file is empty. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ns-slapd hang/segfault
On 12/19/2011 09:13 AM, Dan Scott wrote: On Mon, Dec 19, 2011 at 11:03, Rich Megginsonrmegg...@redhat.com wrote: On 12/19/2011 09:01 AM, Dan Scott wrote: On Thu, Dec 15, 2011 at 11:51, Rich Megginsonrmegg...@redhat.comwrote: On 12/15/2011 09:48 AM, Dan Scott wrote: Hi, On Thu, Dec 15, 2011 at 10:58, Rich Megginsonrmegg...@redhat.com wrote: On 12/15/2011 08:41 AM, Dan Scott wrote: Hi, On my Fedora 15 FreeIPA server, I'm having some problems with stability. The server appears to 'hang' and stops responding to LDAP lookups. When I restart the dirsrv service, I get: Dec 15 09:40:02 ohm kernel: [254566.011404] ns-slapd[28910]: segfault at 17d ip 7f00dbc0208c sp 7fff929b7848 error 4 in libc-2.14.so[7f00dbb87000+18f000] and the /var/log/dirsrv/slapd-EXAMPLE-COM/errors contains [15/Dec/2011:09:47:35 -0500] set_krb5_creds - Could not get initial credentials for principal [ldap/example@example.com] in keytab [WRFILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) [15/Dec/2011:09:47:35 -0500] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_496' not found)) This is happening very frequently, I'm having to restart the dirsrv process once an hour, otherwise people start complaining. I experienced similar problems with FreeIPA 1, when I was using Fedora 14 and earlier, and had to regularly (also once per hour) restart the dirsrv process. Could this be related? I also noticed this: https://bugzilla.redhat.com/show_bug.cgi?id=730387 There are updates in 'updates-testing' which I believe fix the above issue, but I'm reluctant to install from a testing repo on my production server, can anyone report any feedback on this? The above bug does not cause a segfault. What version of 389-ds-base are you using? [root@ohm ~]# rpm -qa|grep 389 389-ds-base-libs-1.2.10-0.4.a4.fc15.x86_64 389-ds-base-1.2.10-0.4.a4.fc15.x86_64 [root@ohm ~]# a4 is alpha software. Not sure how that got released to stable. Please enable the collection of core dumps so we can debug the crash - see http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes OK. I think there is a small typo in the instructions: 'debuginfo-install 389-ds-base-debuginfo' should be 'debuginfo-install 389-ds-base' Thanks. Fixed. I managed to get the core dump (attached - so I only sent this message to you, not the list as well), but it doesn't contain much information. This is https://bugzilla.redhat.com/show_bug.cgi?id=755725 Will be fixed in 1.2.10.a6 But this still doesn't explain your kerberos errors. An additional problem is also occurring. I've been finding that the: /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif file is empty and prevents dirsrv from starting. I can restore it from dse.ldif.bak or dse.ldif.startOK, but this may be related to the LDAP problems that I'm having? I don't know. What is the sequence of operations that causes dse.ldif to become empty? Can I find this in the logs? The dirsrv process is crashing regularly, so I have to regularly restart it. Occasionally (seemingly randomly) it fails to restart because the dse.ldif file is empty. Let me push out the crash fix build to testing and see if that helps. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ns-slapd hang/segfault
On Mon, 2011-12-19 at 11:01 -0500, Dan Scott wrote: On Thu, Dec 15, 2011 at 11:51, Rich Megginson rmegg...@redhat.com wrote: On 12/15/2011 09:48 AM, Dan Scott wrote: Hi, On Thu, Dec 15, 2011 at 10:58, Rich Megginsonrmegg...@redhat.com wrote: On 12/15/2011 08:41 AM, Dan Scott wrote: Hi, On my Fedora 15 FreeIPA server, I'm having some problems with stability. The server appears to 'hang' and stops responding to LDAP lookups. When I restart the dirsrv service, I get: Dec 15 09:40:02 ohm kernel: [254566.011404] ns-slapd[28910]: segfault at 17d ip 7f00dbc0208c sp 7fff929b7848 error 4 in libc-2.14.so[7f00dbb87000+18f000] and the /var/log/dirsrv/slapd-EXAMPLE-COM/errors contains [15/Dec/2011:09:47:35 -0500] set_krb5_creds - Could not get initial credentials for principal [ldap/example@example.com] in keytab [WRFILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) [15/Dec/2011:09:47:35 -0500] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_496' not found)) This is happening very frequently, I'm having to restart the dirsrv process once an hour, otherwise people start complaining. I experienced similar problems with FreeIPA 1, when I was using Fedora 14 and earlier, and had to regularly (also once per hour) restart the dirsrv process. Could this be related? I also noticed this: https://bugzilla.redhat.com/show_bug.cgi?id=730387 There are updates in 'updates-testing' which I believe fix the above issue, but I'm reluctant to install from a testing repo on my production server, can anyone report any feedback on this? The above bug does not cause a segfault. What version of 389-ds-base are you using? [root@ohm ~]# rpm -qa|grep 389 389-ds-base-libs-1.2.10-0.4.a4.fc15.x86_64 389-ds-base-1.2.10-0.4.a4.fc15.x86_64 [root@ohm ~]# a4 is alpha software. Not sure how that got released to stable. Please enable the collection of core dumps so we can debug the crash - see http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes OK. I think there is a small typo in the instructions: 'debuginfo-install 389-ds-base-debuginfo' should be 'debuginfo-install 389-ds-base' Thanks. Fixed. I managed to get the core dump (attached - so I only sent this message to you, not the list as well), but it doesn't contain much information. This is https://bugzilla.redhat.com/show_bug.cgi?id=755725 Will be fixed in 1.2.10.a6 But this still doesn't explain your kerberos errors. An additional problem is also occurring. I've been finding that the: /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif file is empty and prevents dirsrv from starting. I can restore it from dse.ldif.bak or dse.ldif.startOK, but this may be related to the LDAP problems that I'm having? This is an upgrade time problem, it should be fixed in latest packages. Did you recently upgrade freeipa packages if so from what version to what version ? (If you used yum you can use 'yum history' to find out) Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ns-slapd hang/segfault
On Mon, Dec 19, 2011 at 14:14, Simo Sorce s...@redhat.com wrote: On Mon, 2011-12-19 at 11:01 -0500, Dan Scott wrote: On Thu, Dec 15, 2011 at 11:51, Rich Megginson rmegg...@redhat.com wrote: On 12/15/2011 09:48 AM, Dan Scott wrote: Hi, On Thu, Dec 15, 2011 at 10:58, Rich Megginsonrmegg...@redhat.com wrote: On 12/15/2011 08:41 AM, Dan Scott wrote: Hi, On my Fedora 15 FreeIPA server, I'm having some problems with stability. The server appears to 'hang' and stops responding to LDAP lookups. When I restart the dirsrv service, I get: Dec 15 09:40:02 ohm kernel: [254566.011404] ns-slapd[28910]: segfault at 17d ip 7f00dbc0208c sp 7fff929b7848 error 4 in libc-2.14.so[7f00dbb87000+18f000] and the /var/log/dirsrv/slapd-EXAMPLE-COM/errors contains [15/Dec/2011:09:47:35 -0500] set_krb5_creds - Could not get initial credentials for principal [ldap/example@example.com] in keytab [WRFILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) [15/Dec/2011:09:47:35 -0500] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_496' not found)) This is happening very frequently, I'm having to restart the dirsrv process once an hour, otherwise people start complaining. I experienced similar problems with FreeIPA 1, when I was using Fedora 14 and earlier, and had to regularly (also once per hour) restart the dirsrv process. Could this be related? I also noticed this: https://bugzilla.redhat.com/show_bug.cgi?id=730387 There are updates in 'updates-testing' which I believe fix the above issue, but I'm reluctant to install from a testing repo on my production server, can anyone report any feedback on this? The above bug does not cause a segfault. What version of 389-ds-base are you using? [root@ohm ~]# rpm -qa|grep 389 389-ds-base-libs-1.2.10-0.4.a4.fc15.x86_64 389-ds-base-1.2.10-0.4.a4.fc15.x86_64 [root@ohm ~]# a4 is alpha software. Not sure how that got released to stable. Please enable the collection of core dumps so we can debug the crash - see http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes OK. I think there is a small typo in the instructions: 'debuginfo-install 389-ds-base-debuginfo' should be 'debuginfo-install 389-ds-base' Thanks. Fixed. I managed to get the core dump (attached - so I only sent this message to you, not the list as well), but it doesn't contain much information. This is https://bugzilla.redhat.com/show_bug.cgi?id=755725 Will be fixed in 1.2.10.a6 But this still doesn't explain your kerberos errors. An additional problem is also occurring. I've been finding that the: /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif file is empty and prevents dirsrv from starting. I can restore it from dse.ldif.bak or dse.ldif.startOK, but this may be related to the LDAP problems that I'm having? This is an upgrade time problem, it should be fixed in latest packages. Did you recently upgrade freeipa packages if so from what version to what version ? The 0 length file doesn't appear related to upgrades. Possibly it only happens on the first service restart after an upgrade? It's happened at least 4 times since the last freeipa package upgrade on 4th November, so it seems to be happening too regularly to be the result of an upgrade. [root@curie ~]# grep freeipa /var/log/yum.log Sep 06 16:56:51 Installed: freeipa-python-2.0.1-2.fc15.x86_64 Sep 06 17:00:13 Installed: freeipa-client-2.0.1-2.fc15.x86_64 Sep 06 17:00:14 Installed: freeipa-admintools-2.0.1-2.fc15.x86_64 Sep 06 17:01:52 Installed: freeipa-server-selinux-2.0.1-2.fc15.x86_64 Sep 06 17:01:56 Installed: freeipa-server-2.0.1-2.fc15.x86_64 Sep 08 11:23:35 Updated: freeipa-python-2.1.0-1.fc15.x86_64 Sep 08 11:23:41 Updated: freeipa-client-2.1.0-1.fc15.x86_64 Sep 08 11:23:41 Updated: freeipa-admintools-2.1.0-1.fc15.x86_64 Sep 08 11:25:00 Updated: freeipa-server-selinux-2.1.0-1.fc15.x86_64 Sep 08 11:26:06 Updated: freeipa-server-2.1.0-1.fc15.x86_64 Nov 04 15:46:43 Updated: freeipa-python-2.1.3-2.fc15.x86_64 Nov 04 15:52:48 Updated: freeipa-client-2.1.3-2.fc15.x86_64 Nov 04 15:52:48 Updated: freeipa-admintools-2.1.3-2.fc15.x86_64 Nov 04 15:54:47 Updated: freeipa-server-2.1.3-2.fc15.x86_64 Nov 04 15:56:02 Updated: freeipa-server-selinux-2.1.3-2.fc15.x86_64 Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ns-slapd hang/segfault
On 12/15/2011 08:41 AM, Dan Scott wrote: Hi, On my Fedora 15 FreeIPA server, I'm having some problems with stability. The server appears to 'hang' and stops responding to LDAP lookups. When I restart the dirsrv service, I get: Dec 15 09:40:02 ohm kernel: [254566.011404] ns-slapd[28910]: segfault at 17d ip 7f00dbc0208c sp 7fff929b7848 error 4 in libc-2.14.so[7f00dbb87000+18f000] and the /var/log/dirsrv/slapd-EXAMPLE-COM/errors contains [15/Dec/2011:09:47:35 -0500] set_krb5_creds - Could not get initial credentials for principal [ldap/example@example.com] in keytab [WRFILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) [15/Dec/2011:09:47:35 -0500] slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_496' not found)) This is happening very frequently, I'm having to restart the dirsrv process once an hour, otherwise people start complaining. I experienced similar problems with FreeIPA 1, when I was using Fedora 14 and earlier, and had to regularly (also once per hour) restart the dirsrv process. Could this be related? I also noticed this: https://bugzilla.redhat.com/show_bug.cgi?id=730387 There are updates in 'updates-testing' which I believe fix the above issue, but I'm reluctant to install from a testing repo on my production server, can anyone report any feedback on this? The above bug does not cause a segfault. What version of 389-ds-base are you using? Please enable the collection of core dumps so we can debug the crash - see http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes Can anyone help me out? Thanks, Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
