Hi Daniel. I've seen commit eff25289e1244ac74ecae5a1a1c04113e052a27c ...
On Sun, 2016-05-08 at 23:14 +0200, 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? Is the After= really enough? Cause that controls only the order, not what's pulled in... Perhaps one should ask the systemd guys what's actually intended here... perhaps services shouldn't require these targets and things are handled by the target that pulls in sks.service (e.g. multi- user.target) already assuring that local-fs and network is there. So maybe my point (1) was wrong, and one shuldn't include those. What about the following? You closed the bug without commenting on these: > 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. > 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). > > As for the sysvinit style initscripts > 4) The same splitting into two services (db/hkp and recon) > should happen for /etc/init.d/sks Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
