NAME

udebug - Reports Ubik process status for a database service instance

SYNOPSIS

udebug -server <server machine> [-port <IP port>] [-long [<print all info: yes|no>]] [-coordinator [<print coordinator info: quorum|unanimity>]] [-waitfor [<recovery state: quorum|founddb|havedb|sentdb|modifieddb>]] [-duration <seconds (0 = forever)>] [-help]

DESCRIPTION

The udebug command displays the status of the Ubik database service identified by the -server and -port arguments. The output identifies the addresses where Ubik peers are running, which of them is the Ubik coordinator (synchronization site), and the status of the connections between them.

OPTIONS

-server <hostname or IP address>

Combined with the -port argument names the database service for which to display status information. Provide a fully qualified hostname or IP address.

-port <IP port>

Identifies the database server process for which to display status information, either by its process name or port number. Provide one of the following values:

-long [<print all info: yes|no>]

Reports additional information about each peer of the Ubik service named by the -server argument. The information appears by default if that instance is the Ubik coordinator.

-coordinator [<print coordinator info: quorum|unanimity>]

Display the status of the active coordinator, if any. The default is quorum. If unanimity is specified, then output is generated only if the coordinator was elected by unanimous consent.

-waitfor [<recovery state: quorum|founddb|havedb|sentdb|modifieddb>]

When combined with -coordinator, specifies a recovery state to wait for. By default, the command will wait forever. Use -duration to specify a finite number of seconds to wait. The output will be generated either after the recovery state has been reached or the wait duration has passed.

-duration <seconds (0 = forever)>

When combined with -waitfor, specifies the number of seconds to wait for the recovery state. The default value of 0 seconds means "wait forever".

-help

Prints the online help for this command. All other valid options are ignored.

OUTPUT

Several of the messages in the output provide basic status information about the Ubik service specified by the -server and -port arguments, and the remaining messages are useful mostly for debugging purposes.

