mdev -d can (silently) die with "read: no buffer space available"

[Alexander Zangerl]

the mdev -d daemon mode introduced in 1.31.0 works pretty well on
my (systemd- and udev-less) box, but i've hit a few minor issues:

1. after a few days the mdev daemon tends to die.

this is on a laptop that suspends and resumes relatively frequently, and
there's a fair bit of uevent activity.

i've run mdev -df for a while and found that it eventually dies with
"read: no buffer space available", ie. in daemon_loop().

as far as i can tell the default 2kb buffer allocated for
reading from the netlink fd doesn't always suffice.
in my build i've upped this BUFFER_SIZE to 64kb, and haven't had any
mdev crashes since.

1. mdev in background daemon mode does die utterly silently.

even though i built busybox with CONFIG_FEATURE_SYSLOG=y
mdev doesn't set logmode so it seems that that remains set to
LOGMODE_STDIO but after bb_daemonize_or_rexec() both stdout and stderr
are dup'd to /dev/null.

i think that logmode = LOGMODE_SYSLOG; should be added after the
bb_daemonize_or_rexec call, or at least before the
bb_perror_msg_and_die() call in the daemon_loop().

2. /dev/mdev.log is ignored unless it exists before the daemon starts,
and is completely ignored for mdev actions related to initial_scan().

i think open_mdev_log() should be called in daemon_loop, not just
after initial_scan() and bb_daemonize_or_rexec().

that you can't create an mdev.log on demand, just before debugging
some uncooperative device makes debugging a bit harder than necessary;
it might also be good if the docs explicitly state the (reasonable) fact
that mdev -d reads mdev.conf only once at startup.

regards
az


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
Then I dream of a world where idiots are hunted like wild pigs. 
 -- Stephen Edwards
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital Signature
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20191214/86d4fc19/attachment.asc>