Re: unifying mcron and shepherd, service woes, improvements

[Ludovic Courtès]

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’.