From owner-freebsd-current@FreeBSD.ORG Thu Feb 26 14:55:28 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5CE0927B for ; Thu, 26 Feb 2015 14:55:28 +0000 (UTC) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DAED3F9 for ; Thu, 26 Feb 2015 14:55:27 +0000 (UTC) Received: from [10.9.9.241] (helo=rmm6prod02.runbox.com) by bars.runbox.com with esmtp (Exim 4.71) (envelope-from ) id 1YQzWg-0001lv-Tx for freebsd-current@freebsd.org; Thu, 26 Feb 2015 15:34:54 +0100 Received: from mail by rmm6prod02.runbox.com with local (Exim 4.76) (envelope-from ) id 1YQzWg-0006m2-Ta for freebsd-current@freebsd.org; Thu, 26 Feb 2015 15:34:54 +0100 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [Authenticated user (846156)] by runbox.com with http (RMM6); for ; Thu, 26 Feb 2015 14:34:54 GMT From: "Jeffrey Bouquet" Reply-To: jbtakk@iherebuywisely.com To: "freebsd-current" Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" Date: Thu, 26 Feb 2015 06:34:54 -0800 (PST) X-Mailer: RMM6 In-Reply-To: <2A8C0814-E644-4350-85B8-17B468D79BFF@gmail.com> Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 14:55:28 -0000 On Wed, 25 Feb 2015 18:52:35 -0800, Garrett Cooper = wrote: >=20 > > On Feb 25, 2015, at 18:08, Kevin Oberman wrote: > >=20 > >> On Wed, Feb 25, 2015 at 2:30 PM, Garrett Cooper wrote: > >> On Feb 25, 2015, at 14:19, Miguel Clara 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.