Troubleshooting
Problem
This technote identifies a defect where a deleted username can negatively impact performance and functionality of all versions of IBM® Rational® ClearCase® if the account is still in an exception list, []-nusers[], of a VOB object.
Symptom
Overview
The -nusers switch is available for cleartool subcommands, such as lock and mktrype, to create an exception list for objects in a Rational ClearCase VOB.
A username that is included on an exception list is granted rights to modify the object, while users that are not on the list cannot modify the object.
When the object is changed, ClearCase checks the authenticity of the user running the operation as well as all other users that are specified in the -nusers list, even accounts that have been deleted in the environment.
Deleted user account
When a user account is removed from the environment without first being explicitly removed from the exception list of an object, then it remains on the list. There is no update sent to or captured by ClearCase to remove the account from exception list.
In this situation, though the username is no longer valid, it still requires authentication when the VOB object is modified.
As expected, the lookup attempt for an invalid account is unsuccessful, but the remote procedure call (RPC) takes several moments longer to return than if the account was still available in the environment. Hence, this will increase the time it takes for the ClearCase operation to complete.
Since ClearCase does not cache negative failures (or failed lookup attempts), each time an operation is performed against the VOB object, the lookup will occur for any deleted account in the -nusers list.
Note: The delay will vary from environment to environment due to unique configurations, and in some cases, the operation can fail as seen in some of the below examples.
Cause
Defect APAR PK35018 has been submitted to investigate this scenario.
Resolving The Problem
The defect has been closed as ClearCase is working as designed. If the user account is removed but still associated with locked metadata, ClearCase will not perform optimally because it will continue to try and authenticate the user.
Recommendations
- When possible, it is best to just disable a user account, rather than delete it from the environment. However, if the user account must be removed, then see the below suggestions to help with administration of an exception list.
- The -nusers option should be used with discretion to help minimize (and possibly prevent) any performance degradation as detailed above when a user account is deleted.
- Track user accounts that are added to an exception list for an object, that way, should the account need to be deleted, it can first be removed from the -nusers list. Review the next section to see how to check for invalid accounts.
Check for an invalid account
List usernames in -nusers list
You can display the list of users included in an exception list of either a lock or a trigger type using the following command syntax:
(Windows syntax example)
cleartool lslock -l -obs -all vob:<vob-tag> | find "Locked except"
cleartool lstype -l -obs -kind trtype -invob <vob-tag> | find "excluded users"
Check for all user accounts mentioned in the output whether they are still defined in your domain (see below).
If not, then either define and or disable them, or change the exception list on the trigger type or the lock to remove the undefined user account.
Note: Obsoleted trigger types can cause the problem.
Use creds to check account
The ClearCase credentials utility, creds, can be used to determine if a username in an exception list is no longer valid in the environment.
Here is an example of the output that will get returned by creds utility for an invalid account:
Note: This utility will work for any user account whether it is used for ClearCase or not.
>creds user1
Windows NT user info (on local system):
*** LookupAccountName((null),user1) - No mapping between account names and security IDs was done.
ClearCase user info:
*** Can't get user info for "user1"
For more information on creds, refer to technote 1221403.
These are all situations where a non-existent username in the exception list had to be removed to resolve the problem.
- A user account that no longer exists, but is still listed in the -nusers option for cleartool lock of a branch can cause a checkout, checkin and merge to fail like:
error checking out M:/testvu/lib32/test/test_fan/app.
error from vob database lib32. trouble finding the global definition for local type"???".
unable to checkout M:/testvu/lib32/test/test_fan/app.
- Long delays can occur when listing the available label types when trying to apply a label to a version from the ClearCase Version Tree Browser. The delay has been reported to extend from 1 to 5 minutes.
- When attempting to join a UCM project, the operation fails with:
Error Creating the Stream 'dev1_stream'
Error from VOB database: "\pvob1".
Trouble finding the global definition for Local Type "???".
- In a multiple domain environment, the delay can grow exponentially for the lookup of a deleted username to complete.
For example, if the current domain has trusts with other domains then the lookup for the non-existent username must occur in the other domains also. This can take a long time, as the lookup timeout must occur in each trusted domain before returning -2 "nobody", which allows the process to continue.
- Triggers that are configured to run for specific individuals can be problematic if not managed properly.
Note: Even when the trigger is locked obsolete, the problem can still persist.
Documentation
- On-line documentation can be found:
About the ClearCase Information Center
Was this topic helpful?
Document Information
Modified date:
16 June 2018
UID
swg21150848