listing for V
vold - Logical Storage Manager configuration daemon
/sbin/vold [-kfd] [-r reset] [-m mode] [-x debug] [-D diag_portal] [-R
-k Kills any vold process that is currently running before performing any
other startup processing. This is useful for recovering from a hung
vold process. Killing the old vold 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 Runs vold in the foreground. This is often useful when debugging vold,
or when tracing configuration changes.
Without this flag, vold forks a background daemon process and the
foreground process exits as soon as vold startup processing completes.
-d Starts vold in disabled mode. This flag is equivalent to -m disable.
Resets all Logical Storage 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.
Sets the initial operating mode for vold. Possible values for mode are:
Starts fully enabled (default). Uses the /etc/vol/volboot file to
bootstrap and load the rootdg disk group. vold then scans all
known disks looking for disk groups to import, and imports those
disk groups. vold also sets up the /dev/vol and /dev/rvol
directories to define all of the accessible Logical Storage Manager
devices. If the volboot file cannot be read or if the rootdg disk
group cannot be imported, vold will be started in disabled mode.
Starts in disabled mode. This creates a rendezvous file for
utilities that perform various diagnostic or initialization
operations. This option can be used with the -r reset option as
part of a command sequence to completely reinitialize the Logical
Storage Manager configuration. Use the voldctl enable command to
Handles boot-time startup of the Logical Storage Manager. This
starts the rootdg disk group and the root and /usr file system
volumes. This mode is capable of operating before the root file
system is remounted to read-write. The voldctl enable option should
be called later in the boot sequence to trigger vold to rebuild the
/dev/vol and /dev/rvol directories.
Turns on various parameters used for debugging or other miscellaneous
aspects of vold operation. The debug option argument is a decimal
number (0-9) which will set a tracing output level, or one of the
timestamp or mstimestamp
Attaches a date and time-of-day timestamp to all messages written
by vold onto the console. If mstimestamp is used, then a
millisecond value is also displayed, allowing detailed timing of
syslog or nosyslog
This option is not supported.
log or nolog
As an alternative to the use of syslog(), vold can directly log all
of its console output to a file. This logging is reliable, in that
any messages that 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.
For Tru64 UNIX, this support is disabled by default and can be
turned on with -x log. If enabled, the default log file location is
Specifies an alternate location for the vold logfile. This option
implies -x log.
This option causes the /etc/vol/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 vold will fail to
start up if it is killed and restarted. Such a situation can be
cleared by starting vold with -x cleartempdir. This option has no
effect if vold is not started in enabled mode.
It is advisable to kill any running operational utilities
(volume, volsd, or volmend) before using the -x cleartempdir
option. Failure to do so may cause those commands to fail, or
may cause disastrous but unchecked interactions between those
commands and the issuance of new commands. This option can be
used while running the Visual Administrator (dxlsm), or while
LSM background daemons are running (volnotify).
Stub mode is for internal use.
This vold invocation will not communicate configuration changes to
the kernel. It is typically used as a demonstration mode of
operation for vold. In most aspects, a stubbed vold will act like a
regular vold, except that disk devices can be regular files and
volume and plex device nodes are not created. A stubbed vold can
run concurrently with a regular vold, or concurrently with any
other stubbed vold processes, as long as different rendezvous,
volboot, and disk files are used for each concurrent process.
Other Logical Storage Manager utilities can detect when they are
connected to a vold that is running in stubbed mode. When a utility
detects a stubbed-mode vold, 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.
Specifies the pathname to use for the volboot file, which by
default is /etc/vol/volboot. This is primarily used with the stub
debug option. The volboot file might contain 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.
Specifies a directory pathname to prefix for any disk device
accessed by vold. For example, with devprefix=/tmp, any access to a
raw disk device named dsk2 would actually be directed to the file
/tmp/dev/rdisk/dsk2. In stubbed-mode, vold can operate with such
files being regular files. vold requires entries in the prefixdir
/dev/rdisk directory only in stubbed mode.
Logs all possible tracing information in the specified file.
Flushes tracefile data to disk, with fsync(2), to ensure that the
last entry will be included in the file even if the system crashes.
Normally, vold automatically configures 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 vold
with -x noautoconfig prevents the automatic configuration of disk
devices, forcing the Logical Storage Manager to use only those disk
devices listed in the /etc/vol/volboot file. Disks can be added to
this file with the voldctl add disk command. Also, one or more
disks containing rootdg configurations must be recorded in the
Specifies a rendezvous file pathname for diagnostic operation
connections to vold. By default, /etc/vol/vold_diag is used. The
diagnostic portal exists in both the enabled and disabled operating
modes. Primarily for internal use.
Specifies a rendezvous file pathname for regular configuration and
query requests. By default, this is /etc/vol/vold_request. The regular
request portal exists only when vold is operating in enabled mode.
Primarily for internal use.
The Logical Storage Manager configuration daemon, vold, is responsible for
maintaining configurations of disks and disk groups in the Logical Storage
Manager. The vold daemon takes requests from other utilities for
configuration changes, communicates those changes to the kernel, and
modifies configuration information stored on disk. The vold daemon is also
responsible for initializing the Logical Storage Manager when the system is
If errors are encountered, vold writes diagnostic messages to the standard
error output. Some serious errors will cause vold to exit. If an error is
encountered when importing the rootdg disk group during a normal startup,
vold will enter disabled mode. Refer to the Logical Storage Manager manual
for a description of the diagnostics and the suggested course of action.
Defined exit codes for vold are:
0 The requested startup mode completed successfully. This is returned if
-f is not used to start vold as a foreground process. If vold is
started as a foreground process, then it will exit with a zero status
if voldctl stop is used to cause vold to exit.
1 The command line usage is incorrect.
2 Enabled-mode operation was requested, but an error caused vold to enter
disabled mode instead. This is also returned for boot-mode operation
if startup failed. However, with boot-mode operation, the background
vold process exits as well.
3 The -k option was specified, but the existing vold could not be killed.
4 A system error was encountered that vold cannot recover from. The
specific operation that failed is printed on the standard error output.
5 The background vold 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 vold.
7 The -r reset option was specified, but the Logical Storage Manager
kernel cannot be reset. Usually this means that a volume is open or
8 An interprocess communications failure (usually a STREAMS failure) has
occurred, making it impossible for vold to take requests from other
9 Volumes that must be started early by vold could not be started. The
reasons, and possible recovery solutions, are printed to the standard
error output. For Tru64 UNIX, the only early-started volume is the
root file system (if defined on a volume).
Directory containing block device nodes for volumes.
Directory containing raw device nodes for volumes.
Default log file location for vold if logging is enabled.
File containing miscellaneous boot information. See voldctl(8) for more
information on this file.
Default portal for diagnostic connections to vold.
Directory containing miscellaneous temporary files. Files in this
directory are recreated after reboot.
syslog(3), syslogd(8), volintro(8), voldctl(8)
listing for V