Date: Thu, 26 Feb 2015 06:34:54 -0800 (PST) From: "Jeffrey Bouquet" <jbtakk@iherebuywisely.com> To: "freebsd-current" <freebsd-current@freebsd.org> Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" Message-ID: <E1YQzWg-0006m2-Ta@rmm6prod02.runbox.com> In-Reply-To: <2A8C0814-E644-4350-85B8-17B468D79BFF@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 25 Feb 2015 18:52:35 -0800, Garrett Cooper <yaneurabeya@gmail.com> = wrote: >=20 > > On Feb 25, 2015, at 18:08, Kevin Oberman <rkoberman@gmail.com> wrote: > >=20 > >> On Wed, Feb 25, 2015 at 2:30 PM, Garrett Cooper <yaneurabeya@gmail.com= > wrote: > >> On Feb 25, 2015, at 14:19, Miguel Clara <miguelmclara@gmail.com> wrote: > >>=20 > >> ... > >>=20 > >> > 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=3D275299= &r2=3D278704 > >> > > >> > Interesting, as I am using the most recent version which does not RE= QUIRE local_unbound > >> > > >> > I'm even more confused now :| > >> > > >> > > >> > So it has to come after SERVERS but before local_unbound. But NETWOR= KING depends on local_unbound they are both dependent on NEWORKING which ha= s to be after SERVERS. Can you say fubar! Clearly broken. And this means th= at removing SERVERS will re-shuffle the order more appropriately. > >> > > >> > It seems that the behavior of rcorder is not as documented as well a= s being undefined when circular dependencies occur. The man page says that = rcorder aborts when it encounters a circular dependency, but that is not th= e case. It probably is best that it not die, but that leaves things in an u= nknown and inconsistant state, which is also a very bad idea. I guess when = a circular dependency is encountered, a dichotomy occurs. > >>=20 > >> Now you know why I=E2=80=99m so curious about all of this stuff. > >>=20 > >> When I was working on ^/projects/building-blocks, I was able to move m= ost of these pieces around by changing REQUIRE: to BEFORE:, but I noticed t= hat it changes the rcorder a bit, so I haven=E2=80=99t been super gung ho i= n implementing my change. > >>=20 > >> I think there are a couple bugs present on 9-STABLE/10-STABLE/11-CURRE= NT: > >>=20 > >> - Things go awry if named is removed/not installed. > >> - Things go awry if local_unbound is removed (which would have been th= e case if the rc.d script was removed from your system, which existed befor= e my changes). > >> - Other rc.d scripts not being present might break assumptions. > >>=20 > >> I need to create dummy providers for certain logical stages (DNS is on= e of them) to solve part of this problem and provide third parties with a m= echanism that can be depended on (I wish applications were written in a mor= e robust manner to fail gracefully and retry instead of failing flat on the= ir face, but as I=E2=80=99ve seen at several jobs, getting developers to fa= il, then retry is hard :(=E2=80=A6). > >>=20 > >> Another short-term hack: > >>=20 > >> Install dummy/no-op providers so the ordering is preserved, then remov= e the hacks after all of the bugs have been shaken out. > >>=20 > >> Thanks! > >=20 > > Garret,=20 > >=20 > > 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 s= imply ignored. > >=20 > > The real problem is that there is no defined rule for behavior in the e= vent of a circular dependency and any change to any decision point in the o= rdering process may change the way the ordering flips. That is why these th= ings 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 p= orts without their being touched or even re-installed. And the triggering c= hange my, itself be correct. >=20 > Or etc/rc.d/named... >=20 > PROVIDES: DNS >=20 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.= ..=20=20 uuidd_enable=3D"YES" (e2fsprogs* ) dbus_enable=3D"YES" (*dbus*)=20 beginning v9 OR v10 ( not recollecting enough...) and persisting thencefort= h. Maybe those two could also be similarly fixed to this thread's one Despite not being in use day-to-day... nor particularly relevant... install= ed only conventionally.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1YQzWg-0006m2-Ta>