Hi Christoph--
thanks for these thoughtful notes, and for your prompt testing of sks
1.1.5-5. 1.1.5-7 should address these concerns (and several others) but
i wanted to comment a little here too:
On Sun 2016-05-08 17:14:35 -0400, Christoph Anton Mitterer wrote:
> 1) Almost for sure, they miss quite some dependencies,
> at least things like network.target and perhaps
> something that makes sure the local fs is there?
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
> 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.
* 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. 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"
* 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?
> 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.
The admin can already start and stop both services with just:
systemctl start sks
systemctl stop sks
> As for the sysvinit style initscripts
> 4) The same splitting into two services (db/hkp and recon)
> should happen for /etc/init.d/sks
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.
sysvinit makes most of that much harder than it needs to be,
unfortunately, and two interrelated sysvinit scripts sounds even more
troubling than the one.
If you want to offer improvements to the sysvinit scripts (in a separate
bug report, ideally), i'm happy to review it, though i have fewer and
fewer servers like that to test things on.
all the best,
--dkg
