memcached-check error, Address already in use

[Kiran22222]

Hi,

When I execute magma-build, it was exected fine till memcached-check and it failed with below error.
when executed the failed command manually, its working fine.
If any one encounter similar error, please guide me how to resolve it and proceed further.
[root@magma memcached]# grep -i failed /root/magma-develop/lib/sources/memcached/test-suite.log
binary stat 1 of 54 tests failed
testapp.regression_binary_vs_block.block add [ failed ]
testapp.regression_binary_vs_block.binary add [ failed ]
Some test failed.
Failed 1
Failed 2
libtest/server.cc:345: in start() localhost:60596 Failed native ping(), pid: 7172 is alive: true waited: 17 server started. exec: /usr/bin/memcached -P /tmp/memcached.pidXeb8AK -p 60596 -U 60596 -u root -l 127.0.0.1 -m 128 -M stderr:failed to listen on TCP port 60596: Address already in use
[root@magma memcached]#

Regards
Kiran

[ladar]

@Kiran22222 I believe that is an issue with the bundled memcached. It doesn't destroy the server instances from pervious test cases, which keeps the port occupied, and when it tries to spawn a server instance for a new test case, it fails because the port is occupied.

You can try removing the OS memcached server package, so it uses the server bundled with the client library for (testing). You can try and diagnose why the server isn't exiting, and/or see if a newer there is a newer release/patch floating around that fixes this.

You can also run:

QUICK=yes dev/scripts/builders/build.lib.sh all

Which will build the shared magmad.so library without running the unit tests for each library.

[ladar]

@Kiran22222 I recently dug into a number of minor issues with the dependency checks. I think I've fixed the issues for curl/clam, but with memcached the problem can sometimes be your firewall.

If the invalid address libmemcached tries connecting to, so it can test UDP timeouts, will sometimes trigger an immediate invalid network destination response from a firewall, which will break the test as written. An interim fix is to simply drop packets to that destination.

For iptables:

sudo iptables -I OUTPUT -d 10.2.251.4 -j DROP

To make the change permanent:

sudo service iptables save

Or for firewalld systems:

sudo firewall-cmd --direct --add-rule ipv4 filter OUTPUT 0 -d 10.2.251.4/32 -j DROP

To make the change permanent:

sudo firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -d 10.2.251.4/32 -j DROP

I confirmed this fixes things when those are run on a host, and the tests are being run inside a VM. I haven't tried this fix yet on the system running the tests yet. But the iptable/firewall rule might not work, as the kernel will report network prohibited in those situations.