On Thu, 2016-05-12 at 02:13 -0400, Daniel Kahn Gillmor wrote: > This is now handled by having the following line in the Unit section > of > /lib/systemd/system/sks.service: > > After=local-fs.target network.target
I've had seen that, but as I wrote in my mail before, it may actually
not even be required (and my original request would thus be wrong).
Perhaps these targets are already implied much earlier, or at least by
multi-user.target... then we could argue, that if any user hooks in
sks.service to some earlier target he probably knows what he's doing.
>
> >
> > 2) Right now sks.service wants sks-recon.service, but shouldn't
> > it be vice versa?
> > AFAIU, sks (i.e. sks db) can in principle run without sks-recon
> > which just means no further reconciliation would take place.
> > But sks-recon cannot run without sks db, which is also why
> > the dependency should be vice versa, actually Wants isn't
> > probably enough, and Requires would be appropriate.
> > After/Before is however okay, AFAIU, as db should run before
> > recon.
> I thought about this approach (and even tried it at one point) and i
> think the logic i ended up going with is the right logic. let me
> explain why:
>
> * administrators want to "run sks", so the most sensible thing for
> them to control is the "sks" service.
That's why my advice would have been to have three services:
sks.service => simply starts/stops/restarts both and is to be used for admins
sks-hkp.service => for sks db
sks-recon.service => for sks recon, likely with a After=sks-hkp.service, and a
Wants=sks-hkp.servce
simply because sks-recon.service "needs" hkp to work, but
won't crash, without it
> * the main part of the service (the thing without which nothing
> else
> can function) is "sks db". So this should be stopped or started
> when the admin does "systemctl start sks" or "systemctl stop sks"
>
> * when the main sks db process is running, it *also* wants to have
> the
> recon process up and running, so that it will stay in sync with
> the
> network.
Well, this is probably true for the majority of all cases, I agree, but
there could be special use-cases where one doesn't want/need to have
recon running.
Consider e.g. I non-public SKS netowrk (or even just a single service),
with only the company keys) => no need for recon
Or one could think of a server that doesn't do recon but gets his
"updates" in form of regular key dumps from another server.
> But if the recon process goes down, there's no need to
> tear down the db process. This is expressed by having
> sks.service
> "Wants=sks-recon.service"
Uhm... I found that a bit strange... if sks.service = sks DB, than it
shouldn't need in principle recon, and having it vice versa, i.e. sks-
recon.service wanting a DB service seems more natural.
> * on the flip side, if the db process goes down, we should
> terminate
> the recon process, and recon shouldn't be started unless db is
> already up. These constraints are expressed in sks-recon.service
> as:
>
> BindsTo=sks.service
> After=sks.service
>
> Make sense?
Well I have't said that it doesn't work... it just felt a bit unnatural
to me, i.e. not so much directly expressing the actual service
dependencies but doing it rather indirectly.
It probably makes only a difference if you really say, that there's one
sks.service which is conceptually identical to both, running DB and sks
at all (i.e. db and recon).
> > 3) I think sks.service should become sks-db.service (or perhaps
> > sks-hkp.serivce, which makes it more clear to people what it
> > actually does, namely providing the actual HKP protocol).
> > Additionally there could be a sks.service, which Wants the
> > two single services (sks-hkp and sks-recon) and also stops
> > both (when stopped).
> I find the approach with three .service files more confusing than it
> needs to be. There's the SKS daemon (sks.service) and the
> reconciliation server (sks-recon.service). Given that we can already
> express their interdependencies, i don't see what advantage a third
> .service would give us.
Well right now, AFAIU, I cannot just start DB, can I?
If one says systemctl start sks it will run db and because of
the Wants=sks-recon.service, it will also start recon.
> I'd love to have someone step up to take care of the sysvinit
> scripts.
> There are quite a few reports in the BTS (e.g. those about
> weird/spurious output) that are related to sysvinit, which i'm not
> sure
> how to handle. I'm much more inclined to work with an initsystem
> like
> systemd by default enforces clean process environments, sensible
> filedescriptor inheritance, explicit dependencies between services,
> etc.
Well I'd probably also say one should rather concentrate on systemd,...
especially perhaps also employing some more confinement (e.g. sks
shouldn't need access to /home).
Cheers,
Chris.
smime.p7s
Description: S/MIME cryptographic signature
