sys_check - Generates system configuration and analysis for administrators
sys_check [flags1] [flags2 ...]
Lists all subsystems, including security information and setld inventory verification. Lists performance data only (excludes configuration data) Creates escalation files for use in problem reporting to DIGITAL. This produces 2 files TMPDIR/escalate.tar, and one of TMPDIR/escalate_vmzcore.xx, or TMPDIR/escalate_vmcore.xx.gz. This runs sys_check -noquick and includes this output in the escalate.tar file. Lists configuration data, and setld scan. Excludes security information [DIGITAL] Used by Unicensus tool to gather information. This excludes security information and setld scan. [DIGITAL] Used by Unicensus tool to gather information. This includes security information, and setld scan. [DIGITAL] Used by RCM tool to gather information. This includes revision information only.
Outputs debugging information. Only execute warning pass Only execute data gathering pass Output in text, rather than default HTML
The sys_check command writes to standard output the system configuration (software and hardware) of the running system in HTML. sys_check also performs basic analysis of operating system parameters and warns if problems are detected.
The HTML output produced by sys_check can vary between .5MB and 3MB in size typically.
The following environment variables affect the execution of sys_check: Provides a default location for temporary files. Defaults to /var/tmp. Controls number of lines included from various log files. Defaults to 500. Controls number of files in system directories, above which the directory is considered big. Defaults to 15. Controls the size of sys_check detecting a big file. Defaults to 3072KB. Minimum free space needed in TMPDIR, Defaults to 15MB. Location for sys_check to store recovery data. Defaults to /var/recovery. Sys_check automatically cleans up data from previous runs. Typically output per run is about 400KB. This is useful data in event of a catastrophic recovery of the system. Location for sys_check to look for text files to include in sys_check output. Defaults to /var/adhoc. Location for sys_check to find binaries for sys_check tools. Defaults to CWD.
To create escalation files for use in problem reporting to DIGITAL, enter: sys_check -escalate
sys_check calls itself recursively. Thus sys_check must be in the PATH of the current shell, or called with an explicit path on the command line.
sys_check must be run as root.
sys_check does not change system files.
sys_check is updated regularly. New versions should be installed quarterly (or so).
The analysis done by sys_check is not exhaustive, but it includes many of the most common system configuration and operational problems found on production systems.
While sys_check gathers firmware and revision information of hardware devices, it does validate this data. This should be done by qualified support personnel.
sys_check reads many system files.
It is possible for DECevent or uerf commands to not be able to read the binary errolog if old versions of DECevent are in use, or if the binary.errlog has become corrupted. Installing recent versions of DECevent and re-creating the binary.errlog file (if it is corrupted) can solve this problem.
HSZ controllers: The hszterm tool is used to query status of HSZ raid controllers. sys_check looks for a free 'lun' on each target to communicate with HSZ40/50s. If by chance a 'lun' is chosen that is in use, the hszterm query may hang due to scsi reserve assignments to the other system from which it was ran. The solution is to leave lun 7 free on each HSZ SCSI target for HSZ40/50s. It is also important to ensure that sys_check is not running on multiple nodes of the cluster at the same time. If you run into this case you will see in a 'ps' output a 'hszterm' which is not gaining system time, kill that process and the sys_check will continue with the rest of it's work.
sys_check looks for the CCL port to communicate with HSZ70s. Ensure that the CCL port is enabled for each HSZ70 controller. It is also important to ensure that sys_check is not running on multiple nodes of the cluster at the same time. If you run into this case you will see in a 'ps' output a 'hszterm' which is not gaining system time, kill that process and the sys_check will continue with the rest of it's work.
Sys_check attempts to check the NetWorker backup schedule against the /etc/fstab file. Some versions of Networker have a bug in the nsradmin(8) command that cause this check to not output properly.
Sys_check will not validate the NetWorker backup schedule for TruCluster services properly.
The following exit values are returned:
Successful completion An error occurred
Unicensus support tool
Revision Configuration Management Tool