Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager

From: Olivier Brunel <jjk_at_jjacky.com>
Date: Mon, 8 Jan 2018 21:23:52 +0100

On Mon, 08 Jan 2018 19:31:17 +0000
"Laurent Bercot" <ska-skaware_at_skarnet.org> wrote:

> >But, it seems to me that when you're talking about this you expect
> >one to have two different instances of mdevd, one for netlinkd &
> >another one
> >for coldplug. That's not how I made things however: mdevd is a
> >longrun and I simply have both coldplug & netlinkd piped into it.
>
> That can work, but I think it's overly complex.

Well, I don't find it overly complex. It's just two services piped into
the same third one, nothing I find too complex. It's certainly not the
first time I would get different services piped into another common
one. (Even if I don't have helpers as in s6-rc, it's easy enough to do
as well.)


> One is long-lived, reading from mdevd-netlink, and can be logged ;
> if you want to both supervise it separately from mdevd-netlink and
> log its output, you need a supervision architecture that can pipeline
> more than two longruns. (I wonder where that can be found. ;))
> The other one is short-lived, reading from mdevd-coldplug which is a
> short-lived program. So you would just have a "mdevd-coldplug | mdevd"
> oneshot running after the mdevd-netlink pipeline has been launched.
> The second mdevd will simply die when the coldplug is over.

Right. I wasn't too worried about running two instances of mdevd at
once, it's just that I like it better when I have the one mdevd
service, and anything it has to say gets logged in the same place,
always, no matter the "source" of the event.

Otherwise it's either the log from mdevd, or coldplug, depending on the
source. But it's not a big deal. I'll see whether I keep things as I
have them, or make mdevd-coldplug piped into its own mdevd.


> >On another topic of sorts: so I start mdevd, netlinkd, and run
> >coldplug.
> >Cool. But what else would I need to do (upon boot) to ensure
> >everything has been processed correctly?
> >
> >By that I mean, currently if I don't do anything else, some things
> >aren't processed. For instance, my audio card isn't there, neither
> >are a few input devices, such as my (usb) mouse.
>
> Oh? In that case, I would say it's a bug in mdevd-coldplug, which is
> supposed to process everything. Do you have a pattern of stuff that
> isn't processed and should be?

Well, as I said I would always have my audio card & a few input devices
missing. It might be some modules that aren't loaded, and until
then the devices don't show up, hence mdevd-coldplug not finding
them under /sys/dev, but I don't know much else I'm afraid...


> Wow. That sounds very weird. What in your boot sequence could create
> such a huge burst of events? Can you strace mdevd-netlink to see
> what it's reading from the kernel, and tee its output to check whether
> those are legit events to be sent to mdevd or line noise that is
> improperly filtered at netlink registration time?

The only thing I can think of that would generate a burst of events is
my trigger-uevents script mentionned earlier, but I think I got that
error when it wasn't started on boot...

I'll see if I can strace mdevd-netlink when I get a chance and report
back.


Cheers,
Received on Mon Jan 08 2018 - 20:23:52 UTC