|
From: | Jelle Licht |
Subject: | Re: Improving Shepherd |
Date: | Sat, 10 Feb 2018 14:34:21 +0100 |
Hello!
[...]
Currently shepherd monitors SIGCHLD, and it’s not supposed to miss
those; in some cases it might handle them later than you’d expect, which
means that in the meantime you see a zombie process, but otherwise it
seems to work.
ISTR you reported an issue when using ‘shepherd --daemonize’, right?
Perhaps the issue is limited to that mode?
> Concurrency/parallelism - I think Jelle was planning to work on this,
> but I might be wrong about that. Maybe I volunteered? We're keen to
> see Shepherd starting services in parallel, where possible. This will
> require some changes to the way we start/stop services (because at the
> moment we just send a "start" signal to a single service to start it,
> which makes it hard to be parallel), and will require us to actually
> build some sort of real dependency resolution. Longer-term our goal
> should be to bring fibers into Shepherd, but Efraim mentioned that
> fibers doesn't compile on ARM at the moment, so we'll have to get that
> working first at least.
I’d really like to see that happen. I’ve become more familiar with
Fibers, and I think it’ll be perfect for the Shepherd (and we’ll fix the
ARM build issue, no doubt.)
One thing I’d like to do is to handle SIGCHLD via signalfd(2) instead of
an actual signal handler like we do now. That would make it easy to
have signal handling part of the main event loop and thus, it would
integrate well with Fibers.
It seems that signalfd(2) is Linux-only though, which is a bummer. The
solution might be to get over it and have it implemented on GNU/Hurd…
(I saw this discussion:
<https://www.gnu.org/software/hurd/glibc/signal/signal_ >; Ithread.html
suspect it’s within reach.)
[...]
Ludo’.
[Prev in Thread] | Current Thread | [Next in Thread] |