On Wed, 25 Feb 2015 18:52:35 -0800, Garrett Cooper <yaneurab...@gmail.com> wrote:
> > > 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... > > PROVIDES: DNS > I don't know if this is adding not-relevancy to this thread or not... I've a long persistent "dbus-daemon*" "*uuid*" (names approximate, not saved during boot) two "start ..." failures during rc... despite reinstalling the ports and dependencies, particularly the .so. files mentioned (not included here... uuidd_enable="YES" (e2fsprogs* ) dbus_enable="YES" (*dbus*) beginning v9 OR v10 ( not recollecting enough...) and persisting thenceforth. Maybe those two could also be similarly fixed to this thread's one Despite not being in use day-to-day... nor particularly relevant... installed only conventionally. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
