Shared object "" not found, required by "dnscrypt-proxy"

Kevin Oberman rkoberman at
Sat Mar 21 04:59:35 UTC 2015

On Fri, Mar 20, 2015 at 7:14 PM, Miguel Clara <miguelmclara at>

> On Fri, Mar 20, 2015 at 7:01 PM, Kevin Oberman <rkoberman at>
> wrote:
>> On Fri, Mar 20, 2015 at 7:47 AM, Miguel Clara <miguelmclara at>
>> wrote:
>>> On Thu, Feb 26, 2015 at 2:52 AM, Garrett Cooper <yaneurabeya at>
>>> wrote:
>>>> On Feb 25, 2015, at 18:08, Kevin Oberman <rkoberman at> wrote:
>>>> On Wed, Feb 25, 2015 at 2:30 PM, Garrett Cooper <yaneurabeya at>
>>>> wrote:
>>>>> On Feb 25, 2015, at 14:19, Miguel Clara <miguelmclara at>
>>>>> 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:
>>>>> >
>>>>> >
>>>>> > 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
>>>>> - 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...
>>>> I'm going to post a fix up for this on arch@/rc@ because it needs to
>>>> be solved in a saner way -- especially for systems that are pedantic about
>>>> rcorder, like our version at $work.
>>> I re-sync my source and noticed the change while doing the mergemaster
>>> part... with this I can now change dnscrypt to:
>>> @@ -4,7 +4,7 @@
>>>  #
>>>  # PROVIDE: dnscrypt_proxy
>>>  # REQUIRE: SERVERS cleanvar
>>> -# BEFORE: named local_unbound unbound
>>> +# BEFORE: DNS
>>> And this makes the rcorder ok for dnscrypt-proxy
>> This is still broken and only works by random luck. At this time there
>> appears to be nothing providing DNS. At least the default
>> /etc/rc.d/local_unbound does not.nor does anything else in /etc/rc.d. It
>> looks like this change effectively removes all BEFORE constraints, so it
>> may start any time after SERVERS and cleanvar. But, it if really expects to
>> start before name service comes up, it's not going to happen as those start
>> before SERVERS. The effect is probably only that any DNS queries made prior
>> to it starting are not encrypted.
>> Since name service must start before SERVERS, I see no way to really
>> prevent this, but I think the port should be corrected and a message added
>> to warn that queries made while servers are starting may not be encrypted.
>> "rcorder /etc/rc.d/* /usr/src/etc/rc.d/* > /dev/null" should report the
>> lack of a provider for DNS.
> You're right about the order issue, still a lot to fix and indeed
> local_unbound doens't include the change so it seems that it works for me
> because I'm removing the need for local_unbound unbound or named, and one
> of those was probably introducing the issues.
> But I don't understand why this would affect encryption, unless
> local_unbound/unbound is not configured properly, if dnscrypt is stoped
> local_unbound can't forward the queries and so it won't work...
In my case local_unbound would forward to port 53... since that's
> not listening it will simply fail... so you don't really loose encryption
> it just fails... when dnscrypt start the queries start being forward and
> local_unbound does its job!
> This assumes ofc that the nameserver in resolv.conf is set to
> *only* (local_unbound/unbound).

Sorry. I don't use dnscrypt_proxy and misunderstood how it works. You are
Kevin Oberman, Network Engineer, Retired
E-mail: rkoberman at

More information about the freebsd-current mailing list