vold - Logical Storage Manager configuration daemon
/sbin/vold [-kfd] [-r reset] [-m mode] [-x debug] [-D
diag_portal] [-R request_portal]
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 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 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 operation. 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 messages 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 (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).
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 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 stubbedmode
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 /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. 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 booted.
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: 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. However, 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
failure (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).
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)
vold(8)
[ Back ] |
