Alexey Serbin has posted comments on this change. ( http://gerrit.cloudera.org:8080/20514 )
Change subject: KUDU-3507 Fix mini ranger port detection ...................................................................... Patch Set 2: (2 comments) http://gerrit.cloudera.org:8080/#/c/20514/2//COMMIT_MSG Commit Message: http://gerrit.cloudera.org:8080/#/c/20514/2//COMMIT_MSG@10 PS2, Line 10: lsof might handle 0.0.0.0 as ipv6 > The message is very misleading. Originally I thought that the ip address is Thank you for taking time to write down those details. I didn't do all the steps in the recipe, but I just realized that it would be much simpler to instruct the JVM to use IPv4 instead when both IPv4 and IPv6 are available. BTW, similar approach is used for the HMS-related tests (see mini_hms.cc). Overall, the following small patch fixed the problem in my test environment: https://gerrit.cloudera.org/#/c/20582/ Could you apply it and see if it helps to address the issue in your test environment as well? If it helps, maybe you could accommodate that simpler approach in this patch? > This happened, because this is not the API port. Yes, indeed -- it seems that's the Tomcat's shutdown port. I think we should just disable it explicitly, so the process doesn't open that one since the test isn't using it anyway. http://gerrit.cloudera.org:8080/#/c/20514/2/src/kudu/util/test_util.cc File src/kudu/util/test_util.cc: http://gerrit.cloudera.org:8080/#/c/20514/2/src/kudu/util/test_util.cc@584 PS2, Line 584: // lsof exits with 1 even if there is no data: : // https://github.com/lsof-org/lsof/issues/128 : // (-Q option would solve it, but its only available on new systems : // like ubuntu 23.04) > Sorry, I am wrong on the "completely broken" part. If the <PID> is filtered OK, even if lsof returns 1 instead of 0 with empty output per the specified flags, I guess it's not 100% relevant to this issue of failing a particular test. At least I haven't seen a single failure of the test because of this peculiarity in lsof's behavior at the machines where the test scenario fails every time it runs. If you want to address the issue with that lsof behavior, could you please do so in a separate patch? Keeping semantically/logically separate matters in separate patches pays off later if trying to track down reasons why this or that change has been done in the code, and it helps in cherry-picking relevant patches in maintenance branches, if needed. Thanks! -- To view, visit http://gerrit.cloudera.org:8080/20514 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: kudu Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: I89c3409e9efd53a821a6d4244a35564e134323bb Gerrit-Change-Number: 20514 Gerrit-PatchSet: 2 Gerrit-Owner: Zoltan Martonka <[email protected]> Gerrit-Reviewer: Alexey Serbin <[email protected]> Gerrit-Reviewer: Kudu Jenkins (120) Gerrit-Reviewer: Zoltan Martonka <[email protected]> Gerrit-Comment-Date: Tue, 17 Oct 2023 00:05:15 +0000 Gerrit-HasComments: Yes
