On Thu 2016-05-12 09:00:30 -0400, Christoph Anton Mitterer wrote: > 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).
sks definitely needs access to the local filesystem (/var/lib/sks) and
to the network (it listens on ports on its own).
> 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.
users who do that can override the .service file with one of their own
as well.
> 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
This doesn't make any sense in some of the corner cases. what happens
if i do:
systemctl start sks.service
systemctl stop sks-recon.service
what is the outcome now of:
systemctl status sks.service
?
One .service file per actually running service makes a lot more sense.
> 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.
and an admin of that system can easily prohibit sks-recon from launching
with:
systemctl mask sks-recon.service
or its equivalent:
ln -s /dev/null /etc/systemd/system/sks-recon.service
The rest of the system should operate as normal.
>> 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.
sks-db in normal operation *does* want recon -- so that it can provide
up-to-date keys to people who query it. But it dosn't need it.
"sks recon" does explicitly depend on "sks db" because of the
"BindsTo=sks.service" directive in sks-recon.service.
> 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.
If you don't want to run recon at all, you should mask
sks-recon.service, as described above.
> 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).
There's lots more that could be done to improve the systemd situation,
including upstream work on socket activation. Frankly, if i could drop
the sysvinit scripts without upsetting people, i'd be happy to do so.
If someone wants to step up to maintain the sysvinit scripts, that would
be really great.
Regards,
--dkg
signature.asc
Description: PGP signature
