[OT] long-lived spawners
Natanael Copa
ncopa at alpinelinux.org
Thu Mar 12 12:42:04 UTC 2015
On Thu, 12 Mar 2015 13:10:20 +0100
Denys Vlasenko <vda.linux at googlemail.com> wrote:
> On Wed, Mar 11, 2015 at 5:10 PM, Harald Becker <ralda at gmx.de> wrote:
> > On 11.03.2015 16:34, Laurent Bercot wrote:
> >>
> >> On 11/03/2015 14:02, Denys Vlasenko wrote:
> >>>
> >>> But that nldev process will exist for all time, right? That's not
> >>> elegant.
> >>> Ideally, this respawning logic should be in the kernel.
> >>
> > ...
> >>
> >> Needing daemons to answer notifications from userspace processes
> >> or the kernel is the Unix way. It's not Hurd's, it's not Plan 9's
> >> (AFAIK), but it's what we have, and it's not even that ugly. The
> >> listening and spawning logic will have to be somewhere anyway, so
> >> why not userspace ? Userspace memory is cheaper (because it can
> >> be swapped), userspace processes are safer, and processes are not
> >> a scarce resource.
> >
> > And what is wrong with a long lived daemon?
>
> I find it suboptimal to have, say, a hotplug daemon lingering
> in the system five hours after the last hotplug event happened.
What do you gain by moving that logic into the kernel?
My point is that a long lived daemon that stays there 5 hours after the
last hotplug event is currently unavoidable unless you are ok with one
fork/exec for every event. Thus, this long lived daemon should be as
small and simple as possible. The config parsing logic and actual
handling code should be done in different process.
Crazy idea:
have a netlink listener/handler that is installed
in /proc/sys/kernel/hotplug.
On startup it will set up a netlink listener and remove itself
from /proc/sys/kernel/hotplug so all subsequent events comes via
netlink.
Read events from netlink and handle those.
On timeout (no events for N seconds), restore itself
in /proc/sys/kernel/hotplug and exit.
I don't think this is possible to implement without race conditions so
I still believe a minimal forever running netlink listening daemon is
the way to go.
-nc
More information about the busybox
mailing list