[dev] Multiple FRR installs and the damage done.

Donald Sharp sharpd at cumulusnetworks.com
Wed Jul 18 14:23:16 EDT 2018


I just realized that perhaps JR and myself were talking about two
slightly different issues.  I believe JR is also correct if I were to
run FRR 1 time and get it running and then come back later and startup
another instance FRR should be able to give good meaningful error
messages about what has gone wrong.

I have filed: https://github.com/FRRouting/frr/issues/2680 to address
this issue.

donald

On Wed, Jul 18, 2018 at 2:00 PM, Donald Sharp
<sharpd at cumulusnetworks.com> wrote:
> JR -
>
> Unfortunately this is a result of loading library for version Y, but
> running version Z.  I do not believe we have much choice of this
> failure mode.
>
> donald
>
> On Wed, Jul 18, 2018 at 11:36 AM, JR Rivers
> <jrrivers at cumulusnetworks.com> wrote:
>>
>> 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
>>
>>



More information about the dev mailing list