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

Alexander Zangerl az+bb at snafu.priv.at
Mon Dec 16 06:53:32 UTC 2019


On Sun, 15 Dec 2019 22:15:21 +0100, Jan Klötzke writes:
>On Sun, Dec 15, 2019 at 08:44:14AM +1000, Alexander Zangerl wrote:
>> i only increased BUFFER_SIZE.
...
>This is strange. The read() call will always return a single event.

sorry - i spoke too early; my mdev with 64kb BUFFER_SIZE and 2mb RCVBUF
did die in the meantime, after one of my laptop's suspend-resume cycles.
upping BUFFER_SIZE is clearly not sufficient.

>OTOH udevd seems to use a whooping 128MiB for the netlink socket receive
>buffer. And the ENOBUFS error is exactly what should be returned if the
>receive buffer overflows.

i'll experiment with bigger RCVBUF sizes over the next week or so and
will report back then.

>Hmm, adding a stat() for each event that is processed does not seem
>right. In the normal case there will never be a mdev.log...

access("/dev/mdev.log",F_OK) would also work. i'm happy with any solution
that makes mdev easier to debug, i just saw the stat/access approach as the
least intrusive and smallest possible change.

>As a user that's what I would expect from a daemon: reload the
>configuration on SIGHUP and do a log-rotation on SIGUSR1. I think the
>patch won't be big to implement that.

if you do work on that sleeker setup with config rereading then you
might want to take a brief look at the line numbers logged by the mdev
daemon: right now it always says "rule matched, line -1" regardless of
what line (if any) does match.

cheers
az


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
Adam and Eve virus: Takes a couple of bytes out of your Apple.
-------------- 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/20191216/741976dd/attachment.asc>


More information about the busybox mailing list