On 5/3/19 1:34 PM, Tim Düsterhus wrote:

Hello Tim,

Am 03.05.19 um 13:20 schrieb Frederic Lecaille:
About the test which fail, I would say that such errors are not
negligible :

     Starting frontend GLOBAL: cannot change UNIX socket ownership

I believe this is an issue with the long TMPDIR that I tried to mitigate
with this: https://github.com/haproxy/haproxy/blob/master/.travis.yml#L34

With your patch, vtest is able to create the LOG files at the same place $TMPDIR/<haproxy instance name> where the UNIX stats socket should be created. So this does not interfere with the test.

While debugging I noticed that the validation did not properly account
for the temporary extension of the filename during start-up, causing
HAProxy to accept the filename during the check, but fail to set it up.
This leads to the misleading error message.

Yes, perhaps he UNIX stats socket filename is too long (I have found 104 max length for sun_path on Max OS X, 108 on Linux).

So, I propose you revert your fix, and try to find another ways to set TMPDIR with a shorter value than the default one which is too long for UNIX sockets. At least this is the correct way to change the working directory for vtest.

For instance we have:


which is 94 bytes long. Should work only if we do not add an .<pid>.tmp extension bigger than 10 bytes. I guess this is not the case when the PID is big. Now I understand why some test may pass.

I have also noted that there is a missing closing bracket in this log line:

*** h1 0.0 debug|[ALERT] 122/093540 (23139) : Starting frontend GLOBAL: cannot change UNIX socket ownership [/var/folders/nz/vv4_9tw56nv9k3tkvyszvwg80000gn/T//regtest.zHu/

which is built like that:

    snprintf(errmsg, errlen, "%s [%s]", msg, path);

with 100 as errlen value: "cannot change UNIX socket ownership [/var/folders/nz/vv4_9tw56nv9k3tkvyszvwg80000gn/T//regtest.zHu/" is exactly a 100 bytes long string. So here the path for the UNIX socket is truncated in the log.

So let's try with a shorter TMPDIR variable please. This should fix the issue.

I did not get around to investigating this further and filing a bug
report, however.

Best regards
Tim Düsterhus

Reply via email to