|
|
This section provides brief descriptions of server processes that run on the Clearcase LT server. No ClearCase server processes run on a ClearCase LT client.
The Atria location broker daemon or albd_server handles a variety of tasks:
Manages the operation of all ClearCase services on the ClearCase LT server.
Helps set up network communications between ClearCase LT clients and the ClearCase LT server.
Manages execution of tasks run by the ClearCase schedule service.
When you start ClearCase (using the ClearCase control panel on Windows or the atria_start script on UNIX), the albd_server starts first. It then starts other servers as needed.
When you stop ClearCase, the albd_server stops all running ClearCase servers and then exits.
In addition to starting and stopping services, the albd_server helps client programs like cleartool and ClearCase GUIs use remote procedure calls (RPCs) to connect with the ClearCase LT server. When a client program wants to access the ClearCase LT server, it uses an RPC to send a request to the albd_server process on that host. The albd_server starts the requested service if it is not already started, then issues a response telling the client the service's port number (socket address). Thereafter, the client communicates directly with the specific service, without involving the albd_server.
The albd_server reads configuration file albd.conf during startup to determine which services to provide. Do not modify this file.
The ClearCase administration server admin_server is invoked as needed by the albd_server process. This short-lived server performs miscellaneous administrative support functions:
Retrieving server log files for display by the getlog command and the ClearCase Administration Console.
Retrieving and changing the ClearCase LT server's ClearCase properties when requested by the ClearCase Administration Console.
A view_server is a long-lived process that manages activity in a particular view.
For each view, a long-lived view_server process runs on the ClearCase LT server. The view_server is started by the host's albd_server process when necessary. On UNIX systems, it runs with the identity of the owner of the view storage directory (usually, the user who created the view). On Windows systems, it runs with the identity of the albd_server (NT AUTHORITY\SYSTEM) A view_server remains active until it is terminated by a cleartool endview -server command, a system shutdown, or an operating system command that terminates the view_server process.
When it begins execution, a view_server reads configuration information from the .view file in the view-storage directory. Values in this file are established by mkview, chview, and similar commands. Do not edit this file yourself.
For each VOB, a long-lived vob_server process runs on the ClearCase LT server. The vob_server runs with the identity of the VOB owner and manipulates data in the VOB's storage pools in response to requests from client processes.
The vob_server is the only process that ever creates or deletes data containers; the VOB owner is the only user who can modify data containers and storage pools. These severe restrictions protect VOB data against careless or malicious users.
A vob_server process is started as needed by albd_server. It remains active until any of the following events occurs:
The operating system is restarted.
The VOB is deleted with the rmvob command.
ClearCase is stopped (UNIX only, see the init_ccase reference page).
When it begins execution, the vob_server reads configuration information from the file vob_server.conf in the VOB storage directory. Values in this file are established by the vob_snapshot_setup utility and similar commands. Do not edit this file yourself.
A host's db_server processes handle VOB database transactions on that host in response to requests from client programs. Because client programs cannot access VOB databases directly, they must send database transaction requests to a db_server process. Typical requests include:
Creating and modifying metadata (such as attaching a label to a version)
Reading metadata (such as finding the labels attached to a version)
Writing event records (such as the one that records a checkout command)
Writing configuration records
Reading event records and configuration records
Each db_server process services a single client at a time, but can operate on any number of VOBs. A client establishes a connection to a db_server with the help of the albd_server on the VOB host. If necessary, the albd_server starts a new db_server process to handle a request. The connection is broken when the client exits or becomes idle (stops requesting database transactions for an extended period). At that point, the db_server becomes available for use by another client; eventually, an unconnected db_server is terminated by albd_server.
The ClearCase LT server runs up to five vobrpc_server processes for each of its VOBs. Each process handles requests from view_server processes throughout the network. The request can generate both metadata (VOB database) and file system data (storage pool) activity. The vobrpc_server accesses the VOB database in exactly the same way as a db_server. It forwards storage pool access requests to the vob_server.
Multiple server processes are started by albd_server, which also routes new requests to the least-busy servers and terminates unneeded vobrpc_server processes when the system is lightly loaded.
The ClearCase LT server runs one database lock manager process, lockmgr. This process arbitrates transaction requests to all VOB databases on that host from ClearCase LT client programs throughout the network. The calling program polls lockmgr, which either grants or prohibits access to the requested data. If the data is available, the transaction proceeds immediately: the data is read or written, and output is returned to the calling program. If the data is unavailable (locked because another caller has been granted write access to the data), the caller waits until lockmgr grants it access to the data.
Unlike most other ClearCase services, the lockmgr is not started by the albd_server. Instead, it is started when the ClearCase LT server starts. On UNIX systems, the lockmgr is started by the atria_start script. On Windows, the lockmgr is started by the Service Control Manager.
NOTE: On UNIX systems, the lockmgr communicates with other processes through var/adm/atria/almd, which is a shared-memory file on some platforms and a socket on others. To reduce the likelihood of accidental deletion, /var/adm/atria/almd is owned by root.
Lock manager startup options can be changed if necessary to improve VOB server performance for certain configurations. See Lock Manager Startup Options for more information on this topic.
Each ClearCase server process maintains an error log on the ClearCase LT server. For details on the error logs and how to display them, see the getlog reference page in the Command Reference. In addition, Windows hosts can access error logs for all ClearCase hosts (Windows and UNIX) using the ClearCase Administration Console.
On ClearCase LT servers running UNIX, log files are located in the directory /var/adm/atria/log. Log files record error and status information from various server programs and user programs. These files include the following:
albd_log | Used by the albd_server |
db_server_log | Used by the db_server |
error_log | General-purpose error log. Used by user programs such as cleartool |
event_scrubber_log | Used by the event_scrubber program |
install_log | Used by install_release (installation script) |
lockmgr_log | Used by the lockmgr program |
scrubber_log | Used by the scrubber program |
view_log | Used by the view_server |
vob_log | Used by the vob_server |
vob_scrubber_log | Used by vob_scrubber program |
vobrpc_server_log | Used by vobrpc_server |
Error log files are ordinary text files. A typical entry includes the date and time of the error, the software module in which the error occurred, the current user, and an error-specific message.
As errors accumulate, the error log files grow. By default, the scheduler periodically runs a job that renames error log files to logfile_name.old, and creates empty template files in their place. See the schedule reference page for information on describing and changing scheduled jobs.
On ClearCase LT servers running Windows, ClearCase server processes and other ClearCase programs write informational, warning, and error messages to the Windows application event log. The source of these messages is displayed as ClearCase LT. A typical event log entry includes the date and time of the error, the software module in which the error occurred, the current user, and an error-specific message.
As errors accumulate, the error log files grow. Use the Event Viewer to save or delete logs.
|
|
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |
