ESM policy run is hanging on a UNIX server and when looking at running processes on the server with PS command you are seeing many defunct processes that can be traced back to the usrfiles binary in the /esm/bin/<os_type> folder. You may be having to restart the agent service to clean these defunct processes up.
Here is a typical output on a UNIX server:
servername]/root#ps -aef|grep -i 27699
root 12465 27699 11 21:30:08 ? 0:00 <defunct>
root 28762 27699 1 21:28:27 ? 0:00 <defunct>
root 28083 27699 11 21:28:17 ? 0:00 <defunct>
root 29863 27699 12 21:28:37 ? 0:00 <defunct>
root 14047 27699 11 21:30:19 ? 0:00 <defunct>
root 8938 27699 1 21:29:48 ? 0:00 <defunct>
root 7848 27699 1 21:29:38 ? 0:00 <defunct>
root 15095 27699 17 21:30:29 ? 0:00 usrfiles /esm/system/
root 6414 27699 2 21:29:18 ? 0:00 <defunct>
root 15494 18944 0 21:30:32 pts/2 0:00 grep -i 27699
Umask check using the SU method is selected in the User Files module. There is a prompt in the login script for the various user ids that asks for input, such as the pressing of an ENTER key. This is causing this particular check to hang and create defunct processes for each ID that the module tries to use the SU method on to determine the umask setting.
The creation of defunct processes by this check is being treated as a defect and is targeted to be fixed in Security Update 44. In the meantime you may want to use the umask check that uses the Login Script method to determine the umask number rather than the SU method check. Alternately, if the prompt in the login scripts is of no value, you can remove the prompt in order to use the SU method check.
The fix in SU 44 will not allow the umask setting to be determined if there is a prompt in the login script but will keep the module from creating defunct processes.
Imported Document Id