From owner-freebsd-current@FreeBSD.ORG Thu Feb 26 02:08:22 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D8ECC9F1 for ; Thu, 26 Feb 2015 02:08:22 +0000 (UTC) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (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 8C94E361 for ; Thu, 26 Feb 2015 02:08:22 +0000 (UTC) Received: by mail-ig0-f182.google.com with SMTP id h15so11129648igd.3 for ; Wed, 25 Feb 2015 18:08:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=a0TePGq2700qz+CvCkPTkXjlcKKqOgIMEliPsKgBkgc=; b=caqW2koXB6RfUtmEY7+dROYc1aDkTwdpi+yHYZSm85d5QB64wUwyZmCh7L7ydYcF4p JR2LyFGzVT7J09iGVKTMoaOUdczyXdQ2uosytmTMEtn4UfpP6B7ylCc2UqOwloHCQDYE qNRQtYgzLTLCSRDShcVLiAE9VmT6LkCMTl2hx8Bxmu/GZg1cHoR1v1Sp8xwmLk4WLC0W uZIyv/XqcVm/5Hh7vCOejfFWT092qbcRDUgFSxqryJoNUDQ5pBwT2b/J536nNtnozP5o EpSNu0ntD4I8/d3iVNyRhW2TVtIsGdqLxA4TCkKFc6f6y8dyOpII2sbux4r3dylrnyUG Dr5Q== MIME-Version: 1.0 X-Received: by 10.42.170.200 with SMTP id g8mr7275577icz.5.1424916501977; Wed, 25 Feb 2015 18:08:21 -0800 (PST) Sender: kob6558@gmail.com Received: by 10.107.174.86 with HTTP; Wed, 25 Feb 2015 18:08:21 -0800 (PST) In-Reply-To: <98CF988A-D9DB-49AD-8CFF-3B438F892730@gmail.com> References: <64AF7708-217B-4AC0-A47A-AD1B0BFF7EDC@gmail.com> <885DA4D0-9644-4F06-97C9-04EAD7B4958C@gmail.com> <98CF988A-D9DB-49AD-8CFF-3B438F892730@gmail.com> Date: Wed, 25 Feb 2015 18:08:21 -0800 X-Google-Sender-Auth: vaiKkwoH-2Jp3589op52bGiWBYk Message-ID: Subject: Re: Shared object "libsodium.so.13" not found, required by "dnscrypt-proxy" From: Kevin Oberman To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 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:08:22 -0000 On Wed, Feb 25, 2015 at 2:30 PM, Garrett Cooper wrote: > On Feb 25, 2015, at 14:19, Miguel Clara 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=3D275299&r2= =3D278704 > > > > 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 NETWORKIN= G > depends on local_unbound they are both dependent on NEWORKING which has t= o > 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 wh= en > a circular dependency is encountered, a dichotomy occurs. > > Now you know why I=E2=80=99m 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 tha= t > it changes the rcorder a bit, so I haven=E2=80=99t 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 befor= e > 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 o= f > 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 o= n > their face, but as I=E2=80=99ve seen at several jobs, getting developers = to fail, > then retry is hard :(=E2=80=A6). > > 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. -- Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com