Re: [GNUnet-developers] Impact of GNUNET_TEST_HOME

[Christian Grothoff]

On 01/16/2015 10:00 AM, DocMalloc wrote:
> On Fri, 2015-01-16 at 09:40 +0100, Christian Grothoff wrote:
>> Thus, services like core, transport or statistics that are "global" for
>> the entire peer, have a UNIXPATH like this:
>>
>>
>> [statistics]
>> UNIXPATH = $GNUNET_RUNTIME_DIR/gnunet-service-statistics.sock
>>
>> which does not depend on GNUNET_TEST_HOME -- it should got to /tmp and
>> "just work".   Also, testcases should never have to change those
>> defaults.  Now, given that this is always the same directory, there can
>> be problems when testcases don't clean up properly after themselves
>> (i.e. old service processes are left alive), and in particular we have
>> #3256 which may also be relevant in your case.
> 
> The issue is running tests or make check when gnunet is running on a
> system. In this case the tests will fail, atm e.g. in statistics and
> arm,
> with rather unintuitive error messages 
> Because the UNIX sockets are already in use ...
> 
> So I cannot run tests when a gnunet peer is running or what is the
> general idea? In this case we should detect gnunet running...

Yes, that is true (and maybe annoying), but so far I've always stopped
my running peer to run tests.

If you want to propose a fix that solve this, I would totally not mind
that.  However, it does seem to be a bit of a mess, especially when you
also consider port number conflicts in testcases below the 'testbed'
layer (as in, where you don't have testing/testbed take care of
adjusting the configuration to free TCP ports).

Trying to detect if GNUnet is running kind of falls in with #3256: if we
had some good logic to check if a UNIXPATH was a left-over or a running
peer, that would also be useful to fix #3256.

0xE29FC3CC.asc
Description: application/pgp-keys

signature.asc
Description: OpenPGP digital signature