RFD: Rework/extending functionality of mdev

Laurent Bercot ska-dietlibc at skarnet.org
Fri Mar 13 22:33:15 UTC 2015


On 11/03/2015 08:45, Natanael Copa wrote:
> The netlink listener daemon will need to deal with the event handler (or
> parser as you call it) dying. I mean, the handler (the parser) could
> get some error, out of memory, someone broke mdev.conf or anything that
> causes mdev to exit. If the child (the handler/parser) dies a new pipe
> needs to be created and the handler/parser needs to be re-forked.
>
> With that in mind, wouldn't it be better to have the timer code in the
> handler/parser? When there comes no new messages from pipe within a
> given time, the handler/parser just exists.

  I've thought about that a bit, to see if there really was value in
making the handler exit after a timeout. And it's a lot more complex
than it appears, because you then get respawner design issues, the
same that appear when you write a supervisor.

  What if the handler dies too fast and there are still events in the
queue ? Should you respawn the handler instantly ? That's exactly
the kind of load you're trying to avoid by having a (supposedly)
long-lived handler. Should you wait for a bit before respawning the
handler ? How long are you willing to delay your events ?

  It is necessary to ask these questions, and have the mechanisms in
place to handle that case - but the case should actually never happen:
it is an admin error to have the event handler die to fast. So it's
code that should be there but should never be used; and it's already
there in the supervisor program that should monitor your netlink
listener.

  So my conclusion is that it's just not worth it to allow the event
handler to die. s6-uevent-listener considers that its child should be
long-lived; if it dies, s6-uevent-listener dies too with an error
message. It will be picked up by its supervisor (and the new instance
will also respawn the handler). I'm happy to trade a bit of swap
space for a significant decrease in the amount of required code.

-- 
  Laurent



More information about the busybox mailing list