[dev] Multiple FRR installs and the damage done.

JR Rivers jrrivers at cumulusnetworks.com
Wed Jul 18 11:36:20 EDT 2018


Perhaps a more interesting error message would help a bit...

"unable to connect to SOCKET, check to see if another instance of DAEMON is
running" or "another process NUMBER is listening to protocol (SOCKET)
NUMBER, check to see if another instance of DAEMON is running".



On Wed, Jul 18, 2018 at 7:10 AM, Lou Berger <lberger at labn.net> wrote:

> I've hit the same issue too (in testing) a make uninstall target may be
> useful...
>
>
>
> On 7/18/2018 10:06 AM, Philippe Guibert wrote:
>
>> Hi Donald,
>>
>> I faced the same issue, because I use both the topotest setup, and
>> sometimes an already installed frr instance.
>> To people that don't know, it is recommended to run topotest with some
>> specific settings ( daemon binaries are in /usr/lib/frr, but vtysh is
>> in /usr/bin/vtysh).
>>
>> I did not focus on a solution based on changing make settings. I copy
>> manually vtysh if needed, or I use an other VM so that I use separate
>> environments.
>>
>> Philippe
>>
>> On Wed, Jul 18, 2018 at 11:16 AM, Donald Sharp
>> <sharpd at cumulusnetworks.com> wrote:
>>
>>> All -
>>>
>>> Just wanted to document a little bit of a mis-config that I frequently
>>> self-inflict with and have just helped another person resolve.  When
>>> you run one of the daemons, or run vtysh and get this type of message:
>>>
>>> root at dev:~/frr# vtysh
>>> vtysh: Symbol `frr_vtydir' has different size in shared object,
>>> consider re-linking
>>> Exiting: failed to connect to any daemons.
>>> root at dev:~/frr#
>>>
>>> This means that you have managed to install FRR into 2 different
>>> locations.  How you say?  I've seen it from 2 different methodologies:
>>>
>>> 1) I've run `./configure ..`, `make` and `make install` 2 times.  With
>>> the first and second configure line being different.  I am now fairly
>>> paranoid about this issue and double check my configure line.
>>>
>>> 2) I've installed FRR from packaging (a .deb or .rpm ) and then run
>>> `./configure ....` line that installs FRR into a different spot.
>>>
>>> How to clean this mess up?
>>>
>>> In the undesired set of paths you need to clean up the FRR install,
>>> this includes the lib directories.  I do this with manual `find /path
>>> -name ... | xargs rm -rf`.  I'm sure someone more clever than myself
>>> knows how to do this with `make` but I have not experimented with
>>> this.
>>>
>>> donald
>>>
>>> _______________________________________________
>>> dev mailing list
>>> dev at lists.frrouting.org
>>> https://lists.frrouting.org/listinfo/dev
>>>
>> _______________________________________________
>> dev mailing list
>> dev at lists.frrouting.org
>> https://lists.frrouting.org/listinfo/dev
>>
>
>
> _______________________________________________
> dev mailing list
> dev at lists.frrouting.org
> https://lists.frrouting.org/listinfo/dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20180718/152d03f0/attachment.html>


More information about the dev mailing list