|
On 11/21/2013 02:23 AM, Mitja Mihelič
wrote:
I disabled LDAP paging in sssd.conf
and let the setup run for a while. No crashes since.
It does worry me though, that some other application could crash
the server by using result paging.
I am worried too. Please file a ticket.
On 18. 11. 2013 17:05, Rich Megginson wrote:
On 11/18/2013 07:01 AM, Mitja
Mihelič wrote:
On 15. 11. 2013 21:46, Rich
Megginson wrote:
On 11/15/2013 02:58 AM, Mitja
Mihelič wrote:
On 14. 11. 2013 22:08, Rich Megginson wrote:
On 11/14/2013 08:50 AM,
Mitja Mihelič wrote:
One of the consumers has
crashed again and I have attached the stacktrace.
Four hous later it crashed again.
I do hope there is something in the stacktraces, so
that something can be done to prevent future
crashes.
Unfortunately, not enough. Looks like there is still
some mismatch between the version of the package and the
version of the debuginfo package.
rpm -q 389-ds-base 389-ds-base-debuginfo openldap
openldap-debuginfo db4 db4-debuginfo nss nss-debuginfo
nspr nspr-debuginfo glibc glibc-debuginfo
The suggested debuginfo packages were not installed at the
time when the stacktraces were made. They are installed
now. I have recreated the stacktraces and attached them.
The crash looks related to paged searches. We have changed
this code somewhat in the next version. Can you try the
latest version in the EPEL6 testing repo?
389-ds-base-1.2.11.23-3
http://port389.org/wiki/Download
Before installing packages from the testing repo, are there
any other changes I could do?
When you mentioned a relation to paged searches, perharps this
might be related to our usage of SSSD ona server that is
querying the 389DS.
Currently it uses paging of results, as it is enabled by
default and page size is set to 1000 results.
On the 389DS nsslapd-sizelimit is set to 2000.
Every 5 minutes SSSD issues this search query:
SRCH base="dc=TIER2,dc=COMPANY,dc=si" scope=2
filter="(&(objectClass=posixAccount)(uid=*)(uidNumber=*)(gidNumber=*))"
attrs="objectClass uid userPassword uidNumber gidNumber gecos
homeDirectory loginShell krbprincipalname cn modifyTimestamp
modifyTimestamp shadowLastChange shadowMin shadowMax
shadowWarning shadowInactive shadowExpire shadowFlag
krblastpwdchange krbpasswordexpiration pwdattribute
authorizedService accountexpires useraccountcontrol
nsAccountLock host logindisabled loginexpirationtime
loginallowedtimemap"
The first 1000 entries are returned.
conn=1276 op=3 RESULT err=0 tag=101 nentries=1000
etime=34.129000 notes=U,P
Then the exact same search is issued again, and 999 are
returned.
conn=1276 op=4 RESULT err=4 tag=101 nentries=999
etime=1.056000 notes=U,P
err=4 is understandable, since nsslapd-sizelimit = 2000.
Should I disable result paging for SSSD?
You could try that, yes. The problem seems related to paging.
Perhaps even set nsslapd-sizelimit to -1? (I would not like to
do this)
Regards, Mitja
Also, if you are seeing the message:
ber_flush skipped because the connection was marked to
be closed or abandoned
This means you are running with the CONNS error log
level, which means you may have a lot of useful
information in your errors log. Would you be able to
provide that?
I can provide the error logs, but will need to anonimize
our user data. How large a time time interval do you need?
The last log message in errors log was both times:
ber_flush skipped because the connection was marked
to be closed or abandoned
The following versions 389ds packages were installed
at the time:
389-admin-1.1.29-1.el6.x86_64
389-admin-console-1.1.8-1.el6.noarch
389-admin-console-doc-1.1.8-1.el6.noarch
389-adminutil-1.1.15-1.el6.x86_64
389-console-1.1.7-1.el6.noarch
389-ds-1.2.2-1.el6.noarch
389-ds-base-1.2.11.15-22.el6_4.x86_64
389-ds-base-libs-1.2.11.15-22.el6_4.x86_64
389-ds-console-1.2.6-1.el6.noarch
389-ds-console-doc-1.2.6-1.el6.noarch
389-dsgw-1.1.10-1.el6.x86_64
Reragds, Mitja
On 17. 07. 2013 09:52, Mitja MiheliÄ wrote:
It may be best if I removed all 389DS related data
from both of the consumer servers and start fresh.
If they crash again I will send the relevant stack
traces.
|
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
