From: "Ludovic Courtès" <ludo@gnu.org>
To: raingloom <raingloom@riseup.net>
Cc: "guix-devel@gnu.org" <guix-devel@gnu.org>
Subject: Re: unifying mcron and shepherd, service woes, improvements
Date: Sat, 15 May 2021 18:59:52 +0200 [thread overview]
Message-ID: <87fsyohr07.fsf@gnu.org> (raw)
In-Reply-To: <20210515003937.3dbb4bb4@riseup.net> (raingloom@riseup.net's message of "Sat, 15 May 2021 00:39:37 +0200")
Hi!
raingloom <raingloom@riseup.net> skribis:
> Just throwing this out there:
> mcron is basically a very simple service manager, so, why not just move
> all its timer functionality into shepherd (like systemd's timer units)
> and then we can have a unified way to manage and debug services.
Yes, we could—see below.
> But also, shepherd debugging is kind of terrible too, at least on Guix,
> so we (and if no one else gets on it that probably means I) should do
> something about that.
> For example, it's pretty nontrivial to figure out how to run a
> service's command in isolation. So far I always had to find it in
> /proc, which is not great. stracing a service that fails to start is
> also rather tricky. The best I could come up with is to run strace in a
> loop and pgrep for the PIDs I'm interested in. Same goes for GDB, which
> was still bad in general last time I tried it.
I agree it’s kind of ugly. We could provide “actions” to display the
service’s command line, for instance, as in:
herd command openssh
The limitation right now is that the Shepherd’s API is procedural:
there’s ‘make-forkexec-constructor’, which returns a procedure that runs
a command. That “hides” the command from the <service> object. That’s
not hard to fix, though we’ll have to think hard about compatibility.
> Security could also be improved probably. Can we have an OCAP model?
> I feel like I don't know enough to say, so this mail is meant more as a
> conversation starter.
I think “having an ocap model” sounds nice but also vague. :-)
A concrete step we can take is follow the principle of least authority
(POLA) for more services. That was the spirit of
<https://guix.gnu.org/en/blog/2017/running-system-services-in-containers/>.
> So, can we do better? What other issues are there with Shepherd? Are
> they fundamental design problems or just plain old bugs?
>
> Or is everyone else happy with the current design and it's just me who
> can't use Shepherd properly? 😅
I think it’s fair to say it’s rough on the edges. :-)
One thing that’s on the to-do list is switching to a real event loop in
lieu of the current ad-hoc blocking design (this was discussed recently
on this mailing list). The switch to ‘signalfd’ in the last release in
a step in that direction. This will unlock “socket activation” and
possibly timers as you mentioned.
Thanks,
Ludo’.
next prev parent reply other threads:[~2021-05-15 17:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-14 22:39 unifying mcron and shepherd, service woes, improvements raingloom
2021-05-15 16:59 ` Ludovic Courtès [this message]
2021-05-16 18:17 ` raingloom
2021-05-16 20:47 ` Philip McGrath
2021-05-16 20:49 ` Xinglu Chen
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87fsyohr07.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guix-devel@gnu.org \
--cc=raingloom@riseup.net \
/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 public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).