|
|
Two server processes-the albd_server and admin_server-run on every ClearCase host that has been configured to support local VOBs and views, regardless of whether any VOBs or views have been created on the host. Other server processes are started as necessary to manage any VOBs and views that reside on the host. This section provides brief descriptions of these servers.
NOTE: A ClearCase host running Windows can be configured with no support for local VOBs and views. Hosts configured this way do not run any ClearCase server processes.
The Atria location broker daemon or albd_server handles a variety of tasks on hosts configured to support local VOBs and views:
Manages the operation of all ClearCase services on a ClearCase VOB or view server host.
Helps set up network communications between ClearCase client and server programs.
Manages execution of tasks run by the ClearCase schedule service.
Fields license-verification requests on the ClearCase license server host.
Fields requests for registry information on a ClearCase registry server host.
On UNIX platforms, fields load-balancing queries from a remote clearmake process. 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.
NOTE: On a ClearCase Windows client host configured with no support for local VOBs and views, no albd_server is installed, and there are no other ClearCase services to stop or start.
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 ClearCase servers. When a client program wants to access a service on a ClearCase host, 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 listens for RPCs on a well-known port (port 371) that has been reserved for it by the Internet Assigned Numbers Authority. ClearCase installation verifies that no other service registered in the UNIX services database or NIS services map uses this port for UDP or TCP communications. If a conflict is detected, we recommend modifying the conflicting service to use another port. If you cannot reconfigure or remove the conflicting service, you can configure the albd_server to use any free UDP port.
On UNIX, edit the local host's services database and/or the NIS services map.
On Windows, create the appropriate entry in the file %SystemRoot%\System32\drivers\etc\services. (If there is no entry for the albd_server in this file, it will use port 371.)
NOTE: All albd_servers in a ClearCase network must use the same port number. If you change the port assignment for the albd_server on any ClearCase host, you must change it for the albd_server on every ClearCase host.
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 local host's ClearCase properties when requested by the ClearCase Administration Console.
rgy_switchover processing-moving registry files and reconfiguring clients
A view_server is a long-lived process that manages activity in a particular view. It interprets the rules in the view's config spec, and (for dynamic views) tracks modifications to view-private files for other ClearCase software.
For each view, a long-lived view_server process runs on the view host. 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 (typically, user clearcase_albd and group clearcase) 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.
For a dynamic view, a view_server handles MVFS file system requests (such as create, delete, and rename) by querying one or more VOB databases and comparing them against the view's own database. Using the view's config spec, it selects versions of file elements and directory elements to be in the view. It also handles requests from cleartool, clearmake, and clearaudit to look up VOB-database objects and/or names.
The view_server and the MVFS use caching techniques to reduce the computational requirements of this scheme. For information about managing view cache sizes for best performance, see View Caches.
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 VOB host. 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.
Each VOB host 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.
Each VOB host runs one database lock manager process, lockmgr. This process arbitrates transaction requests to all VOB databases on that host from ClearCase 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 VOB host 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 host where it executes. ClearCase has a distributed architecture, so an error resulting from a command entered on one host can generate an error log entry on another host. In such cases, the user is directed to the appropriate log file on the appropriate host. 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 hosts 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:
abe_log | Used by the audited build executor (abe) during parallel clearmake builds |
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 |
export_mvfs_log | Used by the export_mvfs program |
install_log | Used by install_release (installation script) |
lockmgr_log | Used by the lockmgr program |
mntrpc_server_log | Used by mntrpc_server program, which performs MVFS-file-system mounts requested by cleartool subcommand mount |
msadm_log | Used by the MultiSite administrative server, which handles requests for mastership |
promote_log | Used by the promote_server |
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 hosts 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. 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.
On Windows, the MVFS logs status messages to the file C:\mvfslogs. You can use the MVFS tab in the ClearCase Control Panel to change this pathname. By default, the scheduler periodically runs a job that deletes MVFS log files more than seven days old. See the schedule reference page for information on describing and changing scheduled jobs.
|
|
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |
