18.07.2014 Views

Novell eDirectory 8.8 Troubleshooting Guide - NetIQ

Novell eDirectory 8.8 Troubleshooting Guide - NetIQ

Novell eDirectory 8.8 Troubleshooting Guide - NetIQ

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

18Miscellaneous<br />

• Section 18.1, “Backing Up a Container,” on page 95<br />

• Section 18.2, “Repeated <strong>eDirectory</strong> Logins,” on page 95<br />

• Section 18.3, “TCP Connection not Terminating after Abnormal Logout,” on page 95<br />

• Section 18.4, “NDS Error, System Failure (-632) Occurs When Doing ldapsearch for the User<br />

Objects,” on page 96<br />

• Section 18.5, “Disabling SecretStore,” on page 97<br />

18.1 Backing Up a Container<br />

While using ndsbackup to backup a container that has many objects (like a million), it might take<br />

some time to get the list of the objects in the container and start their individual backup.<br />

18.2 Repeated <strong>eDirectory</strong> Logins<br />

Repeated <strong>eDirectory</strong> logins can use up the available memory. Disable the Login Update attribute<br />

using ndsimonitor to overcome this problem.<br />

18.3 TCP Connection not Terminating after<br />

Abnormal Logout<br />

Sometimes the OES Linux server fails to detect a client host that has gone down abruptly due to a<br />

workstation crashing or a power outage. However, the connection is active for the default timeout<br />

(about 12 to 15 minutes) before the connection is cleared.<br />

If you have set the concurrent connections to 1, it is recommended that you either terminate the<br />

connection manually, or wait for the estimated timeout before logging in again. This situation occurs<br />

when the watchdog process fails to close the connection cleanly. So, if the concurrent connections<br />

are set to 1 and the connection is not cleared by the watchdog, users cannot log in.<br />

Linux kernel provides three parameters to change the way keepalive probes work from the server<br />

side. Use these parameters to implement a workaround at the TCP level.<br />

These parameters are available in /proc/sys/net/ipv4/ directory.<br />

• tcp_keepalive_time: Determines the frequency of sending the TCP keepalive packets to keep a<br />

connection alive if it is currently unused. This value is used only when keepalive is enabled.<br />

The tcp_keepalive_time takes an integer value in seconds. The default value is 7200 seconds or<br />

2 hours. This holds good for most of the hosts and does not require many network resources. If<br />

you set this value to low, it engages your network resources with unnecessary traffic.<br />

• tcp_keepalive_probes: Determines the frequency of sending TCP keepalive probes before<br />

deciding a broken connection.<br />

The tcp_keepalive_probes takes an integer value, recommended less than 50 depending on<br />

your tcp_keepalive_time and the tcp_keepalive_interval values. The default is to set to 9 probes<br />

before informing the application of the broken connection.<br />

18<br />

novdocx (en) 6 April 2007<br />

Miscellaneous<br />

95

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!