On Feb 25, 2015, at 14:19, Miguel Clara <miguelmcl...@gmail.com> wrote:
... > I noticed this too, but in that case why doesn't it affect all users? (or all > the ones using dnscrypt+local_unbound) maybe something changed in > "NETWORKING" recently? > > Hum: > https://svnweb.freebsd.org/base/head/etc/rc.d/NETWORKING?r1=275299&r2=278704 > > Interesting, as I am using the most recent version which does not REQUIRE > local_unbound > > I'm even more confused now :| > > > So it has to come after SERVERS but before local_unbound. But NETWORKING > depends on local_unbound they are both dependent on NEWORKING which has to be > after SERVERS. Can you say fubar! Clearly broken. And this means that > removing SERVERS will re-shuffle the order more appropriately. > > It seems that the behavior of rcorder is not as documented as well as being > undefined when circular dependencies occur. The man page says that rcorder > aborts when it encounters a circular dependency, but that is not the case. It > probably is best that it not die, but that leaves things in an unknown and > inconsistant state, which is also a very bad idea. I guess when a circular > dependency is encountered, a dichotomy occurs. Now you know why I’m so curious about all of this stuff. When I was working on ^/projects/building-blocks, I was able to move most of these pieces around by changing REQUIRE: to BEFORE:, but I noticed that it changes the rcorder a bit, so I haven’t been super gung ho in implementing my change. I think there are a couple bugs present on 9-STABLE/10-STABLE/11-CURRENT: - Things go awry if named is removed/not installed. - Things go awry if local_unbound is removed (which would have been the case if the rc.d script was removed from your system, which existed before my changes). - Other rc.d scripts not being present might break assumptions. I need to create dummy providers for certain logical stages (DNS is one of them) to solve part of this problem and provide third parties with a mechanism that can be depended on (I wish applications were written in a more robust manner to fail gracefully and retry instead of failing flat on their face, but as I’ve seen at several jobs, getting developers to fail, then retry is hard :(…). Another short-term hack: Install dummy/no-op providers so the ordering is preserved, then remove the hacks after all of the bugs have been shaken out. Thanks!
signature.asc
Description: Message signed with OpenPGP using GPGMail
