Home > Veritas Storage Foundation™ Volume Manager Manual Pages
- 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 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.
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 raw disk device named hdisk10 would actually be directed to the file /tmp/dev/rdsk/hdisk10. 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 /var/adm/ras/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 conslog file:vxconfigd -x9 -x log -x syslog
- Flushes tracefile data to disk, invoking fsync, to ensure that the last entry is included in the file even if the system crashes.
- Displays the timestamp (in milliseconds) and elapsed time values of the vxconfigd subsystems that are executed when vxconfigd starts. The N argument controls the verbosity of the output. 1 is the lowest level of verbosity, and 8 is the highest. The command also displays the Begin and End messages of each subsystem, and any quantities that are relevant to that subsystem. For example, the number of LUN paths during device discovery. Elapsed time values are shown within the End messages and represent the computed elpased time between the Begin and End messages. Tagged messages can be used to help determine where time is being spect during vxconfigd startup. This is particularly useful in large LUN configurations. The following sample shows a typical output for tagged messages:
- 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.
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.
Veritas Volume Manager Troubleshooting Guide
Last updated: 11 Oct 2006
Copyright ©2009 Symantec Corporation
All rights reserved.