| ZED(8) | System Manager's Manual | ZED(8) |
ZED — ZFS Event
Daemon
ZED |
[-fFhILMvVZ] [-d
zedletdir] [-p
pidfile] [-P
path] [-s
statefile] [-j
jobs] [-b
buflen] |
The ZED (ZFS Event Daemon) monitors events
generated by the ZFS kernel module. When a zevent (ZFS Event) is posted, the
ZED will run any ZEDLETs (ZFS Event Daemon Linkage
for Executable Tasks) that have been enabled for the corresponding zevent
class.
-h-L-V-v-f-F-M-I-Z-d
zedletdir-p
pidfile-P
path$PATH for zedlets to use. Normally zedlets
run in a locked-down environment, with hardcoded paths to the ZFS commands
($ZFS, $ZPOOL,
$ZED, …), and a
hard-coded $PATH. This is done for security
reasons. However, the ZFS test suite uses a custom PATH for its ZFS
commands, and passes it to ZED with
-P. In short, -P is only
to be used by the ZFS test suite; never use it in production!-s
statefile-j
jobs-b
buflenA zevent is comprised of a list of nvpairs (name/value pairs). Each zevent contains an EID (Event IDentifier) that uniquely identifies it throughout the lifetime of the loaded ZFS kernel module; this EID is a monotonically increasing integer that resets to 1 each time the kernel module is loaded. Each zevent also contains a class string that identifies the type of event. For brevity, a subclass string is defined that omits the leading components of the class string. Additional nvpairs exist to provide event details.
The kernel maintains a list of recent zevents that can be viewed
(along with their associated lists of nvpairs) using the
zpool events
-v command.
ZEDLETs to be invoked in response to zevents are located in the enabled-zedlets directory (zedletdir). These can be symlinked or copied from the installed-zedlets directory; symlinks allow for automatic updates from the installed ZEDLETs, whereas copies preserve local modifications. As a security measure, since ownership change is a privileged operation, ZEDLETs must be owned by root. They must have execute permissions for the user, but they must not have write permissions for group or other. Dotfiles are ignored.
ZEDLETs are named after the zevent class for which they should be invoked. In particular, a ZEDLET will be invoked for a given zevent if either its class or subclass string is a prefix of its filename (and is followed by a non-alphabetic character). As a special case, the prefix all matches all zevents. Multiple ZEDLETs may be invoked for a given zevent.
ZEDLETs are executables invoked by the ZED in response to a given zevent. They should be written under the presumption they can be invoked concurrently, and they should use appropriate locking to access any shared resources. Common variables used by ZEDLETs can be stored in the default rc file which is sourced by scripts; these variables should be prefixed with ZED_.
The zevent nvpairs are passed to ZEDLETs as environment variables. Each nvpair name is converted to an environment variable in the following manner:
Some additional environment variables have been defined to present certain nvpair values in a more convenient form. An incomplete list of zevent environment variables is as follows:
Additionally, the following ZED & ZFS variables are defined:
ZEDLETs may need to call other ZFS commands. The installation paths of the following executables are defined as environment variables: ZDB, ZED, ZFS, ZINJECT, and ZPOOL. These variables may be overridden in the rc file.
The ZED requires root privileges.
Do not taunt the ZED.
ZEDLETs are unable to return state/status information to the kernel.
Internationalization support via gettext has not been added.
| May 26, 2021 | OpenZFS |