vxconfigd - Veritas Volume Manager configuration daemon
vxconfigd [-dfk] [-D diag_portal] [-I inquiry_portal] [-m mode] [-r reset] [-R request_portal] [-x arg]
The Veritas Volume Manager (VxVM) configuration daemon, vxconfigd, maintains disk configurations and disk groups in VxVM. vxconfigd takes requests from other utilities for configuration changes, and communicates those changes to the kernel and modifies configuration information stored on disk. vxconfigd also initializes VxVM when the system is booted.
Equivalent to -m disable, which starts vxconfigd in disabled mode.
Specifies a rendezvous file path name for diagnostic operation connections to vxconfigd. /etc/vx/vold_diag is the default path name. The diagnostic portal exists in both the enabled and disabled operating modes.
Starts vxconfigd in the foreground. This is often useful when debugging vxconfigd, or when tracing configuration changes. If -f is not specified, vxconfigd forks a background daemon process. The foreground process exits when the vxconfigd startup processing completes.
Specifies a rendezvous file path name for inquiry operation connections to vxconfigd. /etc/vx/vold_inquiry is the default path name. The inquiry portal accepts only opcodes for connection requests and query requests submitted by vxprint. All other requests are rejected. The inquiry portal exists only when vxconfigd is operating in enabled mode.
If a vxconfigd process is already running, -k kills it before any other startup processing. This is useful for recovering from a hung vxconfigd process. Killing the old vxconfigd and starting a new one usually does not cause problems for volume devices that are being used by applications, or that contain mounted file systems.
Sets the initial operating mode for vxconfigd. Possible modes are:
Handles boot-time startup of VxVM. If the root disk is encapsulated, the boot disk group (of which the root disk must be a member) is imported, and any required volumes on the root disk are started. Boot mode is capable of operating before the root file system is remounted to read-write. vxdctl enable is called later in the boot sequence to trigger vxconfigd to rebuild the /dev/vx/dsk and /dev/vx/rdsk directories.
Starts vxconfigd in disabled mode. disable creates a rendezvous file for utilities that perform various diagnostic or initialization operations. disable can be used with the -r reset option as part of a command sequence to completely reinitialize Veritas Volume Manager configuration. Use the vxdctl enable operation to enable vxconfigd.
Starts vxconfigd fully enabled (default). enable uses the volboot file to bootstrap and load in the boot disk group if the root disk is under VxVM control. It then scans all known disks for disk groups to import and imports those disk groups. enable also sets up entries in the /dev/vx/dsk and /dev/vx/rdsk directories to define all of the accessible Veritas Volume Manager devices. If the volboot file cannot be read, or if the boot disk group cannot be imported, vxconfigd starts in disabled mode.
Resets all Veritas Volume Manager configuration information stored in the kernel as part of startup processing. The reset fails if any volume devices are in use, or if an imported shared disk group exists. This option is primarily useful for testing or debugging.
Specifies a rendezvous file path name for regular configuration and query requests. /etc/vx/vold_request is the default. The regular request portal exists only when vxconfigd is operating in enabled mode.
Turns on various parameters used for debugging or other aspects of vxconfigd operation. The argument, arg, is a decimal number, 1 through 9, or a string. A number value sets the debug information output level and is required to obtain any debug messages.
The debugging level can also be changed while vxconfigd is running by using the vxdctl debug command.
String arguments include:
Specifies the path name to use for the volboot file. This is primarily useful with the stub debug option. The volboot file contains the name of the boot disk group if the root disk is under VxVM control. It also contains a host ID that is stored on disks in imported disk groups to define ownership of disks as a sanity check for disks that might be accessible from more than one host.
Removes and recreates the /etc/vx/tempdb directory. This directory stores configuration information that is cleared after system reboots (or cleared for specific disk groups on import and deport operations). If the contents of this directory are corrupted, due to a disk I/O failure for example, vxconfigd will not start up if it is killed and restarted. Such a situation can be cleared by starting vxconfigd with -x cleartempdir. This option has no effect if vxconfigd is not started in enabled mode.
Note It is advisable to kill any running operational commands (vxvol, vxsd, or vxmend) before using the -x cleartempdir option. Failure to do so may cause these commands to fail, or may cause disastrous but unchecked interactions between those commands and the issuance of new commands. It is safe to use this option while running the graphical user interface, or while Veritas Volume Manager background daemons are running (vxsparecheck, vxnotify, or vxrelocd).
Specifies the pathname to the file that contains persistent disk access records. This file contains a list of disks that are scanned and configured by VxVM.
Specifies a directory path name to prefix for any disk device accessed by vxconfigd. For example, with devprefix=/tmp, any access to a disk device named sdd would actually be directed to the file /tmp/dev/sdd. In stubbed mode, vxconfigd can operate with such files being regular files. vxconfigd only requires entries in the prefixdir /dev directory in stubbed mode. See stub below for more information.
log | nolog
Logs all vxconfigd console output directly to a file. This method of logging is very reliable in that any messages output before a system crash are available in the log file (if the crash did not corrupt the file system). You can enable direct vxconfigd logging with the -x log argument, and turn it off with the -x nolog argument. Logging is disabled by default.
If direct logging is enabled, the default log file is /etc/vx/vxconfigd.log. This option can be used in conjunction with syslog | nosyslog. See syslog | nosyslog below for more information.
The following command logs all debug and error messages to the specified log file:
vxconfigd -x9 -x log
Specifies an alternate vxconfigd direct log file. This option requires using the -x log argument.
vxconfigd usually configures disk devices that can be found by inspecting kernel disk drivers automatically. These auto_configured disk devices are not stored in persistent configurations, but are regenerated from kernel tables after every reboot. Invoking vxconfigd with -x noautoconfig prevents the automatic configuration of disk devices, forcing VxVM to use only those disk devices configured explicitly using vxdisk define or vxdisk init.
Runs vxconfigd single-threaded.
Specifies not to communicate configuration changes to the kernel. stub is typically used as a demonstration mode of operation for vxconfigd. In most aspects, a stubbed vxconfigd behaves like a regular vxconfigd, except that disk devices can be regular files and volume nodes are not created. A stubbed vxconfigd can run concurrently with a regular vxconfigd, or concurrently with any other stubbed vxconfigd processes, as long as different rendezvous, volboot, and disk files are used for each concurrent process.
Other Veritas Volume Manager utilities can detect when they are connected to a vxconfigd that is running in stubbed mode. When a VM utility detects a stubbed-mode vxconfigd, the utility typically stubs out any direct use of volumes or plexes itself. This allows utilities to make configuration changes in a testing environment that runs without any communication with the kernel or creation of real volumes or plexes.
syslog | nosyslog
vxconfigd supports using the syslog() library call to log all of its console messages (this includes error, warning, and notice messages, but not debug messages). By default, vxconfigd redirects console messages to syslog() when it is first started. You can disable syslog() logging using the -x nosyslog argument, and turn it on with the -x syslog argument. You can also enable or disable syslog() logging at boot-time by editing the Veritas Volume Manager startup scripts.
syslog can be specified along with log (described above) to obtain more reliable logging. For example, the following command logs all debug messages to the specified log file, and logs all error messages to both the direct log file and the syslog.log file:
vxconfigd -x9 -x log -x syslog
Note syslog() logging works only on systems where vxconfigd is compiled with support for the syslog() library calls.
Flushes tracefile data to disk, invoking fsync, to ensure that the last entry is included in the file even if the system crashes.
timestamp | mstimestamp
Attaches a date and time-of-day timestamp to all messages written by vxconfigd to the console. If mstimestamp is used, a millisecond value is also displayed, allowing detailed timing of vxconfigd's operation.
Logs all possible tracing information to the specified file.
If errors are encountered, vxconfigd writes diagnostic messages to the standard error output. vxconfigd exits if it encounters some serious errors. If an error is encountered when importing the boot disk group during a normal startup, vxconfigd enters disabled mode. See the Veritas Volume Manager Troubleshooting Guide for a list of error messages and how to respond to them.
Defined exit codes for vxconfigd are:
The requested startup mode completed successfully. This is returned if -f is not used to startup vxconfigd as a foreground process. If vxconfigd is started as a foreground process, it exits with a zero status if vxdctl\ stop is used to exit vxconfigd.
The command line usage is incorrect.
Enabled-mode operation was requested, but an error caused vxconfigd to enter disabled mode instead. This is also returned for boot-mode operation if startup failed. However, with boot-mode operation, the background vxconfigd process exits as well.
The -k option was specified, but the existing vxconfigd could not be killed.
A system error was encountered that vxconfigd cannot recover from. The specific operation that failed is printed on the standard error output.
The background vxconfigd process was killed by a signal before startup completed. The specific signal is printed on the standard error output.
A serious inconsistency was found in the kernel, preventing sane operation. This can also happen because of version mismatch between the kernel and vxconfigd.
The -r\ reset option was specified, but the Veritas Volume Manager kernel cannot be reset. Usually this means that a volume is open or mounted.
An interprocess communications failure (usually a \s-1STREAMS\s+1 failure). Has made it impossible for vxconfigd to take requests from other utilities.
Volumes that must be started early by vxconfigd could not be started. The reasons, and possible recovery solutions, are printed to the standard error output.
Directory containing block device nodes for volumes.
Directory containing raw device nodes for volumes.
File containing a list of disks to be scanned and configured.
Directory containing miscellaneous temporary files. Files in this directory are recreated after reboot.
File containing miscellaneous boot information. See vxdctl(1M) for more information on this file.
Default log file.
By default, vxconfigd is started at boot time with the -x syslog option. This redirects vxconfigd console messages to syslog(). If you want to retain this behavior when restarting vxconfigd from the command line, include the -x syslog argument, as restarting vxconfigd does not preserve the option settings with which it was previously running. Similarly, any Veritas Volume Manager operations that require vxconfigd to be restarted may not retain the behavior that was previously specified by option settings.
vxdctl(1M), vxintro(1M), vxmend(1M), vxnotify(1M), vxrelocd(1M), vxsd(1M), vxvol(1M), fsync(2), syslog(3), syslogd(8),
Veritas Volume Manager Troubleshooting Guide