From owner-freebsd-current@FreeBSD.ORG Thu Feb 26 02:52:41 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 48A2C134 for ; Thu, 26 Feb 2015 02:52:41 +0000 (UTC) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F3CDC9B6 for ; Thu, 26 Feb 2015 02:52:40 +0000 (UTC) Received: by pdbfp1 with SMTP id fp1so9512395pdb.5 for ; Wed, 25 Feb 2015 18:52:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=6LusFs6idnaZ3i3UNm7zCcaFUC8TAaPjNywSWUd4Ae0=; b=WuOpoN29fVaNF+D89HcQPr9Rrw20ji3K+ndpTnmWWIgidPJ9rUEWI9kjdxf3Tw9QxH r8KgpsDOOMFP2k29ZXZOSnWnZiMjS07kiYWsEWrgi4dy0WvrbqK8uRBWiz8utxlqrsLS 9HZefrJ83fA4+V6nothBu444LGowfJTmJKxtpq1Z3aBUklK4AmY/2Drr8v+deLG80AJB 6wEvMYUbnAp61zJzLx046aNuQSGJvjnqpsfgYqhEtNpOhcYUTod0jiI/88x161AR/KiD twh/79QeuFI8vBj9oW4Zo/UaaIp59s9/UEadKK4LD8WV1HIqRfXKlhJgZOql65vPSy10 rpdg== X-Received: by 10.70.90.80 with SMTP id bu16mr10982625pdb.88.1424919160421; Wed, 25 Feb 2015 18:52:40 -0800 (PST) Received: from [10.184.57.98] (mobile-166-171-123-224.mycingular.net. [166.171.123.224]) by mx.google.com with ESMTPSA id gi3sm42562967pbc.83.2015.02.25.18.52.39 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Feb 2015 18:52:39 -0800 (PST) References: <64AF7708-217B-4AC0-A47A-AD1B0BFF7EDC@gmail.com> <885DA4D0-9644-4F06-97C9-04EAD7B4958C@gmail.com> <98CF988A-D9DB-49AD-8CFF-3B438F892730@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Message-Id: <2A8C0814-E644-4350-85B8-17B468D79BFF@gmail.com> X-Mailer: iPhone Mail (12B466) From: Garrett Cooper Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" Date: Wed, 25 Feb 2015 18:52:35 -0800 To: Kevin Oberman Content-Type: text/plain; charset=cp932 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-current , Miguel Clara 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 02:52:41 -0000 > On Feb 25, 2015, at 18:08, Kevin Oberman wrote: >=20 >> On Wed, Feb 25, 2015 at 2:30 PM, Garrett Cooper w= rote: >> 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 "NE= TWORKING" 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 REQUI= RE local_unbound >> > >> > I'm even more confused now :| >> > >> > >> > So it has to come after SERVERS but before local_unbound. But NETWORKIN= G 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 re= moving SERVERS will re-shuffle the order more appropriately. >> > >> > It seems that the behavior of rcorder is not as documented as well as b= eing undefined when circular dependencies occur. The man page says that rcor= der aborts when it encounters a circular dependency, but that is not the cas= e. 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 circu= lar dependency is encountered, a dichotomy occurs. >>=20 >> Now you know why I=81fm so curious about all of this stuff. >>=20 >> 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 i= t changes the rcorder a bit, so I haven=81ft been super gung ho in implement= ing my change. >>=20 >> I think there are a couple bugs present on 9-STABLE/10-STABLE/11-CURRENT:= >>=20 >> - Things go awry if named is removed/not installed. >> - Things go awry if local_unbound is removed (which would have been the c= ase 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. >>=20 >> I need to create dummy providers for certain logical stages (DNS is one o= f them) to solve part of this problem and provide third parties with a mecha= nism that can be depended on (I wish applications were written in a more rob= ust manner to fail gracefully and retry instead of failing flat on their fac= e, but as I=81fve seen at several jobs, getting developers to fail, then ret= ry is hard :(=81c). >>=20 >> Another short-term hack: >>=20 >> Install dummy/no-op providers so the ordering is preserved, then remove t= he 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 n= ot an error. This effectively makes a list of providers into an OR. So, for n= ame service the normal list is "named local_unbound unbound" and any will wo= rk for ordering and having none is a no-op, so if you don't run any nameserv= er (or kerberos or whatever provider), it is not an issue. As long as rcorde= r 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 RE= QUIRES or BEFORE lists no existing providers, the statement is simply ignore= d. >=20 > The real problem is that there is no defined rule for behavior in the even= t of a circular dependency and any change to any decision point in the order= ing process may change the way the ordering flips. That is why these things a= re such a royal pain to debug. A change in any rc.d script may cause the ord= ering of seemingly unrelated scripts to change, perhaps drastically, and the= error messages, while not misleading, is only a starting point in tracking t= his down. This means there may be time bombs that break working ports withou= t their being touched or even re-installed. And the triggering change my, it= self be correct. Or etc/rc.d/named... PROVIDES: DNS I'm going to post a fix up for this on arch@/rc@ because it needs to be solv= ed in a saner way -- especially for systems that are pedantic about rcorder,= like our version at $work.