<div dir="ltr"><br><div>Perhaps a more interesting error message would help a bit...</div><div><br></div><div>"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".</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 18, 2018 at 7:10 AM, Lou Berger <span dir="ltr"><<a href="mailto:lberger@labn.net" target="_blank">lberger@labn.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've hit the same issue too (in testing) a make uninstall target may be useful...<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 7/18/2018 10:06 AM, Philippe Guibert wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Donald,<br>
<br>
I faced the same issue, because I use both the topotest setup, and<br>
sometimes an already installed frr instance.<br>
To people that don't know, it is recommended to run topotest with some<br>
specific settings ( daemon binaries are in /usr/lib/frr, but vtysh is<br>
in /usr/bin/vtysh).<br>
<br>
I did not focus on a solution based on changing make settings. I copy<br>
manually vtysh if needed, or I use an other VM so that I use separate<br>
environments.<br>
<br>
Philippe<br>
<br>
On Wed, Jul 18, 2018 at 11:16 AM, Donald Sharp<br>
<<a href="mailto:sharpd@cumulusnetworks.com" target="_blank">sharpd@cumulusnetworks.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
All -<br>
<br>
Just wanted to document a little bit of a mis-config that I frequently<br>
self-inflict with and have just helped another person resolve.  When<br>
you run one of the daemons, or run vtysh and get this type of message:<br>
<br>
root@dev:~/frr# vtysh<br>
vtysh: Symbol `frr_vtydir' has different size in shared object,<br>
consider re-linking<br>
Exiting: failed to connect to any daemons.<br>
root@dev:~/frr#<br>
<br>
This means that you have managed to install FRR into 2 different<br>
locations.  How you say?  I've seen it from 2 different methodologies:<br>
<br>
1) I've run `./configure ..`, `make` and `make install` 2 times.  With<br>
the first and second configure line being different.  I am now fairly<br>
paranoid about this issue and double check my configure line.<br>
<br>
2) I've installed FRR from packaging (a .deb or .rpm ) and then run<br>
`./configure ....` line that installs FRR into a different spot.<br>
<br>
How to clean this mess up?<br>
<br>
In the undesired set of paths you need to clean up the FRR install,<br>
this includes the lib directories.  I do this with manual `find /path<br>
-name ... | xargs rm -rf`.  I'm sure someone more clever than myself<br>
knows how to do this with `make` but I have not experimented with<br>
this.<br>
<br>
donald<br>
<br>
______________________________<wbr>_________________<br>
dev mailing list<br>
<a href="mailto:dev@lists.frrouting.org" target="_blank">dev@lists.frrouting.org</a><br>
<a href="https://lists.frrouting.org/listinfo/dev" rel="noreferrer" target="_blank">https://lists.frrouting.org/li<wbr>stinfo/dev</a><br>
</blockquote>
______________________________<wbr>_________________<br>
dev mailing list<br>
<a href="mailto:dev@lists.frrouting.org" target="_blank">dev@lists.frrouting.org</a><br>
<a href="https://lists.frrouting.org/listinfo/dev" rel="noreferrer" target="_blank">https://lists.frrouting.org/li<wbr>stinfo/dev</a><br>
</blockquote>
<br>
<br>
______________________________<wbr>_________________<br>
dev mailing list<br>
<a href="mailto:dev@lists.frrouting.org" target="_blank">dev@lists.frrouting.org</a><br>
<a href="https://lists.frrouting.org/listinfo/dev" rel="noreferrer" target="_blank">https://lists.frrouting.org/li<wbr>stinfo/dev</a><br>
</div></div></blockquote></div><br></div>