To check basic Ubik status, issue the command for each Ubik service instance in turn. In the output for each, one of the following messages appears in the top third of the output.

   I am coordinator . . . (<#_sites> servers)

   I am not coordinator

For the Ubik coordinator, the following message indicates that all sites have the same version of the database, which implies that Ubik is functioning correctly. See the following for a description of values other than 1f.

   Recovery state 1f

For correct Ubik operation, time must be synchronized across all machines hosting Ubik service instances. The following messages, which are the second and third lines in the output, report the current date and time according to the host's clock and the clock on the system where the udebug command is issued.

   Host's <IP_addr> time is <dbserver_date/time>
   Local time is <local_date/time> (time differential <skew> secs)

The <skew> is the difference between the Ubik service clock and the local clock. Its absolute value is not vital for Ubik functioning, but a difference of more than a few seconds between the skew values for the Ubik service instances indicates that their clocks are not synchronized and Ubik performance can be hampered.

Following is a description of all messages in the output. As noted, it is useful mostly for debugging and most meaningful to someone who understands Ubik's implementation.

The output begins with the following messages. The first message reports the IP addresses that are configured with the operating system on the machine specified by the -server argument. As previously noted, the second and third messages report the current date and time according to the clocks on the database server machine and the machine where the udebug command is issued, respectively. All subsequent timestamps in the output are expressed in terms of the local clock rather than the database server machine clock.

   Host's addresses are: <list_of_IP_addrs>
   Host's <IP_addr> time is <dbserver_date/time>
   Local time is <local_date/time> (time differential <skew> secs)

If the <skew> is more than about 10 seconds, the following message appears. As noted, it does not necessarily indicate a Ubik malfunction: it denotes clock skew between the database server machine and the local machine, rather than among the database server machines.

   ****clock may be bad

If the udebug command is issued during the coordinator election process and voting has not yet begun, the following message appears next.

   Last yes vote not cast yet

Otherwise, the output continues with the following messages.

   Last yes vote for <sync_IP_addr> was <last_vote> secs ago (coordinator);
   Last vote started <vote_start> secs ago (at <date/time>)
   Local db version is <db_version>

The first indicates which peer this Ubik process last voted for as coordinator (it can vote for itself) and how long ago it sent the vote. The second message indicates how long ago the Ubik coordinator requested confirming votes from the secondary sites. Usually, the <last_vote> and <vote_start> values are the same; a difference between them can indicate clock skew or a slow network connection between the two database server machines. A small difference is not harmful. The third message reports the current version number <db_version> of the database maintained by this Ubik process. It has two fields separated by a period. The field before the period is based on a timestamp that reflects when the database first changed after the most recent coordinator election, and the field after the period indicates the number of changes since the election.

The output continues with messages that differ depending on whether the Ubik process is the coordinator or not.

For both the Ubik coordinator and secondary sites, the output continues with the following messages. The first message reports the version number of the database at the coordinator, which needs to match the <db_version> reported by the preceding Local db version message. The second message indicates how many database records are currently locked for any operation or for writing in particular. The values are nonzero if the udebug command is issued while an operation is in progress.

   Coordinator's db version is <db_version>
   <locked> locked pages, <writes> of them for write

The following messages appear next only if there are any read or write locks on database records:

   There are read locks held
   There are write locks held

Similarly, one or more of the following messages appear next only if there are any read or write transactions in progress when the udebug command is issued:

   There is an active write transaction
   There is at least one active read transaction
   Transaction tid is <tid>

If the machine named by the -server argument is the coordinator, the next message reports when the current coordinator last updated the database.

    Last time a new db version was labelled was:
            <last_restart> secs ago (at <date/time>)

If the machine named by the -server argument is the coordinator, the output concludes with an entry for each secondary site that is participating in the quorum, in the following format.

   Server (<IP_address>): (db <db_version>)
   last vote rcvd <last_vote> secs ago (at <date/time>),
   last beacon sent <last_beacon> secs ago (at <date/time>),
       last vote was { yes | no }
   dbcurrent={ 0 | 1 }, up={ 0 | 1 } beaconSince={ 0 | 1 }

The first line reports the site's IP address and the version number of the database it is maintaining. The <last_vote> field reports how long ago the coordinator received a vote message from the Ubik process at the site, and the <last_beacon> field how long ago the coordinator last requested a vote message. If the udebug command is issued during the coordinator election process and voting has not yet begun, the following messages appear instead.

   Last vote never rcvd
   Last beacon never sent

On the final line of each entry, the fields have the following meaning:

Including the -long flag produces peer entries even when the -server argument names a secondary site, but in that case only the IP_address field is guaranteed to be accurate. For example, the value in the <db_version> field is usually 0.0, because secondary sites do not poll their peers for this information. The values in the last_vote and last_beacon fields indicate when this site last received or requested a vote as coordinator; they generally indicate the time of the last coordinator election.

EXAMPLES

This example checks the status of the Ubik process for the Location Service on the machine db1.your-cell-name.com, which is the Ubik coordinator.

   % udebug db1.your-cell-name.com vlserver
   Host's addresses are: 192.168.107.33
   Host's 192.168.107.33 time is Wed Oct 27 09:49:50 1999
   Local time is Wed Oct 27 09:49:52 1999 (time differential 2 secs)
   Last yes vote for 192.168.107.33 was 1 secs ago (coordinator);
   Last vote started 1 secs ago (at Wed Oct 27 09:49:51 1999)
   Local db version is 940902602.674
   I am coordinator until 58 secs from now (at Wed Oct 27 09:50:50 1999) (3 servers)
   Recovery state 1f
   Coordinator's db version is 940902602.674
   0 locked pages, 0 of them for write
   Last time a new db version was labelled was:
            129588 secs ago (at Mon Oct 25 21:50:04 1999)

   Server( 192.168.107.35 ): (db 940902602.674)
       last vote rcvd 2 secs ago (at Wed Oct 27 09:49:50 1999),
       last beacon sent 1 secs ago (at Wed Oct 27 09:49:51 1999), last vote was yes
       dbcurrent=1, up=1 beaconSince=1

   Server( 192.168.107.34 ): (db 940902602.674)
       last vote rcvd 2 secs ago (at Wed Oct 27 09:49:50 1999),
       last beacon sent 1 secs ago (at Wed Oct 27 09:49:51 1999), last vote was yes
       dbcurrent=1, up=1 beaconSince=1

This example checks the status of the Protection Service on the machine with IP address 192.168.107.34, which is a secondary site. The local clock is about 4 minutes behind the database server machine's clock.

   % udebug 192.168.107.34 7002
   Host's addresses are: 192.168.107.34
   Host's 192.168.107.34 time is Wed Oct 27 09:54:15 1999
   Local time is Wed Oct 27 09:50:08 1999 (time differential -247 secs)
   ****clock may be bad
   Last yes vote for 192.168.107.33 was 6 secs ago (coordinator);
   Last vote started 6 secs ago (at Wed Oct 27 09:50:02 1999)
   Local db version is 940906574.25
   I am not coordinator
   Lowest host 192.168.107.33 was set 6 secs ago
   Coordinator host 192.168.107.33 was set 6 secs ago
   Coordinator's db version is 940906574.25
   0 locked pages, 0 of them for write

PRIVILEGE REQUIRED

None

SEE ALSO

buserver(8), ptserver(8), vlserver(8)

COPYRIGHT

IBM Corporation 2000. http://www.ibm.com/ All Rights Reserved.

This documentation is covered by the IBM Public License Version 1.0. It was converted from HTML to POD by software written by Chas Williams and Russ Allbery, based on work by Alf Wachsmann and Elizabeth Cassell.

ACKNOWLEDGEMENTS

"AFS" is a registered mark of International Business Machines Corporation, used under license. (USPTO Registration 1598389)

"OpenAFS" is a registered mark of International Business Machines Corporation. (USPTO Registration 4577045)

The "AuriStor" name, log 'S' brand mark, and icon are registered marks of AuriStor, Inc. (USPTO Registrations 4849419, 4849421, and 4928460) (EUIPO Registration 015539653).

"Your File System" is a registered mark of AuriStor, Inc. (USPTO Registrations 4801402 and 4849418).

"YFS" and "AuriStor File System" are trademarks of AuriStor, Inc.