-
Notifications
You must be signed in to change notification settings - Fork 187
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failing lua luv tests in build environments #539
Comments
This seems like it might be slightly more than just not having internet access. Those tests pass for me without internet access on Windows, but I haven't tested Linux yet. The IP used in the test that's failing is Could you try changing this line to use EDIT: Also worth noting that this test was ported from libuv's EDIT#2: On Linux, with no network access, I'm hitting this conditional and the test is being skipped (the ipv6 in the 'skipping' message is erroneous): Lines 180 to 184 in b85b9ef
|
One possible solution that would probably work would be to generalize this: Lines 246 to 256 in b85b9ef
to be able to test for both ipv4 and ipv6, and then skip the test if there is no ipv4/ipv6 external network interfaces found. |
I've tried using https://koji.fedoraproject.org/koji/taskinfo?taskID=66321473 |
Could you test the branch in #540 and let me know if that fixes it for you? |
This doesn't fix it: |
This is the network configuration of the build root:
|
Thanks for testing that out. Unfortunately I'm not familiar enough with this stuff to understand what could be happening or how to debug it. Strangely, I did notice that some of the other Libuv multicast tests actually do allow for But I'm not sure why that would be, or if there's a reason the Will need to look into this further. Some way to reproduce EDIT: Here's the PR that added the allowed
Much more cryptic than I'd like. 😞 |
Ok, I finally understand more about what's happening here. From the comment added in #541: EPERM here likely means that a firewall has denied the send, which can happen in some build/CI environments, e.g. the Fedora build system. Reproducible on Linux with iptables by doing:
and for ipv6:
|
#541 should fix this for you. Let us know if you run into any more problems. |
Now the test hanging:
https://koji.fedoraproject.org/koji/taskinfo?taskID=66526614 |
Hm, I wonder if the firewall is dropping the incoming packets in the IPv6 case, meaning that the send succeeds but the recv never gets any input...? If that's the case, I'm not quite sure how to deal with that. Is it possible to get the firewall settings for the build server? Or is there an easy way to reproduce the build server's environment locally? |
Confirmed that this behavior can happen if the firewall is dropping incoming ipv6 packets from outside localhost so I'm assuming that's what's going on, e.g.
I'm not sure what do here, since altering the test to be skipped in this scenario feels a bit too special-case-y to me, or, at least, any workaround that I can think of would obscure real failures (a timeout before skipping, etc). Any suggestions @cryptomilk? |
Hi, |
@dibyendumajumdar would you be willing to build Libuv and its tests and then try running:
and
I'm curious if this is specific to EDIT: Finally got a Fedora VM setup and am able to reproduce the hang (ipv4 udp multicast test is hanging for me). Will be able to better investigate this myself now. EDIT#2: The
|
Ok, the
I think we have to treat this as a real failure, though, so the best fix I can think to do would be to add a timeout to the test and then fail the test if it times out. Any input is welcome; I'm not familiar enough with this stuff to know what all the options are here. |
This is one way to close luvit#539. With the default settings of firewalld (used by Fedora, RHEL, etc), incoming messages from multicast IPs are dropped, meaning that the multicast test will hang forever. This introduces a 1 second timeout, after which the test will fail.
Hi @squeek502 I tried building libuv and running the test you mention.
So the libuv test times out rather than hanging. |
This is one way to close #539. With the default settings of firewalld (used by Fedora, RHEL, etc), incoming messages from multicast IPs are dropped, meaning that the multicast test will hang forever. This introduces a 1 second timeout, after which the test will fail.
Hi,
test in tests/test-udp.lua seems to fail in build environments with EPERM with limited network. The fedora build hosts don't have internet access, so don't have any network configuration. Thus luv tests are failing.
See e.g.
https://kojipkgs.fedoraproject.org//work/tasks/949/66240949/build.log
I would comment them out for now.
Maybe https://cwrap.org/socket_wrapper.html would help to improve network testing :-)
The text was updated successfully, but these errors were encountered: