> On Feb 25, 2015, at 18:08, Kevin Oberman <rkober...@gmail.com> wrote:
>> On Wed, Feb 25, 2015 at 2:30 PM, Garrett Cooper <yaneurab...@gmail.com> 
>> wrote:
>> 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!
> Garret, 
> Also undocumented (except in rcorder.c) is that the lack of a provider is not 
> an error. This effectively makes a list of providers into an OR. So, for name 
> service the normal list is "named local_unbound unbound" and any will work 
> for ordering and having none is a no-op, so if you don't run any nameserver 
> (or kerberos or whatever provider), it is not an issue. As long as rcorder 
> finds a provider, it will be used to set the order, but the lack of any or 
> all providers just means that the specified provider is ignored and if a 
> REQUIRES or BEFORE lists no existing providers, the statement is simply 
> ignored.
> The real problem is that there is no defined rule for behavior in the event 
> of a circular dependency and any change to any decision point in the ordering 
> process may change the way the ordering flips. That is why these things are 
> such a royal pain to debug. A change in any rc.d script may cause the 
> ordering of seemingly unrelated scripts to change, perhaps drastically, and 
> the error messages, while not misleading, is only a starting point in 
> tracking this down. This means there may be time bombs that break working 
> ports without their being touched or even re-installed. And the triggering 
> change my, itself be correct.

Or etc/rc.d/named...


I'm going to post a fix up for this on arch@/rc@ because it needs to be solved 
in a saner way -- especially for systems that are pedantic about rcorder, like 
our version at $work.

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to