Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager
On Mon, 08 Jan 2018 19:31:17 + "Laurent Bercot" 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,
Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager
On Mon, Jan 08, 2018 at 07:31:17PM +, Laurent Bercot wrote:
> > #!/usr/bin/execlineb -P
> > pipeline { find /sys -type f -name uevent -print0 }
> > forstdin -0 -p f importas -u f f redirfd -w 1 $f echo add
> The problem with your script is that it's getting a lot of
> duplicates, since multiple symlinks in /sys point to the same
> directory describing your device. I'm still hoping to avoid scanning
> the entirety of /sys, so I'd like to find a correct pattern, but if
> there's no other way, I'll just scan everything discarding symlinks.
>
'-type f' should only find regular files, not symlinks. I don't believe
it will even recurse into symlinks by default so deduplication shouldn't
be necessary.
--
Colin Booth
Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager
However, somewhat recently I believe I heard (read) you say on IRC that
the recommended way was actually the other way around, so I switched to
start netlinkd first, and then run coldplug.
Well, it's really up to you.
The thing is, if you coldplug first then listen to the netlink, you
have a window where events can appear and won't be picked up: the
netlink listener isn't up yet so the kernel is talking to the hand,
but the coldplugr has already scanned /sys and won't do it again,
so nobody will notice a device needs to be added.
Listening to the netlink first and then running the coldplug makes
sure there's no race condition where events will be ignored.
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.
If not, does that mean the recommended way is really to have two
instances of mdevd? Or is there another/better way I'm not seeing? I
like to have only a single mdevd, one longrun (logged) service, as (I
feel) it should be.
mdevd is not a long-lived process per se: it simply reads from its
stdin, and it dies when it reads EOF. Think "cat". The real long-lived
process is mdevd-netlink, which normally never dies, and never closes
its stdout, so an attached mdevd process would never die either.
So yes, it's okay to have - temporarily - two mdevd instances, that's
the design I had in mind.
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.
It's not a problem to have two mdevd instances running concurrently.
The worst that can happen is that an event arrives after mdevd-netlink
is running but before mdevd-coldplug has finished scanning /sys; in
that case, the event will be picked up twice, and depending on how
complex and duplicate-resistant the event handling is in mdev.conf,
shenanigans may happen. But:
- for the majority of devices, nothing special will happen; the
later instance will just fail to perform some action because the earlier
instance has already done it, it will log a warning and ignore the
event.
- this problem would also occur with a single mdevd instance; you
would simply send it the same event twice.
I don't think that corner case is worth worrying about. It is
unavoidable no matter the device manager you're using.
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?
#!/usr/bin/execlineb -P
pipeline { find /sys -type f -name uevent -print0 }
forstdin -0 -p f importas -u f f redirfd -w 1 $f echo add
This is the job of mdevd-coldplug you're duplicating, so yeah, if
you have to do that, then it's better to fix mdevd-coldplug. :)
The problem with your script is that it's getting a lot of
duplicates, since multiple symlinks in /sys point to the same
directory describing your device. I'm still hoping to avoid scanning
the entirety of /sys, so I'd like to find a correct pattern, but if
there's no other way, I'll just scan everything discarding symlinks.
Now I may be doing something wrong somewhere, but I've always had to
use
a larger buffer to make sure things worked correctly myself (That is,
even before w/ s6-uevent-listener).
I'm currently using 1 MB (1048576) to be sure, though it should work
with a smaller one, but I know that even with 131072 (so twice your
"large side" default) I'd always get the following error during boot:
mdevd-netlink: fatal: unable to receive netlink message: No buffer
space available
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?
--
Laurent
Re: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager
Hey there :)
So I've been using this (instead of your old uevent handler & busybox's
mdev) for a little while now, works great; Thanks!
I do have a few questions though. Originally what I had done was to
start mdevd, run mdevd-coldplug (referred to as coldplug thereafter),
and then start mdevd-netlink (referred to as netlinkd thereafter).
However, somewhat recently I believe I heard (read) you say on IRC that
the recommended way was actually the other way around, so I switched to
start netlinkd first, and then run coldplug.
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.
So for that to work with this new setup/order, I needed to have both do
atomic writes, to ensure things don't get mangled/mixed up. (Wasn't
needed before as I could simply make sure netlinkd only starts after
coldplug, the later being a oneshot.)
Things were good for netlinkd, but not coldplug. So I simply patched it
to flush its output after each uevent. (This being linux and pipe,
I believe atomic writes are ensured so long as we don't go over 4KB,
which I assume won't happen for a single uevent.)
But since that means coldplug now performs a few more write calls, I'm
guessing you might not be interrested in doing such a change upstream,
or am I mistaking?
If not, does that mean the recommended way is really to have two
instances of mdevd? Or is there another/better way I'm not seeing? I
like to have only a single mdevd, one longrun (logged) service, as (I
feel) it should be.
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.
So what I'm doing currently, is have a small trigger-uevents oneshot,
that does this:
#!/usr/bin/execlineb -P
pipeline { find /sys -type f -name uevent -print0 }
forstdin -0 -p f importas -u f f redirfd -w 1 $f echo add
It works, but I'm wondering whether this is the right thing to do, or if
there's a better/more correct way to get there?
Lastly, as a side note, on the doc for netlinkd, regarding the buffer
size, you say "The default is 65536 (which is on the large side)." (Same
as you did before for s6-uevent-listener I believe.)
Now I may be doing something wrong somewhere, but I've always had to use
a larger buffer to make sure things worked correctly myself (That is,
even before w/ s6-uevent-listener).
I'm currently using 1 MB (1048576) to be sure, though it should work
with a smaller one, but I know that even with 131072 (so twice your
"large side" default) I'd always get the following error during boot:
mdevd-netlink: fatal: unable to receive netlink message: No buffer
space available
Thanks!
