The mdevd program
mdevd is a uevent manager. It connects to the netlink and reads
a series of uevents; for every uevent it reads, it performs
actions according to its configuration file. Actions can
be inserting a kernel module, creating or modifying device
entries in /dev, etc.
mdevd's configuration file uses the exact same
The differences between mdevd and mdev are:
- mdev needs to be registered as a hotplug manager and the
kernel spawns an instance of mdev per uevent; for every uevent,
mdev has to parse its configuration file. By contrast, mdevd is
a daemon: it's long-lived, and there is only one instance,
reading a series of uevents and
performing actions without forking; the configuration file is
read and parsed only once.
- Even though mdev can now be run as a daemon, via the -d
option, there are still technical advantages
to running mdevd over mdev.
mdevd [ -v verbosity ] [ -D notif ] [ -o outputfd ] [ -O nlgroups ] [ -b kbufsz ] [ -f conffile ] [ -n ] [ -s slashsys ] [ -d slashdev ] [ -F fwbase ] [ -C ]
- mdevd reads and parses its configuration file /etc/mdev.conf.
- It then connects to the netlink and reads from it, waiting for uevents.
- It exits 0 on a SIGTERM.
- 0: SIGTERM received, clean exit
- 1: received an invalid event
- 2: syntax error in the configuration file
- 100: wrong usage
- 111: system call failed
mdevd reacts to the following signals:
- SIGHUP: re-read the configuration file
- SIGTERM: exit as soon as possible
- -v verbosity : be more or less verbose.
Default verbosity is 1. 0 will only print fatal error messages, 3 or more
is seriously verbose debugging.
- -D notif : when ready
(actually listening to the netlink),
write a newline to file descriptor notif then close it.
This allows mdevd to use the
s6 mechanism to notify
readiness. notif cannot be lesser than 3.
If this option is not given, no readiness notification is sent.
- -o outputfd : send a copy of the complete
uevent, with possible new fields, to file descriptor outputfd,
after mdevd has handled them. (This can serve as a
synchronization mechanism with an external program that needs a device to
have been properly configured by the device manager before acting on the
The uevent is sent with the kernel format: fields are separated by a null
character. The uevent is terminated by an additional null character.
outputfd cannot be lesser than 3 and cannot be the same as notif.
If for any reason, at any point, mdevd fails to write to outputfd,
it stops writing, until it is restarted. (This is to preserve mdevd's memory
stability guarantee.) By default, the uevents are not written anywhere.
- -O nlgroups : after mdevd has handled the
uevents, rebroadcast them to the netlink groups identified by the mask
nlgroups. Bit 0 of nlgroups is always ignored (because
netlink group 1 is the one used by the kernel to send the original uevents and
that mdevd listens to, and we don't want to loopback on it).
- -b kbufsz : try and reserve a kernel buffer of
kbufsz bytes for the netlink queue. Too large a buffer wastes kernel memory;
too small a buffer risks losing events. The default is 500 kB, which should be
enough for most systems; if you're getting "No buffer space available" errors
from mdevd at coldplug time, try increasing this number.
- -n : dry run. mdevd will not create or delete
device nodes, and it will not spawn commands. Instead, it will print to stdout
the actions it would have performed.
- -f conffile : read the configuration
file from conffile. Default is /etc/mdev.conf.
conffile must be an absolute path.
- -s slashsys : assume the sysfs
pseudo-filesystem is mounted on slashsys. Default is /sys.
slashsys must be an absolute path.
- -d slashdev : assume the device nodes
are to be found in slashdev. Default is /dev.
slashdev must be an absolute path.
- -F fwbase : assume the firmware files, if any,
are to be found in fwbase. Default is /lib/firmware.
fwbase must be an absolute path.
- -C : after initialization (when mdevd is ready), invoke
mdevd-coldplug, so that a coldplug is
automatically performed when mdevd starts. This option should only be used
in situations where a drop-in replacement for mdev -d is needed, because
it has the drawback of performing a coldplug every time mdevd is started —
including when mdevd is killed and restarted. By default, mdevd does not perform
a coldplug when it starts, and it is up to the administrator to properly organize
their boot scripts to run mdevd-coldplug once,
at boot time, when mdevd is ready. The examples/s6-rc subdirectory of
the mdevd package shows a way to do this with the
s6-rc service manager.
mdevd uses mdev's configuration file format.
A good mdev.conf example is available
If mdevd cannot find its configuration file, it will use a simple, basic default
configuration where it can create device nodes as root or delete them, and does
A semantic difference with mdev is that a * directive will
be run on every action type, not just ACTION=add and
ACTION=remove. A & directive is in the same case (see
the paragraph below).
execline command support
In addition to the traditional shell command spawning via the @,
$ and * directives, mdevd also supports spawning a command
- +cmd : spawns execlineb -Pc cmd
when this line catches an event that has ACTION=add. This is the
equivalent of @cmd.
- -cmd : spawns execlineb -Pc cmd
when this line catches an event that has ACTION=remove. This is the
equivalent of $cmd.
- &cmd : spawns execlineb -Pc cmd
when this line catches an event no matter its action type (add,
remove, or anything else). This is the equivalent of *cmd.
Note that unlike /bin/sh, execlineb is spawned without an
absolute path, so in order for +, - and & to
work, the execlineb command must be available in mdevd's PATH.
- The examples/ subdirectory of the mdevd package contains
examples on how to run mdevd under various init systems / supervisors. These
examples do not show how to run mdevd as a logged service, because mdevd
should normally be run early in the system's boot up sequence, before
mounting the disks - so the presence of a mounted partition suitable for
logging is not guaranteed. In normal use, mdevd is quite terse, so it
runs smoothly without a dedicated logger, with its error messages
going to the catch-all logger.