vold(8)vold(8)NAMEvold - Logical Storage Manager configuration daemon
SYNOPSIS
/sbin/vold [-kfd] [-r reset] [-m mode] [-x debug] [-D diag_portal] [-R
request_portal]
OPTIONS
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. 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. Starts vold in disabled mode. This flag is equiva‐
lent to -m disable. Resets all Logical Storage Manager configu‐
ration information stored in the kernel as part of startup pro‐
cessing. This will fail if any volume or plex devices are cur‐
rently 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 accessi‐
ble 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 com‐
pletely reinitialize the Logical Storage Manager configuration.
Use the voldctl enable command to enable vold. 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 opera‐
tion. The debug option argument is a decimal number (0-9) which
will set a tracing output level, or one of the following
strings: Attaches a date and time-of-day timestamp to all mes‐
sages written by vold onto the console. If mstimestamp is used,
then a millisecond value is also displayed, allowing detailed
timing of vold's operation. This option is not supported. 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 /var/lsm/vold.log. 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.
Note
It is advisable to kill any running operational utilities (vol‐
ume, 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 run‐
ning the Visual Administrator (dxlsm), or while LSM background
daemons are running (volnotify).
Note
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 con‐
currently with any other stubbed vold processes, as long as dif‐
ferent 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. Speci‐
fies 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 /etc/vol/volboot file. 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. Primar‐
ily 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.
DESCRIPTION
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 booted.
EXIT CODES
If errors are encountered, vold writes diagnostic messages to the stan‐
dard error output. Some serious errors will cause vold to exit. If an
error is encountered when importing the rootdg disk group during a nor‐
mal startup, vold will enter disabled mode. Refer to the Logical Stor‐
age Manager manual for a description of the diagnostics and the sug‐
gested course of action.
Defined exit codes for vold are: 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. The command line usage is incorrect. 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. How‐
ever, with boot-mode operation, the background vold process exits as
well. The -k option was specified, but the existing vold could not be
killed. A system error was encountered that vold cannot recover from.
The specific operation that failed is printed on the standard error
output. The background vold 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 vold. The -r reset option was specified, but
the Logical Storage Manager kernel cannot be reset. Usually this means
that a volume is open or mounted. An interprocess communications fail‐
ure (usually a STREAMS failure) has occurred, making it impossible for
vold to take requests from other utilities. 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).
FILES
Directory containing block device nodes for volumes. Directory con‐
taining raw device nodes for volumes. Default log file location for
vold if logging is enabled. File containing miscellaneous boot infor‐
mation. See voldctl(8) for more information on this file. Default por‐
tal for diagnostic connections to vold. Directory containing miscella‐
neous temporary files. Files in this directory are recreated after
reboot.
SEE ALSOsyslog(3), syslogd(8), volintro(8), voldctl(8)vold(8)