[Fedora-directory-users] temporary resource unavailable problem with fedora directory server

[Rich Megginson]

M Vallapan wrote:
> How do you figure out which clients are grabbing the available
> connections and not letting go ? Could you please provide an example ?
>   
Take a look at the directory server access log.  When a client first 
connects, you will see the connection logged with the client's IP 
address.  The connection will be assigned a number (conn=4364 for 
example).  Then search through the access log from that point looking 
for conn=XXXX to see all operations on that connection.  You should 
eventually see a disconnect.  If you do not, find out what client is on 
the other end of that connection (by IP address or by the types of 
operations it performs).
> On Sat, Mar 1, 2008 at 2:32 AM, Rich Megginson <rmeggins at redhat.com> wrote:
>   
>> M Vallapan wrote:
>>  > Thanks ! the settings you mentioned work, but only for some time then
>>  > the problem arises again. then I have to manually restart fedora-ds to
>>  > break off all the idle sessions for it to be okay again for a little
>>  > while. How do I go about this ?
>>  >
>>  First, figure out what the clients are which are grabbing all of the
>>  available connections and not letting them go . . .
>>
>>  The server does not close idle connections until some other connection
>>  is made.  So you could use ldapsearch to write a script that "pings" the
>>  server every few minutes to force it to close idle connections.
>>
>>
>>     
>>  > On Wed, Feb 27, 2008 at 1:31 AM, Rich Megginson <rmeggins at redhat.com> wrote:
>>  >
>>  >> Low Kian Seong wrote:
>>  >>  > Wow ... a bit of ip information there could someone please take out
>>  >>  > the last email i sent ? How do i request an email be removed ?
>>  >>  >
>>  >>  And in your reply, you copied the entire previous message - I've
>>  >>  contacted Red Hat support to remove the messages from the archive.  But
>>  >>  there is no way to revoke the messages once they are sent.
>>  >>
>>  >>  This information is interesting:
>>  >>
>>  >>
>>  >>  ----- Total Connection Codes -----
>>  >>
>>  >>  B1                    11480    Bad Ber Tag Encountered
>>  >>  U1                     5877    Cleanly Closed Connections
>>  >>  T1                     2187    Idle Timeout Exceeded
>>  >>
>>  >>  B1 usually means the client just exit()'ed without first calling close()
>>  >>  or shutdown() on the TCP/IP socket.  Which is fine.  It's the T1 which
>>  >>  are odd.  Of these 2187, 1864 come from the same client:
>>  >>
>>  >>  13800  XXX.XXX.XXX.129
>>  >>
>>  >>                    8254 -  B1   Bad Ber Tag Encountered
>>  >>                    3608 -  U1   Cleanly Closed Connections
>>  >>                    1864 -  T1   Idle Timeout Exceeded
>>  >>
>>  >>  Take a look at the access log where you get the T1 error upon
>>  >>  disconnect.  You want to find out what the conn=XXXXX is.  From there,
>>  >>  go back in the access log looking for the operations on that
>>  >>  connection.  What are they?  What application are they from?  Why is
>>  >>  that application opening connections and just leaving them open?  If it
>>  >>  is a monitoring application like nagios, you will need to increase the
>>  >>  idle timeout for that application.  You can do this by using a dedicated
>>  >>  BIND dn for that application, then you can increase the idle timeout for
>>  >>  that user without affecting any of the other users - see
>>  >>  http://tinyurl.com/2sy8bl
>>  >>
>>  >>  If you have a lot of applications that open connections and leave them
>>  >>  open for a long time, you will need to figure out how many file
>>  >>  descriptors you need for other clients, and you will need to increase
>>  >>  the number of file descriptors available for the directory server as
>>  >>  well as the size of the directory server connection table -
>>  >>  http://tinyurl.com/35qddb and
>>  >>  http://directory.fedoraproject.org/wiki/Performance_Tuning#Linux
>>  >>
>>  >>  See http://tinyurl.com/35qddb for real time server connection monitoring
>>  >>  information.
>>  >>
>>  >>
>>  >>
>>  >> --
>>  >>  Fedora-directory-users mailing list
>>  >>  Fedora-directory-users at redhat.com
>>  >>  https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>  >>
>>  >>
>>  >>
>>  >
>>  > --
>>  > Fedora-directory-users mailing list
>>  > Fedora-directory-users at redhat.com
>>  > https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>  >
>>
>>
>> --
>>  Fedora-directory-users mailing list
>>  Fedora-directory-users at redhat.com
>>  https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>
>>
>>     
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20080311/8440f35d/attachment.bin>