Hi! raingloom <raingl...@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’.
