Hi!
After weeks of running slapd 2.3.27 suddenly quits answering requests, instead it says "no such objects" - where are objects. After a restart all data is back again.
Is this a known error (to heal by update - what I will do anyway)?
Hans
----------- conf:
include /opt/mail/etc/openldap/schema/core.schema include /opt/mail/etc/openldap/schema/cosine.schema include /opt/mail/etc/openldap/schema/inetorgperson.schema include /opt/mail/etc/openldap/schema/dyngroup.schema include /opt/mail/etc/openldap/schema/openldap.schema include /opt/mail/etc/openldap/schema/nis.schema include /opt/mail/etc/openldap/schema/authldap.schema
pidfile /opt/mail/var/slapd.pid argsfile /opt/mail/var/slapd.args
loglevel 489
TLSCACertificateFile /opt/mail/etc/openldap/ssl/ca2006.pem TLSCertificateFile /opt/mail/etc/openldap/ssl/cert2006.pem TLSCertificateKeyFile /opt/mail/etc/openldap/ssl/key2006.pem
defaultsearchbase "ou=Proxy,ou=foo,o=bla,c=de"
####################################################################### # BDB database definitions ####################################################################### database monitor access to dn.subtree="cn=monitor" by * read
database meta suffix "ou=Proxy,ou=foo,o=bla,c=de" uri "ldap://edir.niedersachsen.de/ou=foobar,ou=Proxy,ou=foo,o=bla,c=de" suffixmassage "ou=foobar,ou=Proxy,ou=foo,o=bla,c=de" "ou=foobar,o=bla,c=de" uri "ldap://edir.niedersachsen.de/ou=AllgV,ou=Proxy,ou=foo,o=bla,c=de" suffixmassage "ou=AllgV,ou=Proxy,ou=foo,o=bla,c=de" "ou=Exchange-Verbund,o=bla,c=de"
access to dn.subtree="ou=Proxy,ou=foo,o=bla,c=de" by * read
Hi!
After weeks of running slapd 2.3.27 suddenly quits answering requests, instead it says "no such objects" - where are objects. After a restart all data is back again.
Is this a known error (to heal by update - what I will do anyway)?
No, it's not (to me, at least). Updating could be an option, since connection caching and handling was significantly improved 'round 2.3.30 or something. If the problem persists, you should provide logs of what is actually done by slapd-meta(5) when it stops responding as expected. Probably, any serious issue will be logged at "any" level, so there should be no need to increase the log level. If nothing relevant appears, you should increase the log level (without stopping the server, of course; you can do this either via back-config or back-monitor). In any case, you can also force connections to expire and refresh; see "conn-ttl" and "idle-timeout" in slapd-meta(5). They are complementary, so I suggest using both.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati schrieb:
No, it's not (to me, at least). Updating could be an option, since connection caching and handling was significantly improved 'round 2.3.30 or something. If the problem persists, you should provide logs of what is actually done by slapd-meta(5) when it stops responding as expected. Probably, any serious issue will be logged at "any" level, so there should be no need to increase the log level. If nothing relevant appears, you should increase the log level (without stopping the server, of course; you can do this either via back-config or back-monitor).
What is the intended loglevel?
In any case, you can also force connections to expire and refresh; see "conn-ttl" and "idle-timeout" in slapd-meta(5). They are complementary, so I suggest using both.
I think, I do this first. Any prefered values for these options?
Thanks!
Hans
Pierangelo Masarati schrieb:
No, it's not (to me, at least). Updating could be an option, since connection caching and handling was significantly improved 'round 2.3.30 or something. If the problem persists, you should provide logs of what is actually done by slapd-meta(5) when it stops responding as expected. Probably, any serious issue will be logged at "any" level, so there should be no need to increase the log level. If nothing relevant appears, you should increase the log level (without stopping the server, of course; you can do this either via back-config or back-monitor).
What is the intended loglevel?
trace + args should give more than enough information. That's what libldap uses most, and slapd-meta(5) heavily uses libldap.
In any case, you can also force connections to expire and refresh; see "conn-ttl" and "idle-timeout" in slapd-meta(5). They are complementary, so I suggest using both.
I think, I do this first. Any prefered values for these options?
It depends on how often you want/accept connections refreshed. I'd put something the order of a day for conn-ttl, and something the order of a hour for idle-timeout, but YMMV.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
openldap-software@openldap.org
-
Hans Moser -
Pierangelo Masarati