[Touch-packages] [Bug 1840633] Re: autopkgtests get stuck in Eoan with iptables 1.8.3
This bug was fixed in the package iptables - 1.8.3-2ubuntu2 --- iptables (1.8.3-2ubuntu2) eoan; urgency=medium * d/p/lp-1840633-nft-exit-in-case-we-can-t-fetch-current-genid.patch: avoid busy loop if cache can't be created (LP: #1840633) -- Christian Ehrhardt Wed, 21 Aug 2019 14:04:49 +0200 ** Changed in: iptables (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1840633 Title: autopkgtests get stuck in Eoan with iptables 1.8.3 Status in iptables package in Ubuntu: Fix Released Status in ufw package in Ubuntu: Invalid Bug description: Hi, it is time to report a bug to keep all info in one place. First of all ufw tests were broken with iptables 1.8.3 due to an ordering issue in the output. This I fixed and tested in [1]. It only adds one more "allowed result" to one of the tests, so it should be no big change. I double checked the upload to not (by any accident) change something else. $ debdiff ufw_0.36-1ubuntu1.dsc ufw_0.36-1ubuntu2.dsc | diffstat changelog |8 patches/0003-fix-test-iptables1.8.patch | 4151 patches/series |1 3 files changed, 4160 insertions(+) $ grep -e '---' -e '+++' ufw-0.36/debian/patches/0003-fix-test-iptables1.8.patch --- /dev/null +++ b/tests/root/valid/result.1.8 --- /dev/null +++ b/tests/root/valid6/result.1.8 => That seems safe to me. But since this hit Eoan the tests get stuck and hang what seems until aborted (we have seen up to 75h). A normal execution in the past was ~30 minutes. The modified test worked fine: http://paste.ubuntu.com/p/RKFvhTP8Ft/ But the test for ufw has multiple runs and I only fixed/modified/tested the "root-unitest". I'm running the full test now hoping it might reproduce locally for debugging. First I thought something else in Eoan changed now trigging this issue. But that is rather unlikely, as without the new iptables it works fine. So for now the working theory for now is that iptables 1.8.3 changed something else changed Formerly this was not seen as it failed on the bug I fixed before hitting the hang. But with the fix above applied it now triggers the hang. It always hangs at this tests: Test get_netfilter_capabilities() ERROR (CommandError): No server with a name or ID of '0eb6260d-c544-41eb-8cfa-baa9a745c528' nova show 0eb6260d-c544-41eb-8cfa-baa9a745c528 (adt-eoan-s390x-ufw-20190815-202934) The test uses no Nova, the last two lines is from the automation being aborted. What is interesting is that this test would be ran up to three times, and it sometimes succeeds one or two times now. So it might (in addition to be broken) also be flaky. [1]: https://code.launchpad.net/~paelzer/ubuntu/+source/ufw/+git/ufw/+merge/371391 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1840633/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1840633] Re: autopkgtests get stuck in Eoan with iptables 1.8.3
@Jamie - you are right and that is exactly the fix that I have up for review since a few hours in https://code.launchpad.net/~paelzer/ubuntu/+source/iptables/+git/iptables/+merge/371575 There are no "other cases needing a similar commit", I meant "this fix also helps other cases that ran into this blocking scenario". As soon as tests complete and someone acked he MP we can upload to Eoan as I agree this needs to be fixed. The current Infrastructure woes make all that a bit slower tan usual. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1840633 Title: autopkgtests get stuck in Eoan with iptables 1.8.3 Status in iptables package in Ubuntu: Confirmed Status in ufw package in Ubuntu: Invalid Bug description: Hi, it is time to report a bug to keep all info in one place. First of all ufw tests were broken with iptables 1.8.3 due to an ordering issue in the output. This I fixed and tested in [1]. It only adds one more "allowed result" to one of the tests, so it should be no big change. I double checked the upload to not (by any accident) change something else. $ debdiff ufw_0.36-1ubuntu1.dsc ufw_0.36-1ubuntu2.dsc | diffstat changelog |8 patches/0003-fix-test-iptables1.8.patch | 4151 patches/series |1 3 files changed, 4160 insertions(+) $ grep -e '---' -e '+++' ufw-0.36/debian/patches/0003-fix-test-iptables1.8.patch --- /dev/null +++ b/tests/root/valid/result.1.8 --- /dev/null +++ b/tests/root/valid6/result.1.8 => That seems safe to me. But since this hit Eoan the tests get stuck and hang what seems until aborted (we have seen up to 75h). A normal execution in the past was ~30 minutes. The modified test worked fine: http://paste.ubuntu.com/p/RKFvhTP8Ft/ But the test for ufw has multiple runs and I only fixed/modified/tested the "root-unitest". I'm running the full test now hoping it might reproduce locally for debugging. First I thought something else in Eoan changed now trigging this issue. But that is rather unlikely, as without the new iptables it works fine. So for now the working theory for now is that iptables 1.8.3 changed something else changed Formerly this was not seen as it failed on the bug I fixed before hitting the hang. But with the fix above applied it now triggers the hang. It always hangs at this tests: Test get_netfilter_capabilities() ERROR (CommandError): No server with a name or ID of '0eb6260d-c544-41eb-8cfa-baa9a745c528' nova show 0eb6260d-c544-41eb-8cfa-baa9a745c528 (adt-eoan-s390x-ufw-20190815-202934) The test uses no Nova, the last two lines is from the automation being aborted. What is interesting is that this test would be ran up to three times, and it sometimes succeeds one or two times now. So it might (in addition to be broken) also be flaky. [1]: https://code.launchpad.net/~paelzer/ubuntu/+source/ufw/+git/ufw/+merge/371391 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1840633/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1840633] Re: autopkgtests get stuck in Eoan with iptables 1.8.3
Review is done, just waiting for the tests to confirm to be ok. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1840633 Title: autopkgtests get stuck in Eoan with iptables 1.8.3 Status in iptables package in Ubuntu: Confirmed Status in ufw package in Ubuntu: Invalid Bug description: Hi, it is time to report a bug to keep all info in one place. First of all ufw tests were broken with iptables 1.8.3 due to an ordering issue in the output. This I fixed and tested in [1]. It only adds one more "allowed result" to one of the tests, so it should be no big change. I double checked the upload to not (by any accident) change something else. $ debdiff ufw_0.36-1ubuntu1.dsc ufw_0.36-1ubuntu2.dsc | diffstat changelog |8 patches/0003-fix-test-iptables1.8.patch | 4151 patches/series |1 3 files changed, 4160 insertions(+) $ grep -e '---' -e '+++' ufw-0.36/debian/patches/0003-fix-test-iptables1.8.patch --- /dev/null +++ b/tests/root/valid/result.1.8 --- /dev/null +++ b/tests/root/valid6/result.1.8 => That seems safe to me. But since this hit Eoan the tests get stuck and hang what seems until aborted (we have seen up to 75h). A normal execution in the past was ~30 minutes. The modified test worked fine: http://paste.ubuntu.com/p/RKFvhTP8Ft/ But the test for ufw has multiple runs and I only fixed/modified/tested the "root-unitest". I'm running the full test now hoping it might reproduce locally for debugging. First I thought something else in Eoan changed now trigging this issue. But that is rather unlikely, as without the new iptables it works fine. So for now the working theory for now is that iptables 1.8.3 changed something else changed Formerly this was not seen as it failed on the bug I fixed before hitting the hang. But with the fix above applied it now triggers the hang. It always hangs at this tests: Test get_netfilter_capabilities() ERROR (CommandError): No server with a name or ID of '0eb6260d-c544-41eb-8cfa-baa9a745c528' nova show 0eb6260d-c544-41eb-8cfa-baa9a745c528 (adt-eoan-s390x-ufw-20190815-202934) The test uses no Nova, the last two lines is from the automation being aborted. What is interesting is that this test would be ran up to three times, and it sometimes succeeds one or two times now. So it might (in addition to be broken) also be flaky. [1]: https://code.launchpad.net/~paelzer/ubuntu/+source/ufw/+git/ufw/+merge/371391 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1840633/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1840633] Re: autopkgtests get stuck in Eoan with iptables 1.8.3
Indeed, that is exactly what https://git.netfilter.org/iptables/commit/?id=e5cab728c40be88c541f68e4601d39178c36111f did. Are you saying there are other cases where a similar commit is needed? IMO, those should be patched before 1.8.3 goes into eoan. Unless I am missing something, iptables is correctly being blocked by the ufw autopkgtest and it should not migrate until these issues are fixed. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1840633 Title: autopkgtests get stuck in Eoan with iptables 1.8.3 Status in iptables package in Ubuntu: Confirmed Status in ufw package in Ubuntu: Invalid Bug description: Hi, it is time to report a bug to keep all info in one place. First of all ufw tests were broken with iptables 1.8.3 due to an ordering issue in the output. This I fixed and tested in [1]. It only adds one more "allowed result" to one of the tests, so it should be no big change. I double checked the upload to not (by any accident) change something else. $ debdiff ufw_0.36-1ubuntu1.dsc ufw_0.36-1ubuntu2.dsc | diffstat changelog |8 patches/0003-fix-test-iptables1.8.patch | 4151 patches/series |1 3 files changed, 4160 insertions(+) $ grep -e '---' -e '+++' ufw-0.36/debian/patches/0003-fix-test-iptables1.8.patch --- /dev/null +++ b/tests/root/valid/result.1.8 --- /dev/null +++ b/tests/root/valid6/result.1.8 => That seems safe to me. But since this hit Eoan the tests get stuck and hang what seems until aborted (we have seen up to 75h). A normal execution in the past was ~30 minutes. The modified test worked fine: http://paste.ubuntu.com/p/RKFvhTP8Ft/ But the test for ufw has multiple runs and I only fixed/modified/tested the "root-unitest". I'm running the full test now hoping it might reproduce locally for debugging. First I thought something else in Eoan changed now trigging this issue. But that is rather unlikely, as without the new iptables it works fine. So for now the working theory for now is that iptables 1.8.3 changed something else changed Formerly this was not seen as it failed on the bug I fixed before hitting the hang. But with the fix above applied it now triggers the hang. It always hangs at this tests: Test get_netfilter_capabilities() ERROR (CommandError): No server with a name or ID of '0eb6260d-c544-41eb-8cfa-baa9a745c528' nova show 0eb6260d-c544-41eb-8cfa-baa9a745c528 (adt-eoan-s390x-ufw-20190815-202934) The test uses no Nova, the last two lines is from the automation being aborted. What is interesting is that this test would be ran up to three times, and it sometimes succeeds one or two times now. So it might (in addition to be broken) also be flaky. [1]: https://code.launchpad.net/~paelzer/ubuntu/+source/ufw/+git/ufw/+merge/371391 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1840633/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1840633] Re: autopkgtests get stuck in Eoan with iptables 1.8.3
It seems like iptables going into a busy loop as non-root is also a bug that should be fixed? At the very least, iptables should bail prior to that condition saying that root is needed. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1840633 Title: autopkgtests get stuck in Eoan with iptables 1.8.3 Status in iptables package in Ubuntu: Confirmed Status in ufw package in Ubuntu: Invalid Bug description: Hi, it is time to report a bug to keep all info in one place. First of all ufw tests were broken with iptables 1.8.3 due to an ordering issue in the output. This I fixed and tested in [1]. It only adds one more "allowed result" to one of the tests, so it should be no big change. I double checked the upload to not (by any accident) change something else. $ debdiff ufw_0.36-1ubuntu1.dsc ufw_0.36-1ubuntu2.dsc | diffstat changelog |8 patches/0003-fix-test-iptables1.8.patch | 4151 patches/series |1 3 files changed, 4160 insertions(+) $ grep -e '---' -e '+++' ufw-0.36/debian/patches/0003-fix-test-iptables1.8.patch --- /dev/null +++ b/tests/root/valid/result.1.8 --- /dev/null +++ b/tests/root/valid6/result.1.8 => That seems safe to me. But since this hit Eoan the tests get stuck and hang what seems until aborted (we have seen up to 75h). A normal execution in the past was ~30 minutes. The modified test worked fine: http://paste.ubuntu.com/p/RKFvhTP8Ft/ But the test for ufw has multiple runs and I only fixed/modified/tested the "root-unitest". I'm running the full test now hoping it might reproduce locally for debugging. First I thought something else in Eoan changed now trigging this issue. But that is rather unlikely, as without the new iptables it works fine. So for now the working theory for now is that iptables 1.8.3 changed something else changed Formerly this was not seen as it failed on the bug I fixed before hitting the hang. But with the fix above applied it now triggers the hang. It always hangs at this tests: Test get_netfilter_capabilities() ERROR (CommandError): No server with a name or ID of '0eb6260d-c544-41eb-8cfa-baa9a745c528' nova show 0eb6260d-c544-41eb-8cfa-baa9a745c528 (adt-eoan-s390x-ufw-20190815-202934) The test uses no Nova, the last two lines is from the automation being aborted. What is interesting is that this test would be ran up to three times, and it sometimes succeeds one or two times now. So it might (in addition to be broken) also be flaky. [1]: https://code.launchpad.net/~paelzer/ubuntu/+source/ufw/+git/ufw/+merge/371391 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1840633/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1840633] Re: autopkgtests get stuck in Eoan with iptables 1.8.3
** Merge proposal linked: https://code.launchpad.net/~paelzer/ubuntu/+source/iptables/+git/iptables/+merge/371575 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1840633 Title: autopkgtests get stuck in Eoan with iptables 1.8.3 Status in iptables package in Ubuntu: Confirmed Status in ufw package in Ubuntu: Invalid Bug description: Hi, it is time to report a bug to keep all info in one place. First of all ufw tests were broken with iptables 1.8.3 due to an ordering issue in the output. This I fixed and tested in [1]. It only adds one more "allowed result" to one of the tests, so it should be no big change. I double checked the upload to not (by any accident) change something else. $ debdiff ufw_0.36-1ubuntu1.dsc ufw_0.36-1ubuntu2.dsc | diffstat changelog |8 patches/0003-fix-test-iptables1.8.patch | 4151 patches/series |1 3 files changed, 4160 insertions(+) $ grep -e '---' -e '+++' ufw-0.36/debian/patches/0003-fix-test-iptables1.8.patch --- /dev/null +++ b/tests/root/valid/result.1.8 --- /dev/null +++ b/tests/root/valid6/result.1.8 => That seems safe to me. But since this hit Eoan the tests get stuck and hang what seems until aborted (we have seen up to 75h). A normal execution in the past was ~30 minutes. The modified test worked fine: http://paste.ubuntu.com/p/RKFvhTP8Ft/ But the test for ufw has multiple runs and I only fixed/modified/tested the "root-unitest". I'm running the full test now hoping it might reproduce locally for debugging. First I thought something else in Eoan changed now trigging this issue. But that is rather unlikely, as without the new iptables it works fine. So for now the working theory for now is that iptables 1.8.3 changed something else changed Formerly this was not seen as it failed on the bug I fixed before hitting the hang. But with the fix above applied it now triggers the hang. It always hangs at this tests: Test get_netfilter_capabilities() ERROR (CommandError): No server with a name or ID of '0eb6260d-c544-41eb-8cfa-baa9a745c528' nova show 0eb6260d-c544-41eb-8cfa-baa9a745c528 (adt-eoan-s390x-ufw-20190815-202934) The test uses no Nova, the last two lines is from the automation being aborted. What is interesting is that this test would be ran up to three times, and it sometimes succeeds one or two times now. So it might (in addition to be broken) also be flaky. [1]: https://code.launchpad.net/~paelzer/ubuntu/+source/ufw/+git/ufw/+merge/371391 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1840633/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1840633] Re: autopkgtests get stuck in Eoan with iptables 1.8.3
As expected the upstream patch works even better. It gets -N and -L working. Most (but not all) the time this might be an issue of the build permissions. As now iptables works (correctly) with sudo but not without. The former hang also only happened with sudo. Maybe the build in the autopkgtest context is executed as non-root? And yes now that I know where to look this is the case. 0 1000 26044 4079 20 0 5312 1920 - R?608:40 \_ /sbin/iptables -N ufw-caps-test1744qu So the bgu was that iptables "could" get into the hang if run as non- root and that is what happened on the autopkgtest build. In the actual build this onyl slowly comes up via https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f -rules-requires-root and will so far run semi-privileged and due to that not trigger within the iptables 1.8.3 build. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1840633 Title: autopkgtests get stuck in Eoan with iptables 1.8.3 Status in iptables package in Ubuntu: Confirmed Status in ufw package in Ubuntu: Invalid Bug description: Hi, it is time to report a bug to keep all info in one place. First of all ufw tests were broken with iptables 1.8.3 due to an ordering issue in the output. This I fixed and tested in [1]. It only adds one more "allowed result" to one of the tests, so it should be no big change. I double checked the upload to not (by any accident) change something else. $ debdiff ufw_0.36-1ubuntu1.dsc ufw_0.36-1ubuntu2.dsc | diffstat changelog |8 patches/0003-fix-test-iptables1.8.patch | 4151 patches/series |1 3 files changed, 4160 insertions(+) $ grep -e '---' -e '+++' ufw-0.36/debian/patches/0003-fix-test-iptables1.8.patch --- /dev/null +++ b/tests/root/valid/result.1.8 --- /dev/null +++ b/tests/root/valid6/result.1.8 => That seems safe to me. But since this hit Eoan the tests get stuck and hang what seems until aborted (we have seen up to 75h). A normal execution in the past was ~30 minutes. The modified test worked fine: http://paste.ubuntu.com/p/RKFvhTP8Ft/ But the test for ufw has multiple runs and I only fixed/modified/tested the "root-unitest". I'm running the full test now hoping it might reproduce locally for debugging. First I thought something else in Eoan changed now trigging this issue. But that is rather unlikely, as without the new iptables it works fine. So for now the working theory for now is that iptables 1.8.3 changed something else changed Formerly this was not seen as it failed on the bug I fixed before hitting the hang. But with the fix above applied it now triggers the hang. It always hangs at this tests: Test get_netfilter_capabilities() ERROR (CommandError): No server with a name or ID of '0eb6260d-c544-41eb-8cfa-baa9a745c528' nova show 0eb6260d-c544-41eb-8cfa-baa9a745c528 (adt-eoan-s390x-ufw-20190815-202934) The test uses no Nova, the last two lines is from the automation being aborted. What is interesting is that this test would be ran up to three times, and it sometimes succeeds one or two times now. So it might (in addition to be broken) also be flaky. [1]: https://code.launchpad.net/~paelzer/ubuntu/+source/ufw/+git/ufw/+merge/371391 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1840633/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1840633] Re: autopkgtests get stuck in Eoan with iptables 1.8.3
I have made good progress on the instance that I got shared. I have a fix for the busy loop, but while that will be helpful it isn't avoiding the root-cause and the system will be broken in regard to iptables. I have submitted an RFC with a long cover letter explaining the situation to upstream => https://marc.info/?l=netfilter-devel=156637728424204=2 But I'd not upload an experimental fix that only makes the symptom less fatal. We have to wait for the upstream discussion and hopefully get things fixed before Eoan is released. But for the UFW tests I currently see only the solution of disabling this particular test. As I said before force-badtest would be too blunt and kill all tests - after all it did its job perfectly and identified an issue. The big alternative would be to drop iptables 1.8.3 from Eoan - but I haven't thought about that too much. I'll try to prepare an UFW upload and test it before proposing it. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1840633 Title: autopkgtests get stuck in Eoan with iptables 1.8.3 Status in iptables package in Ubuntu: Confirmed Status in ufw package in Ubuntu: Invalid Bug description: Hi, it is time to report a bug to keep all info in one place. First of all ufw tests were broken with iptables 1.8.3 due to an ordering issue in the output. This I fixed and tested in [1]. It only adds one more "allowed result" to one of the tests, so it should be no big change. I double checked the upload to not (by any accident) change something else. $ debdiff ufw_0.36-1ubuntu1.dsc ufw_0.36-1ubuntu2.dsc | diffstat changelog |8 patches/0003-fix-test-iptables1.8.patch | 4151 patches/series |1 3 files changed, 4160 insertions(+) $ grep -e '---' -e '+++' ufw-0.36/debian/patches/0003-fix-test-iptables1.8.patch --- /dev/null +++ b/tests/root/valid/result.1.8 --- /dev/null +++ b/tests/root/valid6/result.1.8 => That seems safe to me. But since this hit Eoan the tests get stuck and hang what seems until aborted (we have seen up to 75h). A normal execution in the past was ~30 minutes. The modified test worked fine: http://paste.ubuntu.com/p/RKFvhTP8Ft/ But the test for ufw has multiple runs and I only fixed/modified/tested the "root-unitest". I'm running the full test now hoping it might reproduce locally for debugging. First I thought something else in Eoan changed now trigging this issue. But that is rather unlikely, as without the new iptables it works fine. So for now the working theory for now is that iptables 1.8.3 changed something else changed Formerly this was not seen as it failed on the bug I fixed before hitting the hang. But with the fix above applied it now triggers the hang. It always hangs at this tests: Test get_netfilter_capabilities() ERROR (CommandError): No server with a name or ID of '0eb6260d-c544-41eb-8cfa-baa9a745c528' nova show 0eb6260d-c544-41eb-8cfa-baa9a745c528 (adt-eoan-s390x-ufw-20190815-202934) The test uses no Nova, the last two lines is from the automation being aborted. What is interesting is that this test would be ran up to three times, and it sometimes succeeds one or two times now. So it might (in addition to be broken) also be flaky. [1]: https://code.launchpad.net/~paelzer/ubuntu/+source/ufw/+git/ufw/+merge/371391 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1840633/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1840633] Re: autopkgtests get stuck in Eoan with iptables 1.8.3
I have got a reply from upstream, since recently there is a similar fix which isn't in 1.8.3 I'll update my suggested fix to this one and see how the behavior will be with that one. => https://git.netfilter.org/iptables/commit/?id=e5cab728c40be88c541f68e4601d39178c36111f -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1840633 Title: autopkgtests get stuck in Eoan with iptables 1.8.3 Status in iptables package in Ubuntu: Confirmed Status in ufw package in Ubuntu: Invalid Bug description: Hi, it is time to report a bug to keep all info in one place. First of all ufw tests were broken with iptables 1.8.3 due to an ordering issue in the output. This I fixed and tested in [1]. It only adds one more "allowed result" to one of the tests, so it should be no big change. I double checked the upload to not (by any accident) change something else. $ debdiff ufw_0.36-1ubuntu1.dsc ufw_0.36-1ubuntu2.dsc | diffstat changelog |8 patches/0003-fix-test-iptables1.8.patch | 4151 patches/series |1 3 files changed, 4160 insertions(+) $ grep -e '---' -e '+++' ufw-0.36/debian/patches/0003-fix-test-iptables1.8.patch --- /dev/null +++ b/tests/root/valid/result.1.8 --- /dev/null +++ b/tests/root/valid6/result.1.8 => That seems safe to me. But since this hit Eoan the tests get stuck and hang what seems until aborted (we have seen up to 75h). A normal execution in the past was ~30 minutes. The modified test worked fine: http://paste.ubuntu.com/p/RKFvhTP8Ft/ But the test for ufw has multiple runs and I only fixed/modified/tested the "root-unitest". I'm running the full test now hoping it might reproduce locally for debugging. First I thought something else in Eoan changed now trigging this issue. But that is rather unlikely, as without the new iptables it works fine. So for now the working theory for now is that iptables 1.8.3 changed something else changed Formerly this was not seen as it failed on the bug I fixed before hitting the hang. But with the fix above applied it now triggers the hang. It always hangs at this tests: Test get_netfilter_capabilities() ERROR (CommandError): No server with a name or ID of '0eb6260d-c544-41eb-8cfa-baa9a745c528' nova show 0eb6260d-c544-41eb-8cfa-baa9a745c528 (adt-eoan-s390x-ufw-20190815-202934) The test uses no Nova, the last two lines is from the automation being aborted. What is interesting is that this test would be ran up to three times, and it sometimes succeeds one or two times now. So it might (in addition to be broken) also be flaky. [1]: https://code.launchpad.net/~paelzer/ubuntu/+source/ufw/+git/ufw/+merge/371391 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1840633/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1840633] Re: autopkgtests get stuck in Eoan with iptables 1.8.3
@jdstrand - agreed, but we might need/want to mask the test in UFW thou as the fix in iptables might need some time. The problem is that I can either make it skip the single test (need to check if then later on things fail) OR make it a force-badtest which would be sad as we'd loose so many other tests. OTOH it blocks transitions in this busy phase of Eoan so we might need to do something about it. ** Changed in: iptables (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1840633 Title: autopkgtests get stuck in Eoan with iptables 1.8.3 Status in iptables package in Ubuntu: Confirmed Status in ufw package in Ubuntu: Invalid Bug description: Hi, it is time to report a bug to keep all info in one place. First of all ufw tests were broken with iptables 1.8.3 due to an ordering issue in the output. This I fixed and tested in [1]. It only adds one more "allowed result" to one of the tests, so it should be no big change. I double checked the upload to not (by any accident) change something else. $ debdiff ufw_0.36-1ubuntu1.dsc ufw_0.36-1ubuntu2.dsc | diffstat changelog |8 patches/0003-fix-test-iptables1.8.patch | 4151 patches/series |1 3 files changed, 4160 insertions(+) $ grep -e '---' -e '+++' ufw-0.36/debian/patches/0003-fix-test-iptables1.8.patch --- /dev/null +++ b/tests/root/valid/result.1.8 --- /dev/null +++ b/tests/root/valid6/result.1.8 => That seems safe to me. But since this hit Eoan the tests get stuck and hang what seems until aborted (we have seen up to 75h). A normal execution in the past was ~30 minutes. The modified test worked fine: http://paste.ubuntu.com/p/RKFvhTP8Ft/ But the test for ufw has multiple runs and I only fixed/modified/tested the "root-unitest". I'm running the full test now hoping it might reproduce locally for debugging. First I thought something else in Eoan changed now trigging this issue. But that is rather unlikely, as without the new iptables it works fine. So for now the working theory for now is that iptables 1.8.3 changed something else changed Formerly this was not seen as it failed on the bug I fixed before hitting the hang. But with the fix above applied it now triggers the hang. It always hangs at this tests: Test get_netfilter_capabilities() ERROR (CommandError): No server with a name or ID of '0eb6260d-c544-41eb-8cfa-baa9a745c528' nova show 0eb6260d-c544-41eb-8cfa-baa9a745c528 (adt-eoan-s390x-ufw-20190815-202934) The test uses no Nova, the last two lines is from the automation being aborted. What is interesting is that this test would be ran up to three times, and it sometimes succeeds one or two times now. So it might (in addition to be broken) also be flaky. [1]: https://code.launchpad.net/~paelzer/ubuntu/+source/ufw/+git/ufw/+merge/371391 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1840633/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1840633] Re: autopkgtests get stuck in Eoan with iptables 1.8.3
Thanks for chasing this down! It seems clear that while the ufw autopkgtest found the issue, the bug is not in ufw. ** Changed in: ufw (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1840633 Title: autopkgtests get stuck in Eoan with iptables 1.8.3 Status in iptables package in Ubuntu: New Status in ufw package in Ubuntu: Invalid Bug description: Hi, it is time to report a bug to keep all info in one place. First of all ufw tests were broken with iptables 1.8.3 due to an ordering issue in the output. This I fixed and tested in [1]. It only adds one more "allowed result" to one of the tests, so it should be no big change. I double checked the upload to not (by any accident) change something else. $ debdiff ufw_0.36-1ubuntu1.dsc ufw_0.36-1ubuntu2.dsc | diffstat changelog |8 patches/0003-fix-test-iptables1.8.patch | 4151 patches/series |1 3 files changed, 4160 insertions(+) $ grep -e '---' -e '+++' ufw-0.36/debian/patches/0003-fix-test-iptables1.8.patch --- /dev/null +++ b/tests/root/valid/result.1.8 --- /dev/null +++ b/tests/root/valid6/result.1.8 => That seems safe to me. But since this hit Eoan the tests get stuck and hang what seems until aborted (we have seen up to 75h). A normal execution in the past was ~30 minutes. The modified test worked fine: http://paste.ubuntu.com/p/RKFvhTP8Ft/ But the test for ufw has multiple runs and I only fixed/modified/tested the "root-unitest". I'm running the full test now hoping it might reproduce locally for debugging. First I thought something else in Eoan changed now trigging this issue. But that is rather unlikely, as without the new iptables it works fine. So for now the working theory for now is that iptables 1.8.3 changed something else changed Formerly this was not seen as it failed on the bug I fixed before hitting the hang. But with the fix above applied it now triggers the hang. It always hangs at this tests: Test get_netfilter_capabilities() ERROR (CommandError): No server with a name or ID of '0eb6260d-c544-41eb-8cfa-baa9a745c528' nova show 0eb6260d-c544-41eb-8cfa-baa9a745c528 (adt-eoan-s390x-ufw-20190815-202934) The test uses no Nova, the last two lines is from the automation being aborted. What is interesting is that this test would be ran up to three times, and it sometimes succeeds one or two times now. So it might (in addition to be broken) also be flaky. [1]: https://code.launchpad.net/~paelzer/ubuntu/+source/ufw/+git/ufw/+merge/371391 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1840633/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1840633] Re: autopkgtests get stuck in Eoan with iptables 1.8.3
A new -N call hangs as well, so I can debug "into" the failure Here is a strace from start into the looping call https://paste.ubuntu.com/p/YTQStdg6vm/ -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1840633 Title: autopkgtests get stuck in Eoan with iptables 1.8.3 Status in iptables package in Ubuntu: New Status in ufw package in Ubuntu: New Bug description: Hi, it is time to report a bug to keep all info in one place. First of all ufw tests were broken with iptables 1.8.3 due to an ordering issue in the output. This I fixed and tested in [1]. It only adds one more "allowed result" to one of the tests, so it should be no big change. I double checked the upload to not (by any accident) change something else. $ debdiff ufw_0.36-1ubuntu1.dsc ufw_0.36-1ubuntu2.dsc | diffstat changelog |8 patches/0003-fix-test-iptables1.8.patch | 4151 patches/series |1 3 files changed, 4160 insertions(+) $ grep -e '---' -e '+++' ufw-0.36/debian/patches/0003-fix-test-iptables1.8.patch --- /dev/null +++ b/tests/root/valid/result.1.8 --- /dev/null +++ b/tests/root/valid6/result.1.8 => That seems safe to me. But since this hit Eoan the tests get stuck and hang what seems until aborted (we have seen up to 75h). A normal execution in the past was ~30 minutes. The modified test worked fine: http://paste.ubuntu.com/p/RKFvhTP8Ft/ But the test for ufw has multiple runs and I only fixed/modified/tested the "root-unitest". I'm running the full test now hoping it might reproduce locally for debugging. First I thought something else in Eoan changed now trigging this issue. But that is rather unlikely, as without the new iptables it works fine. So for now the working theory for now is that iptables 1.8.3 changed something else changed Formerly this was not seen as it failed on the bug I fixed before hitting the hang. But with the fix above applied it now triggers the hang. It always hangs at this tests: Test get_netfilter_capabilities() ERROR (CommandError): No server with a name or ID of '0eb6260d-c544-41eb-8cfa-baa9a745c528' nova show 0eb6260d-c544-41eb-8cfa-baa9a745c528 (adt-eoan-s390x-ufw-20190815-202934) The test uses no Nova, the last two lines is from the automation being aborted. What is interesting is that this test would be ran up to three times, and it sometimes succeeds one or two times now. So it might (in addition to be broken) also be flaky. [1]: https://code.launchpad.net/~paelzer/ubuntu/+source/ufw/+git/ufw/+merge/371391 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1840633/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1840633] Re: autopkgtests get stuck in Eoan with iptables 1.8.3
It is this function our busy loop is in:
1581 static void __nft_build_cache(struct nft_handle *h)
1582 {
1583 »···uint32_t genid_start, genid_stop;
1584
1585 retry:
1586 »···mnl_genid_get(h, _start);
1587 »···fetch_chain_cache(h);
1588 »···fetch_rule_cache(h);
1589 »···h->have_cache = true;
1590 »···mnl_genid_get(h, _stop);
1591
1592 »···if (genid_start != genid_stop) {
1593 »···»···flush_chain_cache(h, NULL);
1594 »···»···goto retry;
1595 »···}
1596
1597 »···h->nft_genid = genid_start;
1598 }
It seems that if (genid_start != genid_stop)
never is untrue, I get
(gdb) p genid_stop
$5 = 32767
(gdb) p genid_start
$6 = 3596142128
And those values do not change
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iptables in Ubuntu.
https://bugs.launchpad.net/bugs/1840633
Title:
autopkgtests get stuck in Eoan with iptables 1.8.3
Status in iptables package in Ubuntu:
New
Status in ufw package in Ubuntu:
New
Bug description:
Hi,
it is time to report a bug to keep all info in one place.
First of all ufw tests were broken with iptables 1.8.3 due to an ordering
issue in the output.
This I fixed and tested in [1].
It only adds one more "allowed result" to one of the tests, so it should be
no big change.
I double checked the upload to not (by any accident) change something else.
$ debdiff ufw_0.36-1ubuntu1.dsc ufw_0.36-1ubuntu2.dsc | diffstat
changelog |8
patches/0003-fix-test-iptables1.8.patch | 4151
patches/series |1
3 files changed, 4160 insertions(+)
$ grep -e '---' -e '+++'
ufw-0.36/debian/patches/0003-fix-test-iptables1.8.patch
--- /dev/null
+++ b/tests/root/valid/result.1.8
--- /dev/null
+++ b/tests/root/valid6/result.1.8
=> That seems safe to me.
But since this hit Eoan the tests get stuck and hang what seems until aborted
(we have seen up to 75h). A normal execution in the past was ~30 minutes.
The modified test worked fine: http://paste.ubuntu.com/p/RKFvhTP8Ft/
But the test for ufw has multiple runs and I only fixed/modified/tested the
"root-unitest". I'm running the full test now hoping it might reproduce locally
for debugging.
First I thought something else in Eoan changed now trigging this issue. But
that is rather unlikely, as without the new iptables it works fine.
So for now the working theory for now is that iptables 1.8.3 changed
something else changed
Formerly this was not seen as it failed on the bug I fixed before hitting the
hang.
But with the fix above applied it now triggers the hang.
It always hangs at this tests:
Test get_netfilter_capabilities()
ERROR (CommandError): No server with a name or ID of
'0eb6260d-c544-41eb-8cfa-baa9a745c528'
nova show 0eb6260d-c544-41eb-8cfa-baa9a745c528
(adt-eoan-s390x-ufw-20190815-202934)
The test uses no Nova, the last two lines is from the automation being
aborted.
What is interesting is that this test would be ran up to three times,
and it sometimes succeeds one or two times now. So it might (in
addition to be broken) also be flaky.
[1]:
https://code.launchpad.net/~paelzer/ubuntu/+source/ufw/+git/ufw/+merge/371391
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1840633/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1840633] Re: autopkgtests get stuck in Eoan with iptables 1.8.3
Backtrce while in the loop (gdb) bt #0 0x77b120b82790 in mnl_cb_run () from /lib/powerpc64le-linux-gnu/libmnl.so.0 #1 0x013b1172e2a8 in mnl_talk (h=0x7fffd658cad0, nlh=, cb=0x13b11729570 , data=0x7fffd658c5e4) at nft.c:106 #2 0x013b1172e530 in mnl_genid_get (genid=0x7fffd658c5e4, h=0x7fffd658cad0) at nft.c:91 #3 __nft_build_cache (h=h@entry=0x7fffd658cad0) at nft.c:1590 #4 0x013b117330b4 in nft_build_cache (h=0x7fffd658cad0) at nft.c:1603 #5 nft_chain_list_get (table=0x13b11760828 "filter", h=0x7fffd658cad0) at nft.c:1639 #6 nft_chain_builtin_init (table=0x13b1177ec08 , h=0x7fffd658cad0) at nft.c:738 #7 nft_xt_builtin_init (h=h@entry=0x7fffd658cad0, table=table@entry=0x13b11760828 "filter") at nft.c:770 #8 0x013b11737c5c in nft_chain_user_add (h=0x7fffd658cad0, chain=0x7fffd658f78e "ufw-caps-test1744qu", table=0x13b11760828 "filter") at nft.c:1829 #9 0x013b11728a88 in do_commandx (h=0x7fffd658cad0, argc=, argv=0x7fffd658d128, table=0x7fffd658cac8, restore=) at xtables.c:1165 #10 0x013b11725108 in xtables_main (family=family@entry=2, progname=progname@entry=0x13b1175f600 "iptables", argc=, argv=0x7fffd658d128) at xtables-standalone.c:72 #11 0x013b117252bc in xtables_ip4_main (argc=, argv=) at xtables-standalone.c:96 #12 0x013b1175d290 in subcmd_main (argc=3, argv=0x7fffd658d128, cb=0x13b1177f030 ) at xshared.c:212 #13 0x013b1171a520 in main (argc=, argv=) at xtables-nft-multi.c:52 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1840633 Title: autopkgtests get stuck in Eoan with iptables 1.8.3 Status in iptables package in Ubuntu: New Status in ufw package in Ubuntu: New Bug description: Hi, it is time to report a bug to keep all info in one place. First of all ufw tests were broken with iptables 1.8.3 due to an ordering issue in the output. This I fixed and tested in [1]. It only adds one more "allowed result" to one of the tests, so it should be no big change. I double checked the upload to not (by any accident) change something else. $ debdiff ufw_0.36-1ubuntu1.dsc ufw_0.36-1ubuntu2.dsc | diffstat changelog |8 patches/0003-fix-test-iptables1.8.patch | 4151 patches/series |1 3 files changed, 4160 insertions(+) $ grep -e '---' -e '+++' ufw-0.36/debian/patches/0003-fix-test-iptables1.8.patch --- /dev/null +++ b/tests/root/valid/result.1.8 --- /dev/null +++ b/tests/root/valid6/result.1.8 => That seems safe to me. But since this hit Eoan the tests get stuck and hang what seems until aborted (we have seen up to 75h). A normal execution in the past was ~30 minutes. The modified test worked fine: http://paste.ubuntu.com/p/RKFvhTP8Ft/ But the test for ufw has multiple runs and I only fixed/modified/tested the "root-unitest". I'm running the full test now hoping it might reproduce locally for debugging. First I thought something else in Eoan changed now trigging this issue. But that is rather unlikely, as without the new iptables it works fine. So for now the working theory for now is that iptables 1.8.3 changed something else changed Formerly this was not seen as it failed on the bug I fixed before hitting the hang. But with the fix above applied it now triggers the hang. It always hangs at this tests: Test get_netfilter_capabilities() ERROR (CommandError): No server with a name or ID of '0eb6260d-c544-41eb-8cfa-baa9a745c528' nova show 0eb6260d-c544-41eb-8cfa-baa9a745c528 (adt-eoan-s390x-ufw-20190815-202934) The test uses no Nova, the last two lines is from the automation being aborted. What is interesting is that this test would be ran up to three times, and it sometimes succeeds one or two times now. So it might (in addition to be broken) also be flaky. [1]: https://code.launchpad.net/~paelzer/ubuntu/+source/ufw/+git/ufw/+merge/371391 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1840633/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1840633] Re: autopkgtests get stuck in Eoan with iptables 1.8.3
Since iptables seems to hang it might be more a bug in there, but I fail to recreate the case for further analysis no matter what I tried so far :-/ Adding iptables bug task and subscribing jdstrand in case he has another idea due to his experience in that area. ** Also affects: iptables (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1840633 Title: autopkgtests get stuck in Eoan with iptables 1.8.3 Status in iptables package in Ubuntu: New Status in ufw package in Ubuntu: New Bug description: Hi, it is time to report a bug to keep all info in one place. First of all ufw tests were broken with iptables 1.8.3 due to an ordering issue in the output. This I fixed and tested in [1]. It only adds one more "allowed result" to one of the tests, so it should be no big change. I double checked the upload to not (by any accident) change something else. $ debdiff ufw_0.36-1ubuntu1.dsc ufw_0.36-1ubuntu2.dsc | diffstat changelog |8 patches/0003-fix-test-iptables1.8.patch | 4151 patches/series |1 3 files changed, 4160 insertions(+) $ grep -e '---' -e '+++' ufw-0.36/debian/patches/0003-fix-test-iptables1.8.patch --- /dev/null +++ b/tests/root/valid/result.1.8 --- /dev/null +++ b/tests/root/valid6/result.1.8 => That seems safe to me. But since this hit Eoan the tests get stuck and hang what seems until aborted (we have seen up to 75h). A normal execution in the past was ~30 minutes. The modified test worked fine: http://paste.ubuntu.com/p/RKFvhTP8Ft/ But the test for ufw has multiple runs and I only fixed/modified/tested the "root-unitest". I'm running the full test now hoping it might reproduce locally for debugging. First I thought something else in Eoan changed now trigging this issue. But that is rather unlikely, as without the new iptables it works fine. So for now the working theory for now is that iptables 1.8.3 changed something else changed Formerly this was not seen as it failed on the bug I fixed before hitting the hang. But with the fix above applied it now triggers the hang. It always hangs at this tests: Test get_netfilter_capabilities() ERROR (CommandError): No server with a name or ID of '0eb6260d-c544-41eb-8cfa-baa9a745c528' nova show 0eb6260d-c544-41eb-8cfa-baa9a745c528 (adt-eoan-s390x-ufw-20190815-202934) The test uses no Nova, the last two lines is from the automation being aborted. What is interesting is that this test would be ran up to three times, and it sometimes succeeds one or two times now. So it might (in addition to be broken) also be flaky. [1]: https://code.launchpad.net/~paelzer/ubuntu/+source/ufw/+git/ufw/+merge/371391 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1840633/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1840633] Re: autopkgtests get stuck in Eoan with iptables 1.8.3
Note from my debug builds:
TDEBUG: check OSError
GNC: Enter get_netfilter_capabilities
GNC: we are root
GNC: chain ufw-caps-testSqLa5Y
GNC: exe /sbin/iptables
That means it is the first action of the test, just running
/sbin/iptables -N ufw-caps-testSqLa5Y
Nothing else of the python stack was running before as part of the test.
debian/rules just has:
30 install: build
31 »···dh_testdir
32 »···dh_testroot
33 »···dh_prep
34 »···dh_installdirs
35
36 ifeq (,$(findstring nocheck,$(DEB_BUILD_OPTIONS)))
37 »···./run_tests.sh -i $(PYTHON2)
38 »···./run_tests.sh -i $(PYTHON)
39 »···# the testsuite creates the build/ directory with test values that we
40 »···# don't want to use
41 »···make clean
42 endif
We should actually be able to just run
$ sudo apt build-dep ufw
$ ./debian/rules install
In general this is mostly python, so build almost only consists of
selftests.
But no matter what I do the test either
a) works
b) breaks on the root check like
File "/home/ubuntu/ufw/tests/unit/test_util.py", line 918, in
test_get_netfilter_capabilities
ufw.util.get_netfilter_capabilities)
File "/home/ubuntu/ufw/tests/unit/support.py", line 164, in
check_for_exception
t.fail('%s not thrown' % str(expectedException))
AssertionError: not thrown
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1840633
Title:
autopkgtests get stuck in Eoan with iptables 1.8.3
Status in ufw package in Ubuntu:
New
Bug description:
Hi,
it is time to report a bug to keep all info in one place.
First of all ufw tests were broken with iptables 1.8.3 due to an ordering
issue in the output.
This I fixed and tested in [1].
It only adds one more "allowed result" to one of the tests, so it should be
no big change.
I double checked the upload to not (by any accident) change something else.
$ debdiff ufw_0.36-1ubuntu1.dsc ufw_0.36-1ubuntu2.dsc | diffstat
changelog |8
patches/0003-fix-test-iptables1.8.patch | 4151
patches/series |1
3 files changed, 4160 insertions(+)
$ grep -e '---' -e '+++'
ufw-0.36/debian/patches/0003-fix-test-iptables1.8.patch
--- /dev/null
+++ b/tests/root/valid/result.1.8
--- /dev/null
+++ b/tests/root/valid6/result.1.8
=> That seems safe to me.
But since this hit Eoan the tests get stuck and hang what seems until aborted
(we have seen up to 75h). A normal execution in the past was ~30 minutes.
The modified test worked fine: http://paste.ubuntu.com/p/RKFvhTP8Ft/
But the test for ufw has multiple runs and I only fixed/modified/tested the
"root-unitest". I'm running the full test now hoping it might reproduce locally
for debugging.
First I thought something else in Eoan changed now trigging this issue. But
that is rather unlikely, as without the new iptables it works fine.
So for now the working theory for now is that iptables 1.8.3 changed
something else changed
Formerly this was not seen as it failed on the bug I fixed before hitting the
hang.
But with the fix above applied it now triggers the hang.
It always hangs at this tests:
Test get_netfilter_capabilities()
ERROR (CommandError): No server with a name or ID of
'0eb6260d-c544-41eb-8cfa-baa9a745c528'
nova show 0eb6260d-c544-41eb-8cfa-baa9a745c528
(adt-eoan-s390x-ufw-20190815-202934)
The test uses no Nova, the last two lines is from the automation being
aborted.
What is interesting is that this test would be ran up to three times,
and it sometimes succeeds one or two times now. So it might (in
addition to be broken) also be flaky.
[1]:
https://code.launchpad.net/~paelzer/ubuntu/+source/ufw/+git/ufw/+merge/371391
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1840633/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1840633] Re: autopkgtests get stuck in Eoan with iptables 1.8.3
I discussed if maybe it is part of the special net rules "autopkgtest@lgw01-14.secgroup" that I saw in the command - but according to Laney/Juliank those are just copies of the default group for scaling reasons. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1840633 Title: autopkgtests get stuck in Eoan with iptables 1.8.3 Status in ufw package in Ubuntu: New Bug description: Hi, it is time to report a bug to keep all info in one place. First of all ufw tests were broken with iptables 1.8.3 due to an ordering issue in the output. This I fixed and tested in [1]. It only adds one more "allowed result" to one of the tests, so it should be no big change. I double checked the upload to not (by any accident) change something else. $ debdiff ufw_0.36-1ubuntu1.dsc ufw_0.36-1ubuntu2.dsc | diffstat changelog |8 patches/0003-fix-test-iptables1.8.patch | 4151 patches/series |1 3 files changed, 4160 insertions(+) $ grep -e '---' -e '+++' ufw-0.36/debian/patches/0003-fix-test-iptables1.8.patch --- /dev/null +++ b/tests/root/valid/result.1.8 --- /dev/null +++ b/tests/root/valid6/result.1.8 => That seems safe to me. But since this hit Eoan the tests get stuck and hang what seems until aborted (we have seen up to 75h). A normal execution in the past was ~30 minutes. The modified test worked fine: http://paste.ubuntu.com/p/RKFvhTP8Ft/ But the test for ufw has multiple runs and I only fixed/modified/tested the "root-unitest". I'm running the full test now hoping it might reproduce locally for debugging. First I thought something else in Eoan changed now trigging this issue. But that is rather unlikely, as without the new iptables it works fine. So for now the working theory for now is that iptables 1.8.3 changed something else changed Formerly this was not seen as it failed on the bug I fixed before hitting the hang. But with the fix above applied it now triggers the hang. It always hangs at this tests: Test get_netfilter_capabilities() ERROR (CommandError): No server with a name or ID of '0eb6260d-c544-41eb-8cfa-baa9a745c528' nova show 0eb6260d-c544-41eb-8cfa-baa9a745c528 (adt-eoan-s390x-ufw-20190815-202934) The test uses no Nova, the last two lines is from the automation being aborted. What is interesting is that this test would be ran up to three times, and it sometimes succeeds one or two times now. So it might (in addition to be broken) also be flaky. [1]: https://code.launchpad.net/~paelzer/ubuntu/+source/ufw/+git/ufw/+merge/371391 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1840633/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1840633] Re: autopkgtests get stuck in Eoan with iptables 1.8.3
Original run command would be: $ #/home/ubuntu/autopkgtest/runner/autopkgtest --output-dir /tmp/autopkgtest-work.zn3q26vh/out --timeout-copy=6000 --setup-commands /home/ubuntu/autopkgtest-cloud/worker-config-production/setup-canonical.sh --setup-commands /home/ubuntu/autopkgtest/setup-commands/setup-testbed --apt-pocket=proposed --apt-upgrade ufw --env=ADT_TEST_TRIGGERS=iptables/1.8.3-2ubuntu1 -- ssh -s /home/ubuntu/autopkgtest/ssh-setup/nova -- --flavor autopkgtest --security-groups autopkgtest@lgw01-14.secgroup --name adt-eoan-amd64-ufw-20190817-072321 --image adt/ubuntu-eoan-amd64-server --keyname testbed-juju-prod-ues-proposed-migration-machine-11 --net-id=net_ues_proposed_migration -e ''"'"'http_proxy=http://squid.internal:3128'"'"'' -e ''"'"'https_proxy=http://squid.internal:3128'"'"'' -e ''"'"'no_proxy=127.0.0.1,127.0.1.1,localhost,localdomain,novalocal,internal,archive.ubuntu.com,security.ubuntu.com,ddebs.ubuntu.com,changelogs.ubuntu.com,ppa.launchpad.net'"'"'' --mirror=http://ftpmaster.internal/ubuntu But I could not convince canonistack to take a new instance as that. Probably special image type and some internal credentials. The closest I could try was running it (build) on a canonistack instance myself. But since I knew tat even build on LP is fine (only the build-need autopkgtest isn't) the hope that this triggers was low. Setup I used: 1. canonistack m1.medium per [2] 2. copy into this instacne my local UFW directory (to not install ubuntu-dev-tools and all its dependences) 3. use autopkgtest with autopkgtest-virt-null driver to run on this instance $ sudo touch /run/autopkgtest_no_reboot.stamp $ sudo autopkgtest --apt-upgrade --apt-pocket=proposed=src:iptables --shell-fail --output-dir=/tmp/test-v1 ufw_0.36-1ubuntu3~ppa1.dsc -- null But this goes straight to the testing, I need to isolate what the build-needed flag runs. [1]: https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Worker_service_in_the_cloud [2]: https://wiki.canonical.com/InformationInfrastructure/IS/CanoniStack-BOS01#Non-Juju -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1840633 Title: autopkgtests get stuck in Eoan with iptables 1.8.3 Status in ufw package in Ubuntu: New Bug description: Hi, it is time to report a bug to keep all info in one place. First of all ufw tests were broken with iptables 1.8.3 due to an ordering issue in the output. This I fixed and tested in [1]. It only adds one more "allowed result" to one of the tests, so it should be no big change. I double checked the upload to not (by any accident) change something else. $ debdiff ufw_0.36-1ubuntu1.dsc ufw_0.36-1ubuntu2.dsc | diffstat changelog |8 patches/0003-fix-test-iptables1.8.patch | 4151 patches/series |1 3 files changed, 4160 insertions(+) $ grep -e '---' -e '+++' ufw-0.36/debian/patches/0003-fix-test-iptables1.8.patch --- /dev/null +++ b/tests/root/valid/result.1.8 --- /dev/null +++ b/tests/root/valid6/result.1.8 => That seems safe to me. But since this hit Eoan the tests get stuck and hang what seems until aborted (we have seen up to 75h). A normal execution in the past was ~30 minutes. The modified test worked fine: http://paste.ubuntu.com/p/RKFvhTP8Ft/ But the test for ufw has multiple runs and I only fixed/modified/tested the "root-unitest". I'm running the full test now hoping it might reproduce locally for debugging. First I thought something else in Eoan changed now trigging this issue. But that is rather unlikely, as without the new iptables it works fine. So for now the working theory for now is that iptables 1.8.3 changed something else changed Formerly this was not seen as it failed on the bug I fixed before hitting the hang. But with the fix above applied it now triggers the hang. It always hangs at this tests: Test get_netfilter_capabilities() ERROR (CommandError): No server with a name or ID of '0eb6260d-c544-41eb-8cfa-baa9a745c528' nova show 0eb6260d-c544-41eb-8cfa-baa9a745c528 (adt-eoan-s390x-ufw-20190815-202934) The test uses no Nova, the last two lines is from the automation being aborted. What is interesting is that this test would be ran up to three times, and it sometimes succeeds one or two times now. So it might (in addition to be broken) also be flaky. [1]: https://code.launchpad.net/~paelzer/ubuntu/+source/ufw/+git/ufw/+merge/371391 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1840633/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1840633] Re: autopkgtests get stuck in Eoan with iptables 1.8.3
But the ps output already has identified a hang inside of iptables itself hanging. The commandline identified it coming from 767 # First install a test chain 768 (rc, out) = cmd([exe, '-N', chain]) 769 if rc != 0: In the example: /sbin/iptables -N ufw-caps-testZNBjxu That doesn't have a lot of content yet, it is "just" installing a new chain. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1840633 Title: autopkgtests get stuck in Eoan with iptables 1.8.3 Status in ufw package in Ubuntu: New Bug description: Hi, it is time to report a bug to keep all info in one place. First of all ufw tests were broken with iptables 1.8.3 due to an ordering issue in the output. This I fixed and tested in [1]. It only adds one more "allowed result" to one of the tests, so it should be no big change. I double checked the upload to not (by any accident) change something else. $ debdiff ufw_0.36-1ubuntu1.dsc ufw_0.36-1ubuntu2.dsc | diffstat changelog |8 patches/0003-fix-test-iptables1.8.patch | 4151 patches/series |1 3 files changed, 4160 insertions(+) $ grep -e '---' -e '+++' ufw-0.36/debian/patches/0003-fix-test-iptables1.8.patch --- /dev/null +++ b/tests/root/valid/result.1.8 --- /dev/null +++ b/tests/root/valid6/result.1.8 => That seems safe to me. But since this hit Eoan the tests get stuck and hang what seems until aborted (we have seen up to 75h). A normal execution in the past was ~30 minutes. The modified test worked fine: http://paste.ubuntu.com/p/RKFvhTP8Ft/ But the test for ufw has multiple runs and I only fixed/modified/tested the "root-unitest". I'm running the full test now hoping it might reproduce locally for debugging. First I thought something else in Eoan changed now trigging this issue. But that is rather unlikely, as without the new iptables it works fine. So for now the working theory for now is that iptables 1.8.3 changed something else changed Formerly this was not seen as it failed on the bug I fixed before hitting the hang. But with the fix above applied it now triggers the hang. It always hangs at this tests: Test get_netfilter_capabilities() ERROR (CommandError): No server with a name or ID of '0eb6260d-c544-41eb-8cfa-baa9a745c528' nova show 0eb6260d-c544-41eb-8cfa-baa9a745c528 (adt-eoan-s390x-ufw-20190815-202934) The test uses no Nova, the last two lines is from the automation being aborted. What is interesting is that this test would be ran up to three times, and it sometimes succeeds one or two times now. So it might (in addition to be broken) also be flaky. [1]: https://code.launchpad.net/~paelzer/ubuntu/+source/ufw/+git/ufw/+merge/371391 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1840633/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1840633] Re: autopkgtests get stuck in Eoan with iptables 1.8.3
I ran a test on bileto ticket [1] with some extended debug output. A good run would look like: test_get_netfilter_capabilities (tests.unit.test_util.UtilTestCase) Test get_netfilter_capabilities() ...· TDEBUG: check OSError GNC: Enter get_netfilter_capabilities GNC: we are root GNC: chain ufw-caps-testSz014H GNC: exe /sbin/iptables TDEBUG: past OSError TDEBUG: exe /<>/tests/unit/fake-binaries/iptables GNC: Enter get_netfilter_capabilities GNC: we are root GNC: chain ufw-caps-test4To0RO GNC: exe /<>/tests/unit/fake-binaries/iptables GNC: recent-set GNC: recent-update GNC: cleanup GNC: rc 0 GNC: caps ['recent-set', 'recent-update'] TDEBUG: post check I TDEBUG: exe /<>/tests/unit/fake-binaries/ip6tables GNC: Enter get_netfilter_capabilities GNC: we are root GNC: chain ufw6-caps-testwvcC9O GNC: exe /<>/tests/unit/fake-binaries/ip6tables GNC: recent-set GNC: recent-update GNC: cleanup GNC: rc 0 GNC: caps ['recent-set', 'recent-update'] TDEBUG: post check II ok This is just to check which call from python actually breaks it. [1]: https://bileto.ubuntu.com/#/ticket/3790 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1840633 Title: autopkgtests get stuck in Eoan with iptables 1.8.3 Status in ufw package in Ubuntu: New Bug description: Hi, it is time to report a bug to keep all info in one place. First of all ufw tests were broken with iptables 1.8.3 due to an ordering issue in the output. This I fixed and tested in [1]. It only adds one more "allowed result" to one of the tests, so it should be no big change. I double checked the upload to not (by any accident) change something else. $ debdiff ufw_0.36-1ubuntu1.dsc ufw_0.36-1ubuntu2.dsc | diffstat changelog |8 patches/0003-fix-test-iptables1.8.patch | 4151 patches/series |1 3 files changed, 4160 insertions(+) $ grep -e '---' -e '+++' ufw-0.36/debian/patches/0003-fix-test-iptables1.8.patch --- /dev/null +++ b/tests/root/valid/result.1.8 --- /dev/null +++ b/tests/root/valid6/result.1.8 => That seems safe to me. But since this hit Eoan the tests get stuck and hang what seems until aborted (we have seen up to 75h). A normal execution in the past was ~30 minutes. The modified test worked fine: http://paste.ubuntu.com/p/RKFvhTP8Ft/ But the test for ufw has multiple runs and I only fixed/modified/tested the "root-unitest". I'm running the full test now hoping it might reproduce locally for debugging. First I thought something else in Eoan changed now trigging this issue. But that is rather unlikely, as without the new iptables it works fine. So for now the working theory for now is that iptables 1.8.3 changed something else changed Formerly this was not seen as it failed on the bug I fixed before hitting the hang. But with the fix above applied it now triggers the hang. It always hangs at this tests: Test get_netfilter_capabilities() ERROR
[Touch-packages] [Bug 1840633] Re: autopkgtests get stuck in Eoan with iptables 1.8.3
Checking the hanging process shows:
https://paste.ubuntu.com/p/5Z745G963k/ <- that repeating endlessly
And wchan is "0" which means it is really busy
That is:
sendto(4, {{len=20,
type=NFNL_SUBSYS_NFTABLES<<8|NFT_MSG_GETGEN, flags=NLM_F_REQUEST, seq=0,
pid=0}, {nfgen_family=AF_UNSPEC, version=NFNETLINK_V0, res_id=htons(0)}, 20, 0,
{sa_family=AF_NETLINK, nl_pid=0, nl_groups=}, 12) = 20
recvmsg(4, {msg_name={sa_family=AF_NETLINK, nl_pid=0,
nl_groups=}, msg_namelen=12, msg_iov=[{iov_base={{len=40,
type=NLMSG_ERROR, flags=0, seq=0, pid=25819}, {error=-EPERM, msg={{len=20,
type=NFNL_SUBSYS_NFTABLES<<8|NFT_MSG_GETGEN, flags=NLM_F_REQUEST, seq=0,
pid=0}, {nfgen_family=AF_UNSPEC, version=NFNETLINK_V0, res_id=htons(0)}}},
iov_len=16536}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 40
sendto(4, {{len=20,
type=NFNL_SUBSYS_NFTABLES<<8|NFT_MSG_GETGEN, flags=NLM_F_REQUEST, seq=0,
pid=0}, {nfgen_family=AF_UNSPEC, version=NFNETLINK_V0, res_id=htons(0)}, 20, 0,
{sa_family=AF_NETLINK, nl_pid=0, nl_groups=}, 12) = 20
recvmsg(4, {msg_name={sa_family=AF_NETLINK, nl_pid=0,
nl_groups=}, msg_namelen=12, msg_iov=[{iov_base={{len=40,
type=NLMSG_ERROR, flags=0, seq=0, pid=25819}, {error=-EPERM, msg={{len=20,
type=NFNL_SUBSYS_NFTABLES<<8|NFT_MSG_GETGEN, flags=NLM_F_REQUEST, seq=0,
pid=0}, {nfgen_family=AF_UNSPEC, version=NFNETLINK_V0, res_id=htons(0)}}},
iov_len=16536}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 40
sendto(4, {{len=20,
type=NFNL_SUBSYS_NFTABLES<<8|NFT_MSG_GETTABLE, flags=NLM_F_REQUEST|NLM_F_DUMP,
seq=0, pid=0}, {nfgen_family=AF_INET, version=NFNETLINK_V0, res_id=htons(0)},
20, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=}, 12) = 20
recvmsg(4, {msg_name={sa_family=AF_NETLINK, nl_pid=0,
nl_groups=}, msg_namelen=12, msg_iov=[{iov_base={{len=40,
type=NLMSG_ERROR, flags=0, seq=0, pid=25819}, {error=-EPERM, msg={{len=20,
type=NFNL_SUBSYS_NFTABLES<<8|NFT_MSG_GETTABLE, flags=NLM_F_REQUEST|NLM_F_DUMP,
seq=0, pid=0}, {nfgen_family=AF_INET, version=NFNETLINK_V0, res_id=htons(0)}}},
iov_len=16536}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 40
sendto(4, {{len=20,
type=NFNL_SUBSYS_NFTABLES<<8|NFT_MSG_GETCHAIN, flags=NLM_F_REQUEST|NLM_F_DUMP,
seq=0, pid=0}, {nfgen_family=AF_INET, version=NFNETLINK_V0, res_id=htons(0)},
20, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=}, 12) = 20
recvmsg(4, {msg_name={sa_family=AF_NETLINK, nl_pid=0,
nl_groups=}, msg_namelen=12, msg_iov=[{iov_base={{len=40,
type=NLMSG_ERROR, flags=0, seq=0, pid=25819}, {error=-EPERM, msg={{len=20,
type=NFNL_SUBSYS_NFTABLES<<8|NFT_MSG_GETCHAIN, flags=NLM_F_REQUEST|NLM_F_DUMP,
seq=0, pid=0}, {nfgen_family=AF_INET, version=NFNETLINK_V0, res_id=htons(0)}}},
iov_len=16536}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 40
sendto(4, {{len=20,
type=NFNL_SUBSYS_NFTABLES<<8|NFT_MSG_GETGEN, flags=NLM_F_REQUEST, seq=0,
pid=0}, {nfgen_family=AF_UNSPEC, version=NFNETLINK_V0, res_id=htons(0)}, 20, 0,
{sa_family=AF_NETLINK, nl_pid=0, nl_groups=}, 12) = 20
recvmsg(4, {msg_name={sa_family=AF_NETLINK, nl_pid=0,
nl_groups=}, msg_namelen=12, msg_iov=[{iov_base={{len=40,
type=NLMSG_ERROR, flags=0, seq=0, pid=25819}, {error=-EPERM, msg={{len=20,
type=NFNL_SUBSYS_NFTABLES<<8|NFT_MSG_GETGEN, flags=NLM_F_REQUEST, seq=0,
pid=0}, {nfgen_family=AF_UNSPEC, version=NFNETLINK_V0, res_id=htons(0)}}},
iov_len=16536}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 40
sendto(4, {{len=20,
type=NFNL_SUBSYS_NFTABLES<<8|NFT_MSG_GETGEN, flags=NLM_F_REQUEST, seq=0,
pid=0}, {nfgen_family=AF_UNSPEC, version=NFNETLINK_V0, res_id=htons(0)}, 20, 0,
{sa_family=AF_NETLINK, nl_pid=0, nl_groups=}, 12) = 20
recvmsg(4, {msg_name={sa_family=AF_NETLINK, nl_pid=0,
nl_groups=}, msg_namelen=12, msg_iov=[{iov_base={{len=40,
type=NLMSG_ERROR, flags=0, seq=0, pid=25819}, {error=-EPERM, msg={{len=20,
type=NFNL_SUBSYS_NFTABLES<<8|NFT_MSG_GETGEN, flags=NLM_F_REQUEST, seq=0,
pid=0}, {nfgen_family=AF_UNSPEC, version=NFNETLINK_V0, res_id=htons(0)}}},
iov_len=16536}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 40
sendto(4, {{len=20,
type=NFNL_SUBSYS_NFTABLES<<8|NFT_MSG_GETTABLE, flags=NLM_F_REQUEST|NLM_F_DUMP,
seq=0, pid=0}, {nfgen_family=AF_INET, version=NFNETLINK_V0, res_id=htons(0)},
20, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=}, 12) = 20
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ufw in Ubuntu.
https://bugs.launchpad.net/bugs/1840633
Title:
autopkgtests get stuck in Eoan with iptables 1.8.3
Status in ufw package in Ubuntu:
New
Bug description:
Hi,
it is time to report a bug to keep all info in one place.
First of all ufw tests were broken with iptables 1.8.3 due to an ordering
issue in the output.
This I fixed and tested in [1].
It only adds one more "allowed result" to one of the tests, so it should be
no big change.
I
[Touch-packages] [Bug 1840633] Re: autopkgtests get stuck in Eoan with iptables 1.8.3
Thanks to Laney I now know that iptables is actually hanging in what seems to be a busy loop: ubuntu 717 0.0 0.7 22976 11968 ?S08:36 0:00 | \_ sshd: ubuntu@notty root 3715 0.0 0.6 16064 9536 ?Ss 08:36 0:00 | \_ sudo -n /tmp/autopkgtest-run-wrapper env ADT_TEST_TRIGGERS=iptables/1.8.3-2ubuntu1 sh -ec su --shell=/bin/sh ubuntu -c 'set -e; exec 3>&1 >&2; set -x; cd /tmp/autopkgtest.eeLwnO/build.zyB/src; DEB_BUILD_OPTIONS="parallel=1 $DEB_BUILD_OPTIONS" dpkg-buildpackage -us -uc -b; dpkg-source --before-build .' root 3716 0.0 0.1 11200 1920 ?S08:36 0:00 | \_ /bin/bash /tmp/autopkgtest-run-wrapper env ADT_TEST_TRIGGERS=iptables/1.8.3-2ubuntu1 sh -ec su --shell=/bin/sh ubuntu -c 'set -e; exec 3>&1 >&2; set -x; cd /tmp/autopkgtest.eeLwnO/build.zyB/src; DEB_BUILD_OPTIONS="parallel=1 $DEB_BUILD_OPTIONS" dpkg-buildpackage -us -uc -b; dpkg-source --before-build .' root 3718 0.0 0.0 3520 1408 ?S08:36 0:00 | \_ sh -ec su --shell=/bin/sh ubuntu -c 'set -e; exec 3>&1 >&2; set -x; cd /tmp/autopkgtest.eeLwnO/build.zyB/src; DEB_BUILD_OPTIONS="parallel=1 $DEB_BUILD_OPTIONS" dpkg-buildpackage -us -uc -b; dpkg-source --before-build .' root 3719 0.0 0.5 15680 8960 ?S08:36 0:00 | \_ su --shell=/bin/sh ubuntu -c set -e; exec 3>&1 >&2; set -x; cd /tmp/autopkgtest.eeLwnO/build.zyB/src; DEB_BUILD_OPTIONS="parallel=1 $DEB_BUILD_OPTIONS" dpkg-buildpackage -us -uc -b; dpkg-source --before-build . ubuntu3720 0.0 0.0 3520 1344 ?Ss 08:36 0:00 | \_ sh -c set -e; exec 3>&1 >&2; set -x; cd /tmp/autopkgtest.eeLwnO/build.zyB/src; DEB_BUILD_OPTIONS="parallel=1 $DEB_BUILD_OPTIONS" dpkg-buildpackage -us -uc -b; dpkg-source --before-build . ubuntu3721 0.0 1.3 28416 21120 ?S08:36 0:00 | \_ /usr/bin/perl /usr/bin/dpkg-buildpackage -us -uc -b ubuntu3810 0.0 0.0 3520 1344 ?S08:36 0:00 | \_ /bin/sh /usr/bin/fakeroot debian/rules binary ubuntu3825 0.0 0.1 9728 1728 ?S08:36 0:00 | \_ /usr/bin/make -f debian/rules binary ubuntu3835 0.0 0.1 3904 1792 ?S08:36 0:00 | \_ /bin/sh ./run_tests.sh -i /usr/bin/python2 ubuntu3854 1.0 3.4 58048 53952 ?S08:36 1:54 | \_ /usr/bin/python2 ./tests/unit/runner.py ubuntu 25819 99.9 0.1 5312 2368 ?R08:39 173:53 | \_ /sbin/iptables -N ufw-caps-testZNBjxu -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1840633 Title: autopkgtests get stuck in Eoan with iptables 1.8.3 Status in ufw package in Ubuntu: New Bug description: Hi, it is time to report a bug to keep all info in one place. First of all ufw tests were broken with iptables 1.8.3 due to an ordering issue in the output. This I fixed and tested in [1]. It only adds one more "allowed result" to one of the tests, so it should be no big change. I double checked the upload to not (by any accident) change something else. $ debdiff ufw_0.36-1ubuntu1.dsc ufw_0.36-1ubuntu2.dsc | diffstat changelog |8 patches/0003-fix-test-iptables1.8.patch | 4151 patches/series |1 3 files changed, 4160 insertions(+) $ grep -e '---' -e '+++' ufw-0.36/debian/patches/0003-fix-test-iptables1.8.patch --- /dev/null +++ b/tests/root/valid/result.1.8 --- /dev/null +++ b/tests/root/valid6/result.1.8 => That seems safe to me. But since this hit Eoan the tests get stuck and hang what seems until aborted (we have seen up to 75h). A normal execution in the past was ~30 minutes. The modified test worked fine: http://paste.ubuntu.com/p/RKFvhTP8Ft/ But the test for ufw has multiple runs and I only fixed/modified/tested the "root-unitest". I'm running the full test now hoping it might reproduce locally for debugging. First I thought something else in Eoan changed now trigging this issue. But that is rather unlikely, as without the new iptables it works fine. So for now the working theory for now is that iptables 1.8.3 changed something else changed Formerly this was not seen as it failed on the bug I fixed before hitting the hang. But with the fix above applied it now triggers the hang. It always hangs at this tests: Test get_netfilter_capabilities() ERROR (CommandError): No server with a name or ID of '0eb6260d-c544-41eb-8cfa-baa9a745c528' nova show 0eb6260d-c544-41eb-8cfa-baa9a745c528 (adt-eoan-s390x-ufw-20190815-202934)
[Touch-packages] [Bug 1840633] Re: autopkgtests get stuck in Eoan with iptables 1.8.3
There were a bunch of mentions of that function in bug 1044361 bug 1039729 and bug 1062521. And while the issues back then are in the code since version 34 we might again face something that is special about the network environment that is present only in the autopkgtest-env for "build-needed" but not in any other build env where everything is passing. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1840633 Title: autopkgtests get stuck in Eoan with iptables 1.8.3 Status in ufw package in Ubuntu: New Bug description: Hi, it is time to report a bug to keep all info in one place. First of all ufw tests were broken with iptables 1.8.3 due to an ordering issue in the output. This I fixed and tested in [1]. It only adds one more "allowed result" to one of the tests, so it should be no big change. I double checked the upload to not (by any accident) change something else. $ debdiff ufw_0.36-1ubuntu1.dsc ufw_0.36-1ubuntu2.dsc | diffstat changelog |8 patches/0003-fix-test-iptables1.8.patch | 4151 patches/series |1 3 files changed, 4160 insertions(+) $ grep -e '---' -e '+++' ufw-0.36/debian/patches/0003-fix-test-iptables1.8.patch --- /dev/null +++ b/tests/root/valid/result.1.8 --- /dev/null +++ b/tests/root/valid6/result.1.8 => That seems safe to me. But since this hit Eoan the tests get stuck and hang what seems until aborted (we have seen up to 75h). A normal execution in the past was ~30 minutes. The modified test worked fine: http://paste.ubuntu.com/p/RKFvhTP8Ft/ But the test for ufw has multiple runs and I only fixed/modified/tested the "root-unitest". I'm running the full test now hoping it might reproduce locally for debugging. First I thought something else in Eoan changed now trigging this issue. But that is rather unlikely, as without the new iptables it works fine. So for now the working theory for now is that iptables 1.8.3 changed something else changed Formerly this was not seen as it failed on the bug I fixed before hitting the hang. But with the fix above applied it now triggers the hang. It always hangs at this tests: Test get_netfilter_capabilities() ERROR (CommandError): No server with a name or ID of '0eb6260d-c544-41eb-8cfa-baa9a745c528' nova show 0eb6260d-c544-41eb-8cfa-baa9a745c528 (adt-eoan-s390x-ufw-20190815-202934) The test uses no Nova, the last two lines is from the automation being aborted. What is interesting is that this test would be ran up to three times, and it sometimes succeeds one or two times now. So it might (in addition to be broken) also be flaky. [1]: https://code.launchpad.net/~paelzer/ubuntu/+source/ufw/+git/ufw/+merge/371391 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1840633/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1840633] Re: autopkgtests get stuck in Eoan with iptables 1.8.3
This ordering is interesting (from a good case): $ grep -e 'autopkgtest .*\[.*\]: test .*:' -e get_netfilter_capabilities old-iptables-good.txt test_get_netfilter_capabilities (tests.unit.test_util.UtilTestCase) Test get_netfilter_capabilities() ... ok test_get_netfilter_capabilities (tests.unit.test_util.UtilTestCase) Test get_netfilter_capabilities() ... ok autopkgtest [20:42:36]: test test-ufw.py: preparing testbed autopkgtest [20:44:18]: test test-ufw.py: [--- autopkgtest [20:44:22]: test test-ufw.py: ---] autopkgtest [20:44:22]: test test-ufw.py: - - - - - - - - - - results - - - - - - - - - - autopkgtest [20:44:22]: test root-unittest: preparing testbed autopkgtest [20:46:24]: test root-unittest: [--- autopkgtest [20:52:16]: test root-unittest: ---] autopkgtest [20:52:16]: test root-unittest: - - - - - - - - - - results - - - - - - - - - - autopkgtest [20:52:16]: test unittest: preparing testbed autopkgtest [20:52:24]: test unittest: [--- test_get_netfilter_capabilities (tests.unit.test_util.UtilTestCase) Test get_netfilter_capabilities() ... ok autopkgtest [20:59:10]: test unittest: ---] autopkgtest [20:59:11]: test unittest: - - - - - - - - - - results - - - - - - - - - - That means at least the first two of the times the test runs seems to be from the build as two of the autopkgtest entries come with "build-needed". That is interesting as: 1. the new ufw's actual build was obviously against proposed and there things worked fine You can see both occasions of the test in the build log at [1] 2. that build ran on all my tests before upload and it worked fine there Two occasions in http://paste.ubuntu.com/p/RKFvhTP8Ft/ 3. it is not the test, but the prep stage for "build-needed" that is failing which might also be the reason why there is no auto-timeout-abort The bad part, in a local build this just works fine: - autopkgtest in a VM is ok - sbuild building the package itself is ok Next steps: - what does this particular test actually do that could hang - what might be different in that build time comapred to "local-autopkgtest-vm" and the "normal LP builds" [1]: https://launchpadlibrarian.net/437577267/buildlog_ubuntu-eoan- amd64.ufw_0.36-1ubuntu2_BUILDING.txt.gz -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ufw in Ubuntu. https://bugs.launchpad.net/bugs/1840633 Title: autopkgtests get stuck in Eoan with iptables 1.8.3 Status in ufw package in Ubuntu: New Bug description: Hi, it is time to report a bug to keep all info in one place. First of all ufw tests were broken with iptables 1.8.3 due to an ordering issue in the output. This I fixed and tested in [1]. It only adds one more "allowed result" to one of the tests, so it should be no big change. I double checked the upload to not (by any accident) change something else. $ debdiff ufw_0.36-1ubuntu1.dsc ufw_0.36-1ubuntu2.dsc | diffstat changelog |8 patches/0003-fix-test-iptables1.8.patch | 4151 patches/series |1 3 files changed, 4160 insertions(+) $ grep -e '---' -e '+++' ufw-0.36/debian/patches/0003-fix-test-iptables1.8.patch --- /dev/null +++ b/tests/root/valid/result.1.8 --- /dev/null +++ b/tests/root/valid6/result.1.8 => That seems safe to me. But since this hit Eoan the tests get stuck and hang what seems until aborted (we have seen up to 75h). A normal execution in the past was ~30 minutes. The modified test worked fine: http://paste.ubuntu.com/p/RKFvhTP8Ft/ But the test for ufw has multiple runs and I only fixed/modified/tested the "root-unitest". I'm running the full test now hoping it might reproduce locally for debugging. First I thought something else in Eoan changed now trigging this issue. But that is rather unlikely, as without the new iptables it works fine. So for now the working theory for now is that iptables 1.8.3 changed something else changed Formerly this was not seen as it failed on the bug I fixed before hitting the hang. But with the fix above applied it now triggers the hang. It always hangs at this tests: Test get_netfilter_capabilities() ERROR (CommandError): No server with a name or ID of '0eb6260d-c544-41eb-8cfa-baa9a745c528' nova show 0eb6260d-c544-41eb-8cfa-baa9a745c528 (adt-eoan-s390x-ufw-20190815-202934) The test uses no Nova, the last two lines is from the automation being aborted. What is interesting is that this test would be ran up to three times, and it sometimes succeeds one or two times now. So it might (in addition to be broken) also be flaky. [1]: https://code.launchpad.net/~paelzer/ubuntu/+source/ufw/+git/ufw/+merge/371391 To manage notifications about this bug go to:
