From: rendaw <7e9wc56emjakcm@s.rendaw.me>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: help-guix@gnu.org
Subject: Re: Services and log management/monitoring
Date: Sat, 20 Apr 2019 00:47:27 +0900 [thread overview]
Message-ID: <bd98e3cc-e3fa-d2e2-f584-8c6cc35d8023@s.rendaw.me> (raw)
In-Reply-To: <87imvaci2p.fsf@gnu.org>
On 4/19/19 9:09 PM, Ludovic Courtès wrote:
> Hi,
>
> rendaw <7e9wc56emjakcm@s.rendaw.me> skribis:
>
>> I think fundamentally what I'd most like to know is when should I use a
>> Shepherd service vs a non-Shepherd service. Maybe it's as simple as: if
>> you don't have any specific requirements always define a Shepherd service.
> It’s hard to answer that question in the abstract. Do you have an
> example in mind that we could work through?
Yeah, so the basic example I was thinking of is I have an executable
binary (a server for diagnostics) I'd like to run when the computer boots.
>
>> Beyond what a service actually is though I have a few more questions:
>>
>> * Both
>> https://www.gnu.org/software/guix/manual/en/html_node/Service-Composition.html
>> and
>> https://www.gnu.org/software/guix/manual/en/html_node/Shepherd-Services.html#Shepherd-Services
>> appear to show a dependency graph.
> The first page shows a service extension graph.
>
> The second page shows a graph of dependencies among Shepherd services.
>
> These are two different beasts.
Ah okay, that explains a lot - I was completely misinterpreting the
extension graph then. I'm afraid I don't know what extension means in
this context. Is it similar to OOP extension, where a "Dog" is-a
"Canine"? Looking at the graphic, "accounts" depends-on "etc" (the
directory/mount?) makes a lot more sense to me than "accounts" is-a
"etc". Similarly I would assume that the udev service runs udevd, but
if upower and colord are both "udev" services (because they extend udev)
does that mean if I run both the upower and colord services then my
system will have 3 instances of udevd running?
I'm fairly sure that's not what it means, but if extends isn't an
inheritance relationship and it's not a dependency relationship I'm not
sure what it is.
Is the udev service in the shepherd graph different then the udev
service (-type?) in the service extension graph? That might be a factor
in my confusion.
>> Are the dependency graphs Shepherd and non-Shepherd services
>> entirely separate? Or maybe I'm completely misunderstanding
>> "extension" in this context. Can an inet service depend on a non-inet
>> service? Can an inet service depend on a d-bus service? * Is there a
>> way to hook into service events - that is, run some code when a
>> service starts or stops?
> An inetd service cannot “depend” on a non-inetd service; a D-Bus service
> cannot depend on a non-D-Bus service. Both D-Bus and inetd have their
> own notion of what a service is, how to start it, etc., which is
> separate from what the Shepherd does.
So suppose I have an mcron job that needs an ssh tunnel managed by
shepherd to be started, or an inetd handler that needs data files on a
network mount to run... is it possible to express those ordering
dependencies? Or a service that subscribes the server to external
webhooks, and needs the webhook listeners (inetd handlers) to be started
before registering.
I assume the answer to my 2nd question from the previous email - if
there's a way to run code when a service's state changes - is that there
currently isn't such hooking mechanism.
>
> I reckon that calling everything a “service” does not help understand
> all this…
I don't think it's an unreasonable choice of words :) - there's just a
lot that isn't fitting in mentally for me.
And thank you for your patience with the answers, I think I'm drawing
much closer to understanding all this. Once I've figured it out I'll
definitely write something up in case someone else has the same issues.
next prev parent reply other threads:[~2019-04-19 15:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-14 18:12 Services and log management/monitoring rendaw
2019-04-17 21:20 ` Ludovic Courtès
2019-04-18 15:11 ` rendaw
2019-04-19 12:09 ` Ludovic Courtès
2019-04-19 15:47 ` rendaw [this message]
2019-05-04 7:01 ` Chris Marusich
2019-05-04 8:01 ` rendaw
2019-05-04 8:24 ` Chris Marusich
2019-05-04 8:32 ` rendaw
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=bd98e3cc-e3fa-d2e2-f584-8c6cc35d8023@s.rendaw.me \
--to=7e9wc56emjakcm@s.rendaw.me \
--cc=help-guix@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.
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).