vxconfigd(ADM)
vxconfigd - Volume Manager configuration daemon 
 Synopsis
vxconfigd [ -kfd ] [ -r reset ] [ -m mode ] [ -x debug ] [ -D diag_portal ] [ -R request_portal ] 
 Description
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. 
 Options 
- -k 
 -  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. 
 - -f 
 -  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 
completes. 
 - -d 
 -  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: 
- enable 
 - 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. 
 - disable 
 - 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. 
 - boot 
 -  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 /
dev/vx/rdsk directories. 
 
 - -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
syslog(S)).
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 
its use). 
- 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 
startup scripts. 
- 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 /
var/vxvm/vxconfigd.log. 
  - logfile=logfilename 
 - Specify an alternate location for the vxconfigd logfile.  This option implies -xlog. 
 - cleartempdir 
 - 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). 
  - stub 
 -  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. 
  - boot=volboot_path 
 - 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. 
 - devprefix=prefixdir 
 - 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 
mode. 
 - tracefile=file 
 - Log all possible tracing information in the given file. 
 - synctrace 
 - Flush tracefile data to disk, with 
fsync(S),
to ensure that the last entry will be included in 
the file, even if the system crashes. 
 - noautoconfig 
 - 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. 
 - vfstab=vfstabfile 
 - 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 
operating modes. 
 - -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. 
 
 Diagnostics
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: 
- 0 
 -  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. 
 - 1 
 -  The command line usage is incorrect. 
 - 2 
 -  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. 
 - 3 
 -  The -k option was specified, but the existing vxconfigd could not be killed. 
 - 4 
 -  A system error was encountered that vxconfigd cannot recover from. The specific operation that 
failed is printed on the standard error output. 
 - 5 
 -  The background vxconfigd process was killed by a signal before startup completed.  The specific 
signal is printed on the standard error output. 
 - 6 
 -  A serious inconsistency was found in the kernel, preventing sane operation.  This can also happen 
because of version mismatch between the kernel and vxconfigd. 
 - 7 
 -  The -rresest option was specified, but the Volume Manager kernel cannot be reset.  Usually this 
means that a volume is open or mounted. 
 - 8 
 -  An interprocess communications failure (usually a STREAMS failure).  Has made it impossible for 
vxconfigd to take requests from other utilities. 
 - 9 
 -  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. 
 
 Files
- /dev/vx/dsk 
 - Directory containing block device nodes for volumes. 
 - /dev/vx/rdsk 
 - Directory containing raw device nodes for volumes. 
 - /etc/vx/volboot 
 - File containing miscellaneous boot information (see 
vxdctl(ADM)).
 - /var/vxvm/tempdb 
 - Directory containing miscellaneous temporary files.  Files in this directory are recreated after reboot. 
 
 References
syslogd(ADM),
vxdctl(ADM),
vxintro(ADM),
vxmend(ADM),
vxnotify(ADM),
vxrelocd(ADM),
vxsd(ADM),
vxvol(ADM),
fsync(S),
syslog(S),
syslog.conf(4bsd)
Copyright © 2005 The SCO Group, Inc. All rights reserved.