[Freeipa-users] FreeIPA unresponsive - Causes DOS situations

Martin Basti mbasti at redhat.com
Tue Nov 11 13:14:17 UTC 2014


Ludiwg (CCed) this seems like old (fixed?) DS bug.

On 11/11/14 13:13, Walter van Lille wrote:
> I've just cleaned out a ton of slapd_poll timed out messages from the 
> output and changed the names to protect the innocent, :-)
> Here is the output as requested:
>
>
> *[05/Nov/2014:11:44:05 +0200] - SASL encrypted packet length exceeds 
> maximum allowed limit (length=805634565, limit=2097152).  Change the 
> nsslapd-maxsasliosize attribute in cn=config to increase limit.*
> *
> *
> *[10/Nov/2014:14:45:19 +0200] - slapd_poll(115) timed out*
> *[10/Nov/2014:14:45:19 +0200] sasl_io_enable - Cannot enable SASL 
> security on connection in CLOSING state*
> *[10/Nov/2014:14:45:19 +0200] - Error: could not add/remove IO layers 
> from connection*
> *[11/Nov/2014:11:48:09 +0200] - slapd shutting down - signaling 
> operation threads*
> *[11/Nov/2014:11:48:09 +0200] - slapd shutting down - waiting for 30 
> threads to terminate*
> *[11/Nov/2014:13:14:12 +0200] - slapd shutting down - closing down 
> internal subsystems and plugins*
> *[11/Nov/2014:13:14:12 +0200] - Waiting for 4 database threads to stop*
> *[11/Nov/2014:13:14:13 +0200] - All database threads now stopped*
> *[11/Nov/2014:13:14:13 +0200] - slapd stopped.*
> *[11/Nov/2014:13:26:35 +0200] - 389-Directory/1.2.11.15 
> <http://1.2.11.15> B2014.219.179 starting up*
> *[11/Nov/2014:13:26:35 +0200] schema-compat-plugin - warning: no 
> entries set up under cn=computers, cn=compat,dc=sample,dc=example*
> *[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition cn=Password 
> Policy,cn=accounts,dc=sample,dc=example--no CoS Templates found, which 
> should be added before the CoS Definition.*
> *[11/Nov/2014:13:26:36 +0200] - Skipping CoS Definition cn=Password 
> Policy,cn=accounts,dc=sample,dc=example--no CoS Templates found, which 
> should be added before the CoS Definition.*
> *[11/Nov/2014:13:26:36 +0200] - slapd started. Listening on All 
> Interfaces port 389 for LDAP requests*
> *[11/Nov/2014:13:26:36 +0200] - Listening on All Interfaces port 636 
> for LDAPS requests*
> *[11/Nov/2014:13:26:36 +0200] - Listening on 
> /var/run/slapd-SAMPLE-EXAMPLE.socket for LDAPI requests*
> *[11/Nov/2014:13:57:08 +0200] - slapd_poll(78) timed out*
> *
> *
> *
> *
> *
> *
>
>
> On Tue, Nov 11, 2014 at 1:19 PM, Martin Basti <mbasti at redhat.com 
> <mailto:mbasti at redhat.com>> wrote:
>
>     IMHO It's DS bug, can you share DS error log?
>     pspacek CCed to examine named logs.
>
>     Martin^2
>
>
>     On 11/11/14 12:13, Walter van Lille wrote:
>>     Hi Martin, thanks for the reply.
>>     My version: bind-dyndb-ldap-2.3-5.el6.x86_64
>>     The server doesn't have journalctl installed but I have the
>>     outputs from the messages and named.run files that I included here:
>>
>>     Messages:
>>
>>     *Nov 11 12:30:13 freeipa named[1481]: error (network unreachable)
>>     resolving 'example.example.com.10.123.123.123/A/IN':
>>     2001:500:2f::f#53*
>>     *Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. Try
>>     to adjust "timeout" parameter*
>>     *Nov 11 12:30:23 freeipa named[1481]: LDAP query timed out. Try
>>     to adjust "timeout" parameter*
>>     *Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. Try
>>     to adjust "timeout" parameter*
>>     *Nov 11 12:30:33 freeipa named[1481]: LDAP query timed out. Try
>>     to adjust "timeout" parameter*
>>
>>     Named.run:
>>
>>     *client 10.123.123.123#42639: transfer of 'example.example/IN':
>>     AXFR-style IXFR started*
>>     *client 10.123.123.123#42639: transfer of ''example.example/IN':
>>     AXFR-style IXFR ended*
>>     *client 10.123.123.123#46912: transfer of
>>     '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR started*
>>     *client 10.123.123.123#46912: transfer of
>>     '10.123.123.123.in-addr.arpa/IN': AXFR-style IXFR ended*
>>     *LDAP query timed out. Try to adjust "timeout" parameter*
>>     *LDAP query timed out. Try to adjust "timeout" parameter*
>>     *LDAP query timed out. Try to adjust "timeout" parameter*
>>
>>     I just replaced the IPs and the actual names with something more
>>     generic.
>>
>>     Regards,
>>
>>     Walter
>>
>>     On Thu, Nov 6, 2014 at 5:00 PM, Martin Basti <mbasti at redhat.com
>>     <mailto:mbasti at redhat.com>> wrote:
>>
>>         On 06/11/14 14:58, Walter van Lille wrote:
>>>         Hi,
>>>
>>>         I need some assistance please.
>>>         I've taken over an IPA server to manage a few months ago,
>>>         and it was working fine until recently when it started
>>>         acting up seemingly off its own accord.
>>>         When I do an ipactl status it basically gives an output as
>>>         shown below:
>>>
>>>
>>>         *Directory Service: RUNNING
>>>         *
>>>         *
>>>         *
>>>         *Loooooooooooooooooooooooooooooooooooooooooooooooooong
>>>         pause... (To the tune of 7 minutes sometimes)*
>>>         *
>>>         *
>>>         *KDC Service: RUNNING*
>>>         *KPASSWD Service: RUNNING*
>>>         *DNS Service: RUNNING*
>>>         *MEMCACHE Service: RUNNING*
>>>         *HTTP Service: RUNNING*
>>>         *CA Service: RUNNING*
>>>         *ADTRUST Service: RUNNING*
>>>         *EXTID Service: RUNNING*
>>>
>>>         Running top showed that ns-slapd was munching almost all my
>>>         resources, but I got that fixed by upping the cache.
>>>         Unfortunately this did not correct the issue and it still
>>>         reacts in the same fashion, although the resources have been
>>>         freed up now.
>>>         I've noticed that when I run dig on either the local server
>>>         or a remote machine that the query basically just times out
>>>         as shown here:
>>>
>>>         *dig freeipa.myexample.sample*
>>>         *
>>>         *
>>>         *; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>>
>>>         freeipa.myexample.sample*
>>>         *;; global options: +cmd*
>>>         *;; connection timed out; no servers could be reached*
>>>
>>>         When the KDC service fails to start, then name lookups seem
>>>         OK, but authentication fails. otherwise it's dead in the water.
>>>
>>>         This also happens:
>>>
>>>         *sudo ipactl status*
>>>         *Directory Service: RUNNING*
>>>         *Unknown error when retrieving list of services from LDAP:*
>>>         *
>>>         *
>>>         My software setup is as follows:
>>>
>>>         *CentOS release 6.5 (Final)
>>>         *
>>>         *389-ds-base.x86_64 1.2.11.15-34.el6_5
>>>         *
>>>         *bind.x86_64  32:9.8.2-0.23.rc1.el6_5.1
>>>         *
>>>         *bind-dyndb-ldap.x86_64*
>>>         *bind-libs.x86_64 32:9.8.2-0.23.rc1.el6_5.1*
>>>         *bind-utils.x86_64  32:9.8.2-0.23.rc1.el6_5.1*
>>>         *rpcbind.x86_64 0.2.0-11.el6
>>>         @anaconda-CentOS-201311291202.x86_64/6.5*
>>>         *samba4-winbind.x86_64*
>>>         *krb5-server.x86_64 1.10.3-15.el6_5.1
>>>         *
>>>         *
>>>         *
>>>         *Linux 2.6.32-431.29.2.el6.x86_64 #1 SMP Tue Sep 9 21:36:05
>>>         UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>>>         *
>>>
>>>         It's not a permanent situation as it sometimes runs 100% for
>>>         a while, but 80% of the time it is unusable. If anybody can
>>>         assist me, please be so kind.
>>>
>>>         Regards,
>>>
>>>         Walter
>>>
>>         Hello please which version of bind-dyndb-ldap do you use?
>>         I had similar issue with bind-dyndb-ldap, but it was
>>         development version, I'm not sure if this is your case.
>>         When named was failing, dirserv was really slow.
>>
>>         Can you send journalctl -b -u named log when dig doesn't work??
>>
>>         -- 
>>         Martin Basti
>>
>>
>
>
>     -- 
>     Martin Basti
>
>


-- 
Martin Basti

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141111/e56a4d22/attachment.htm>


More information about the Freeipa-users mailing list