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

[Jan Klötzke]

On Mon, Dec 16, 2019 at 04:53:32PM +1000, Alexander Zangerl wrote:
> 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.

:+1:

> >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.

I'll solve that too. It looks like an easy fix.

/Jan