[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Improving Shepherd
From: |
Carlo Zancanaro |
Subject: |
Re: Improving Shepherd |
Date: |
Mon, 05 Feb 2018 21:49:08 +1100 |
User-agent: |
mu4e 0.9.18; emacs 25.3.1 |
A few people came to join me on Friday to think about Shepherd.
Thanks Alex, Efraim, and Jelle.
We talked about a few different things that we'd like to achieve
with Shepherd. The most significant and achievable things were, I
think: user services, child process control, and
concurrency/parallelism.
User services - Alex has already sent a patch to the list to allow
generating user services from the Guix side. The idea is to
generate a Shepherd config file, allowing a user to invoke
shepherd manually to start their services. A further extension to
this would be to have something like systemd's "user sessions",
where the pid 1 Shepherd automatically starts a user's services
when they log in.
Child process control - this is my personal frustration, where
Shepherd loses track of processes that fork away (e.g. "emacs
--daemon"). I barely know anything about Linux process management,
but from my reading this can be solved through Linux namespaces
(if user namespaces are available). Could someone who knows more
about this let me know if that's a productive direction for me to
investigate? Or tell me a better way to go about it?
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 mentioned an idea to the guys on Friday about how Shepherd
should treat enabled/disabled services. I've thought about it some
more, and I think it might work. The general idea is that Shepherd
would always try to run an enabled service, and it would leave a
disabled service as-is (unless it's needed to start another
service). So it would kind of work like this:
- if stopped and enabled: try to start service
- if started and enabled: monitor, and restart service if it
fails
- if retrying too often: disable this service, and all which
depend on it
- else: only start if another enabled service depends on this one
This would mean that Shepherd could decide the best way to
start/stop services, including doing so in parallel if possible.
So, there are our ideas! Any thoughts, or words of wisdom?
Feedback is welcome.
Carlo
On Mon, Jan 29 2018, Carlo Zancanaro wrote:
I'm keen to do some work on shepherd. Partially this is driven
by
me using it to manage my user session and having it not always
work right, and partially this is driven by me grepping the code
for "FIXME" (which was slightly overwhelming). If anyone is keen
to chat about it on Friday, please find me! I have some ideas
about things I'd like to do, but I don't really have any idea
what
I'm doing. Any help/advice/encouragement you can give me will be
appreciated!
Carlo
signature.asc
Description: PGP signature
- Re: Improving Shepherd,
Carlo Zancanaro <=
- Re: Improving Shepherd, Ludovic Courtès, 2018/02/05
- Re: Improving Shepherd, Carlo Zancanaro, 2018/02/05
- Re: Improving Shepherd, Ludovic Courtès, 2018/02/09
- Re: Improving Shepherd, Carlo Zancanaro, 2018/02/09
- Re: Improving Shepherd, Christopher Lemmer Webber, 2018/02/09
- Re: Improving Shepherd, Ludovic Courtès, 2018/02/14
- Re: Improving Shepherd, Andy Wingo, 2018/02/15
Re: Improving Shepherd, Jelle Licht, 2018/02/10