Tips for finding Knowledge Articles

  • - Enter just a few key words related to your question or problem
  • - Add Key words to refine your search as necessary
  • - Do not use punctuation
  • - Search is not case sensitive
  • - Avoid non-descriptive filler words like "how", "the", "what", etc.
  • - If you do not find what you are looking for the first time,reduce the number of key words you enter and try searching again.
  • - Minimum supported Internet Explorer version is IE9
Home  >

KB-6592: adclient process hangs or goes defunct

23 March,16 at 03:08 PM

Applies to:

All versions of Centrify DirectControl on AIX 7.1


This issue may manifest itself in many varieties, however each of them directly impacting performance or functionality of the adclient process on AIX 7.1 machines. A common observation is for DirectControl to cease user authentication and for adclient to drop into a seemingly "hung" state. There may also be <defunct> child processes to the parent adclient process that appear within the pstree.


> ps -ef | grep -i 4849818
root 4128872 4849818 0 0:00 <defunct>
root 4849818 4391026 0 Mar 17 - 2:05 /usr/sbin/adclient


Issue is unrelated to Centrify code. It occurs due to messages sent from adclient to the port mapper streams queue that cannot be handled due to the socket's sendspace value. This issue is due to an incomplete fix for AIX 7.1. Specifically: IV73993, which was implemented between 7.1 TL03 SP05 and 7.1 TL04 SP00.

Per IBM:
"The fix is not complete. It increased the size of the streams queue from 8K to 64K but it neglected to tell the socket code of the increase as well..<snip>..I’m fairly confident that if you increase the udp_sendspace via the no option, the socket created will be able to accept the larger messages and not get clogged as it is currently happening."


Modify udp_sendspace to be at least 64k via the 'no' utility as follows:

no -p -o udp_sendspace=65536

This will take effect immediately as well as after a reboot, however the port mapper needs to be recycled and the only safe way to do that is to reboot the system.

Note: A reboot will also be necessary to clear any <defunct> processes


IBM will submit an APAR draft to remedy this in a future release.

References(provided as a courtesy):