From: Carlo Zancanaro <carlo@zancanaro.id.au>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: Improving Shepherd
Date: Tue, 06 Feb 2018 02:56:12 +1100 [thread overview]
Message-ID: <87d11jh1lv.fsf@zancanaro.id.au> (raw)
In-Reply-To: <871shzeg8m.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 5699 bytes --]
Hey Ludo,
On Mon, Feb 05 2018, Ludovic Courtès wrote:
>> 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.
>
> After replying to Alex’ message, I realized that we could just
> as well
> have a separate “guix service” or similar tool to take care of
> this?
>
> This needs more thought (and perhaps taking a look at systemd
> user
> sessions, which I’m not familiar with), but I think Alex’
> approach is a
> good starting point.
We were thinking it might work like this:
- services->package constructs a package which places a file in
the profile containing the necessary references
- pid 1 shepherd listens to elogind login/logout events, and
starts the services when necessary
Admittedly this isn't the nicest way for it to work, but it might
be a good starting point.
There were some discussions on the list a while ago about how to
have `guix environment` automatically start services, too, so I
wonder what overlap there could be there. Although maybe
environment services (in containers) have more in common with
system services than user services.
>> 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?
>
> 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?
I no longer use the daemonize function. My user shepherd runs "in
the foreground" (it's started when my X session starts), so it's
not that. Jelle fixed the problem I was having by delaying the
SIGCHLD handler registration until it's needed. It is still buggy
if a process is started before the daemonize command is given to
root service, though.
If you try running "emacs --daemon" with
"make-forkexec-constructor" (and #:pid-file, and put something in
your emacs config to make it write out the pid) you should be able
to reproduce what I am seeing. If you kill emacs (or if it
crashes) then shepherd continues to report that it is started and
running. When I look at htop's output I can also see that my emacs
process is not a child of my shepherd process.
I would like to add a --daemon/--daemonize command line argument
to shepherd instead of the current "send the root service a
daemonize message". I think the use cases of turning it into a
daemon later are limited, and it just gives you an additional way
of shooting yourself in the foot.
>> 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.)
I'm not going to put much time/effort into this until we have
fibers building on ARM. I think these changes are likely to break
shepherd's config API, too. In particular, with higher levels of
concurrency I want to move the mutable state out of <service>
objects.
> 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_thread.html>;
> I
> suspect it’s within reach.)
Failing that, could we have our signal handlers just convert the
signal to a message in our event loop? I have a very rudimentary
understanding of signal handling, but I assume we could have our
main event loop just reading things off of two channels: one of
signal events, one of fd events.
>> This would mean that Shepherd could decide the best way to
>> start/stop
>> services, including doing so in parallel if possible.
>
> Sounds good. That’s annoyed most of us already, so if you get
> that
> fixed, you’ll make a lot of people happy. :-)
I'll have a go at this in the next few weeks. I'll be travelling
until the end of February, so I'm not expecting much, but we'll
see!
Carlo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2018-02-05 15:56 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-29 21:14 Improving Shepherd Carlo Zancanaro
2018-01-29 22:27 ` Jelle Licht
2018-02-05 10:49 ` Carlo Zancanaro
2018-02-05 13:08 ` Ludovic Courtès
2018-02-05 15:56 ` Carlo Zancanaro [this message]
2018-02-09 13:26 ` Ludovic Courtès
2018-02-09 19:50 ` Carlo Zancanaro
2018-02-09 21:32 ` Christopher Lemmer Webber
2018-02-14 13:10 ` Ludovic Courtès
2018-02-15 13:55 ` Andy Wingo
2018-02-10 13:34 ` Jelle Licht
2018-02-14 13:25 ` Ludovic Courtès
2018-02-15 17:05 ` Jelle Licht
2018-02-15 19:04 ` Mark H Weaver
2018-02-05 16:00 ` Danny Milosavljevic
2018-02-05 16:41 ` Carlo Zancanaro
2018-02-09 13:22 ` Ludovic Courtès
2018-02-09 20:51 ` David Pirotte
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d11jh1lv.fsf@zancanaro.id.au \
--to=carlo@zancanaro.id.au \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.