9.7 Troubleshooting

This section describes commands you can use to troubleshoot failed mastership requests, and lists error messages and their meanings.

Troubleshooting Commands

To determine which replica masters a branch or branch type:

To determine whether a mastership request will succeed:

To list the event history of a branch or branch type and determine who has requested its mastership, use the lshistory -minor -fmt command:

cleartool lshistory -min -fmt "%n\t%o\n%c" file.fm@@/main
file.fm@@/main chmaster
Reqmaster changed master replica from "boston_hub" to "buenosaires".
Requester: user "PURPLEDOC\fangio" in domain "PURPLEDOC" on host "mardelplata"
file.fm@@/main chmaster
Reqmaster changed master replica from "tokyo" to "boston_hub".
Requester: user "PURPLEDOC\susan" in domain "PURPLEDOC" on host "minuteman"
file.fm@@/main chmaster
Reqmaster changed master replica from "bangalore" to "tokyo".
Requester: user "PURPLEDOC\masako" in domain "PURPLEDOC" on host "shinjuku"
file.fm@@/main chmaster
Reqmaster changed master replica from "sanfran_hub" to "bangalore".
Requester: user "PURPLEDOC\kumar" in domain "PURPLEDOC" on host "ramohalli"
...

cleartool lshistory -min -fmt "%n\t%o\n%c" brtype:main@/vobs/doc

Status Messages

Table 12 describes error messages you may see when you enable or disable requests at the replica level, work with the ACL, and allow or deny requests at the branch type or branch level. Table 13 describes error messages associated with mastership requests.

Errors that occur during the mastership request process, including errors that occur during the synchronization export, are written to the msadm log file. To view it, use the cleartool getlog command or the ClearCase Administration Console (Windows).

Table 12 Error Messages from Mastership Request Management Operations


Message

Meaning of message and action to take

Could not check Request for Mastership permissions.


The process that checks the ACL could not determine whether you have read or write permissions on the ACL. Check the msadm and albd log files on the client and server hosts and try the command again later.


Could not edit Request Mastership ACL.


You do not have permission to edit the ACL.

To edit the ACL, you must be VOB owner, root (UNIX), a member of the ClearCase administrators group (Windows), or have write permission on the ACL.


Could not get Request Mastership ACL.


Your client computer could not retrieve the ACL from the VOB server host. There may be a network connection problem. Check the msadm and albd log files on the client and server hosts and try the command again later.


Could not resolve object 'object-identifier'.


The command could not find the object. Check the spelling of the object selector. In a dynamic view context, mount the VOB and try the command again.


Object must be a branch or branch type.


Specify a branch or branch type.

Examples of branch specifications:

/vobs/dev/acc.c@@/main (UNIX)
\doc\stage.pl@@\main\debug (Windows)

Examples of branch type specifications:

brtype:main
brtype:boston_main@/vobs/dev (UNIX)
brtype:v1.0_bugfix@\tests (Windows)


Request for mastership ACL operations on multiple replicas are not allowed.


Specify only one VOB selector.


The specified selector must be a VOB selector.


Specify a VOB selector. For example:

vob:/vobs/dev (UNIX)
vob:\tests (Windows)


Request for mastership ACL operations require a VOB-selector argument.


The VOB family feature level is too low to enable requests for mastership.


The VOB family feature level is less than 2.

If all replicas in the VOB family are at feature level 2 or greater, raise the family feature level.

If any replica in the VOB family has a feature level less than 2, ask the administrator of that replica to upgrade to a newer version of Rational ClearCase (if necessary), raise the feature level of the replica, and send an update packet to the sibling replicas. Raise the family feature level.


This replica does not master its replica object.


A replica must be self-mastering for you to enable requests for mastership in that replica. See Transferring Mastership of a Replica Object.


This replica does not master the branch.


For you to allow or deny mastership requests for a branch, your current replica must master the branch.

Determine which replica masters the branch and ask the administrator of the replica to change mastership of the branch to your replica.


This replica does not master the branch type.


For you to allow or deny mastership requests for a branch type, your current replica must master the branch type.

Determine which replica masters the branch type and ask the administrator of the replica to change mastership of the branch type to your replica.


You cannot specify -instances with the -enable option.


To enable requests at the replica level, use the -enable option and specify a VOB selector. To deny or allow requests for all instances of a branch type, use the -deny or -allow option with the -instances option and specify a branch type selector.


Table 13 Error Messages from Mastership Requests


Message

Meaning of message and action to take

An error at the sibling replica prevented the request for mastership.


The error cannot be specified. Try the request again later. If the request continues to fail, ask the administrator of the master replica to check the ClearCase and MultiSite log files.


At least one checkout prevents the request.


There is a blocking checkout on the branch being requested or on an instance of the branch type being requested. Try the request again later. If the request continues to fail, ask the user at the sibling replica to check in the element.


Could not resolve object 'object-identifier'.


The command could not find the object. Check the spelling of the object selector.


Locks at the sibling replica prevented the request for mastership.


A request for mastership fails if the branch or branch type is locked at the master replica. Ask the administrator of the master replica to unlock the branch or branch type.


Requests are denied for all objects mastered by the sibling replica.


Mastership requests are not enabled for the replica on host hostname. Ask the administrator of the master replica of the branch or branch type to enable mastership requests at the replica level.


Requests are denied for all objects of the given type.


Mastership requests are denied for all instances of the branch type. Ask the administrator of the master replica of the branch to use reqmaster -allow -instances or the Properties Browser (Windows) to allow requests for all instances.


Requests are denied for the object.


Mastership requests are denied for the branch or branch type. Ask the administrator of the master replica to use reqmaster -allow or the Properties Browser (Windows) to allow requests for the branch or branch type.


Requests for mastership can be made only for branches and branch types.


The user must specify a branch or branch type in the reqmaster command.

Examples of branch specifications:

/vobs/dev/acc.c@@/main (UNIX)
\doc\stage.pl@@\main\debug (Windows)

Examples of branch type specifications:

brtype:main
brtype:boston_main@/vobs/dev (UNIX)
brtype:v1.0_bugfix@\tests (Windows)


The object is not a branch or a branch type.


The object is already mastered by replica 'replica-selector'.


The user's current replica already masters the requested object.


The object was not found at the sibling replica. This may indicate that the replicas are not in sync.


The user's current replica has more up-to-date information than other replicas in the VOB family. Ask the administrator of the current replica to do both of the following things:

  • Verify that no update packets are waiting to be imported at other replicas in the VOB family.
  • Determine whether update packets must be sent more frequently. (Frequent exchange of packets means that replicas have up-to-date information about the state of other replicas.)

The sibling replica does not master the object.


The user's current replica has out-of-date information about the mastership of the object. Ask the administrator of the current replica to do both of the following things:

  • Verify that no update packets are waiting to be imported at your current replica or the sibling replica.
  • Send update packets more frequently. (Frequent exchange of packets means that replicas have up-to-date information about the state of other replicas.)

You do not have permission to request mastership from the sibling replica.


The user requesting mastership is not included on the replica's access control list. Ask the administrator of the sibling replica to use reqmaster -acl -get to display the access control list and check the following things:

  • Spelling of user and domain names
  • All variants of the domain name are included
  • User's access level