vxconfigd - Volume Manager configuration daemon
vxconfigd [ -kfd ] [ -r reset ] [ -m mode ] [ -x debug ] [ -D diag_portal ] [ -R request_portal ]
The Volume Manager configuration daemon, vxconfigd, is responsible for maintaining configurations of disks and disk groups in the VERITAS Volume Manager. vxconfigd takes requests from other utilities for configuration changes, and communicates those changes to the kernel and modifies configuration information stored on disk. vxconfigd is also responsible for initializing the Volume Manager when the system is booted.
- If a vxconfigd process is running already, then kill 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 should not cause any problems for volume or plex devices that are being
used by applications or that contain mounted file systems.
- Start vxconfigd in the foreground. This is often useful when debugging vxconfigd, or when tracing
configuration changes. If this flag is not used, vxconfigd will fork a background daemon
process. The foreground process will exit as soon as vxconfigd startup processing
- This is equivalent to -mdisable, which starts vxconfigd in disabled mode.
- -r reset
- Reset all Volume Manager configuration information stored in the kernel as part of startup
processing. This will fail if any volume or plex devices are currently in use. This option
is primarily useful for testing or debugging.
- -m mode
- Set the initial operating mode for vxconfigd. Possible values for mode are:
- Start fully enabled (default). This will use the volboot file to bootstrap and load in the
rootdg disk group. It will then scan all known disks looking for disk groups to
import, and will import those disk groups. This will also set up the /dev/vx/dsk
and /dev/vx/rdsk directories to define all of the accessible Volume Manager
devices. If the volboot file cannot be read or if the rootdg disk group cannot be
imported, vxconfigd will be started in disabled mode.
- Start in disabled mode. This creates a rendezvous file for utilities that perform various
diagnostic or initialization operations. This can be used with the -rreset option
as part of a command sequence to completely reinitialize the Volume Manager
configuration. Use the vxdctlenable operation to enable vxconfigd.
- Handle boot-time startup of the Volume Manager. This starts the rootdg disk group and
the root file system volume. This mode is capable of operating before
the root file system is remounted to read-write. vxdctlenable should be called
later in the boot sequence to trigger vxconfigd to rebuild the /dev/vx/dsk and /
- -x debug
- Turn on various parameters used for debugging or other miscellaneous aspects of vxconfigd
operation. The debug option argument is a decimal number, which will set a tracing output
level, or one of the following strings:
- timestamp or mstimestamp
- Attach a date and time-of-day timestamp to all messages written by vxconfigd onto the
console. If mstimestamp is used, then a millisecond value is also displayed,
allowing detailed timing of vxconfigd's operation.
- syslog or nosyslog
- These options are provided only on systems where vxconfigd is compiled with support for
the syslog() library calls
(see syslogd(ADM) and
vxconfigd can support
use of syslog() to log all of its regular console messages. This support is either
available by default (in which case -xnosyslog is required to disable its use), or it
can support it as a run-time option (in which case -xsyslog can be used to enable
- For UnixWare, -xsyslog must be supplied (default) to vxconfigd to enable use of syslog().
The system can be changed to use this option at boot-time by editing the VxVM
- NOTE: If the syslog option is enabled, then all console output will be directed through the
syslog() interface. However, both syslog and log (described below) can be used
together to get reliable logging, into a private log file, along with distributed
logging through syslogd.
- log or nolog
- As an alternative to the use of syslog(), vxconfigd can directly log all of its console output
to a file. This logging is reliable, in that any messages which are output just before
a system crash will be available in the log file, presuming that the crash does not
result in file system corruption. vxconfigd can be compiled such that logging
defaults either to enabled or disabled. If it defaults to disabled, then it can be
turned on with -xlog; otherwise, it can be turned off with -xnolog.
- For UnixWare, logging is disabled by default. If enabled, the default log file location is /
- Specify an alternate location for the vxconfigd logfile. This option implies -xlog.
- This option causes the /var/vxvm/tempdb directory to be removed and recreated. This
directory stores configuration information that is cleared on reboots (or cleared for
specific disk groups on import and deport operations). If the contents of this
directory become corrupt, such as due to a disk I/O failure, then vxconfigd will
fail to start up if it is killed and restarted. Such a situation can be cleared by
starting vxconfigd with -xcleartempdir. This option has no effect if vxconfigd
is not started in enabled mode.
- NOTE: It is advisable to kill any running operational utilities (vxvol, vxsd, or vxmend)
before using the -xcleartempdir option. Failure to do so may cause those
commands to fail, or may cause disasterous but unchecked interactions between
those commands and the issuance of new commands. It is okay to use this option
while running the Visual Administrator (vxva), or while VxVM background
daemons are running (vxrelocd or vxnotify).
- This vxconfigd invocation will not communicate configuration changes to the kernel. It
is typically used as a demonstration mode of operation for vxconfigd. In most
aspects, a stubbed vxconfigd will act like a regular vxconfigd, except that disk
devices can be regular files and volume and plex device 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 Volume Manager utilities can detect when they are connected to a vxconfigd that is
running in stubbed mode. When a utility detects a stubbed-mode vxconfigd, it
will normally stub out any direct use of volume or plex devices, itself. This allows
regular utilities to be used for making configuration changes in a testing
environment that runs without any communication with the kernel or creation of
real volume or plex devices.
- Specify the pathname to use for the volboot file. This is primarily of use with the stub
debug option. The volboot file contains an initial list of disks that are used to
locate the root disk group. 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.
- Specify a directory pathname to prefix for any disk device accessed by vxconfigd. For
example, with devprefix=/tmp, any access to a raw disk device named
c2b0t1d0s0 would actually be directed to the file /tmp/dev/rdsk/c2b0t1d0s0. In
stubbed-mode, vxconfigd can operate with such files being regular files.
vxconfigd only requires entries in the prefixdir /dev/rdsk directory in stubbed
- Log all possible tracing information in the given file.
- Flush tracefile data to disk, with
to ensure that the last entry will be included in
the file, even if the system crashes.
- Normally, vxconfigd will automatically configure disk devices that can be found by
inspecting kernel disk drivers. These auto_configured disk devices are not stored
in persistent configurations, but are regenerated from kernel tables after every
reboot. Invoking vxconfigd with -xnoautoconfig prevents the automatic
configuration of disk devices, forcing the Volume Manager to use only those disk
devices configured explicitly using vxdisk define or vxdisk init.
- Specify the pathname to use for the vfstab file. Normally, /etc/vfstab is used.
- -D diag_portal
- Specify a rendezvous file pathname for diagnostic operation connections to vxconfigd. By default,
/etc/vx/vold_diag is used. The diagnostic portal exists in both the enabled and disabled
- -R request_portal
- Specify a rendezvous file pathname for regular configuration and query requests. By default, this is
/etc/vx/vold_request. The regular request portal exists only when vxconfigd is operating
in enabled mode.
If errors are encountered, vxconfigd writes diagnostic messages to the standard error output. Some serious errors will cause vxconfigd to exit. If an error is encountered when importing the rootdg disk group during a normal startup, vxconfigd will enter disabled mode. The error messages appendix of the VERITAS Volume Manager System Administrator Guide should be consulted for a description of the diagnostics and the suggested course of action.
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, then it
will exit with a zero status if vxdctlstop is used to cause vxconfigd to exit.
- 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 -rresest option was specified, but the Volume Manager kernel cannot be reset. Usually this
means that a volume is open or mounted.
- An interprocess communications failure (usually a STREAMS 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. For UnixWare, the early-
started volumes is the root file system, if it is defined on a volume.
- Directory containing block device nodes for volumes.
- Directory containing raw device nodes for volumes.
- File containing miscellaneous boot information (see
- Directory containing miscellaneous temporary files. Files in this directory are recreated after reboot.
Copyright © 2005 The SCO Group, Inc. All rights reserved.