[Touch-packages] [Bug 1992454] Re: iptables: segfault when renaming a chain
Hello, As noted in the bug description, it is important to know that from Jammy onward, the only way to exercise the bugfix is to use iptables-legacy and not iptables which uses a newer library. It also mitigates the impact on newer releases unless the -legacy version is being used. ...Louis -- 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/1992454 Title: iptables: segfault when renaming a chain Status in iptables package in Ubuntu: Fix Released Status in iptables source package in Bionic: Fix Committed Status in iptables source package in Focal: Fix Committed Status in iptables source package in Jammy: Fix Committed Status in iptables source package in Kinetic: Fix Committed Bug description: [ Impact ] * An explanation of the effects of the bug on users This is the description for the upstream fix of this bug[1] : This is an odd bug: If the number of chains is right and one renames the last one in the list, libiptc dereferences a NULL pointer. * justification for backporting the fix to the stable release. Without this patch, users may experience segmentation fault when using the following versions of iptables : - Bionic : iptables - Focal : iptables - Jammy : iptables-legacy - Kinetic: iptables-legacy * In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug. The upstream fix adjust the size of the chain_index if the element is the last chain in the list. [1] http://git.netfilter.org/iptables/commit/?id=97bf4e68fc0794adba3243fd96f40f4568e7216f [ Test Plan ] * detailed instructions how to reproduce the bug The following code (adapted from the upstream commit to work on Kinetic) may be used to reproduce the issue : 8< #!/bin/bash # # Cover for a bug in libiptc: # - the chain 'node-98-tmp' is the last in the list sorted by name # - there are 81 chains in total, so three chain index buckets # - the last index bucket contains only the 'node-98-tmp' chain # => rename temporarily removes it from the bucket, leaving a NULL bucket # behind which is dereferenced later when inserting the chain again with new # name again ( echo "*filter" for chain in node-1 node-10 node-101 node-102 node-104 node-107 node-11 node-12 node-13 node-14 node-15 node-16 node-17 node-18 node-19 node-2 node-20 node-21 node-22 node-23 node-25 node-26 node-27 node-28 node-29 node-3 node-30 node-31 node-32 node-33 node-34 node-36 node-37 node-39 node-4 node-40 node-41 node-42 node-43 node-44 node-45 node-46 node-47 node-48 node-49 node-5 node-50 node-51 node-53 node-54 node-55 node-56 node-57 node-58 node-59 node-6 node-60 node-61 node-62 node-63 node-64 node-65 node-66 node-68 node-69 node-7 node-70 node-71 node-74 node-75 node-76 node-8 node-80 node-81 node-86 node-89 node-9 node-92 node-93 node-95 node-98-tmp; do echo ":$chain - [0:0]" done echo "COMMIT" ) | $XT_MULTI iptables-legacy-restore $XT_MULTI iptables-legacy -E node-98-tmp node-98 exit $? >8 Alternatively, this test has been added to the DEP8 list of tests, and will be executed automatically once the package is accepted into proposed. The DEP8 logs can be inspected for its run. Look for a test named "0006rename-segfault". [ Where problems could occur ] For Jammy and onward, only users of the -legacy commands may be affected. Since Jammy, iptables uses the new nft libraries which are not affected by the bug. For Bionic and Focal users, the regular iptables command is affected by the change. As stated in the manpage : E, --rename-chain old-chain new-chain Rename the user specified chain to the user supplied name. This is cosmetic, and has no effect on the structure of the table. In case of a problem, only the modification of the name would be affected as this is clearly outlined as a cosmetic only change. [ Other Info ] The patch is also applied to lunar and mantic, but is fixed in upstream's 1.8.9 release which so far is only in debian testing/unstable. This is being uploaded together with test fixes from bug #1992454 (bionic-specific) and bug #2019023 (focal-specific), which were found and fixed while trying out the DEP8 runs for this package. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1992454/+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 1992454] Re: iptables: segfault when renaming a chain
Hi Robie, This version of the package has been in Lunar since end of last year so I assume that it has been largely in use since then. ..Louis -- 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/1992454 Title: iptables: segfault when renaming a chain Status in iptables package in Ubuntu: Fix Released Status in iptables source package in Bionic: Fix Committed Status in iptables source package in Focal: Fix Committed Status in iptables source package in Jammy: Fix Committed Status in iptables source package in Kinetic: Fix Committed Bug description: [ Impact ] * An explanation of the effects of the bug on users This is the description for the upstream fix of this bug[1] : This is an odd bug: If the number of chains is right and one renames the last one in the list, libiptc dereferences a NULL pointer. * justification for backporting the fix to the stable release. Without this patch, users may experience segmentation fault when using the following versions of iptables : - Bionic : iptables - Focal : iptables - Jammy : iptables-legacy - Kinetic: iptables-legacy * In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug. The upstream fix adjust the size of the chain_index if the element is the last chain in the list. [1] http://git.netfilter.org/iptables/commit/?id=97bf4e68fc0794adba3243fd96f40f4568e7216f [ Test Plan ] * detailed instructions how to reproduce the bug The following code (adapted from the upstream commit to work on Kinetic) may be used to reproduce the issue : 8< #!/bin/bash # # Cover for a bug in libiptc: # - the chain 'node-98-tmp' is the last in the list sorted by name # - there are 81 chains in total, so three chain index buckets # - the last index bucket contains only the 'node-98-tmp' chain # => rename temporarily removes it from the bucket, leaving a NULL bucket # behind which is dereferenced later when inserting the chain again with new # name again ( echo "*filter" for chain in node-1 node-10 node-101 node-102 node-104 node-107 node-11 node-12 node-13 node-14 node-15 node-16 node-17 node-18 node-19 node-2 node-20 node-21 node-22 node-23 node-25 node-26 node-27 node-28 node-29 node-3 node-30 node-31 node-32 node-33 node-34 node-36 node-37 node-39 node-4 node-40 node-41 node-42 node-43 node-44 node-45 node-46 node-47 node-48 node-49 node-5 node-50 node-51 node-53 node-54 node-55 node-56 node-57 node-58 node-59 node-6 node-60 node-61 node-62 node-63 node-64 node-65 node-66 node-68 node-69 node-7 node-70 node-71 node-74 node-75 node-76 node-8 node-80 node-81 node-86 node-89 node-9 node-92 node-93 node-95 node-98-tmp; do echo ":$chain - [0:0]" done echo "COMMIT" ) | $XT_MULTI iptables-legacy-restore $XT_MULTI iptables-legacy -E node-98-tmp node-98 exit $? >8 Alternatively, this test has been added to the DEP8 list of tests, and will be executed automatically once the package is accepted into proposed. The DEP8 logs can be inspected for its run. Look for a test named "0006rename-segfault". [ Where problems could occur ] For Jammy and onward, only users of the -legacy commands may be affected. Since Jammy, iptables uses the new nft libraries which are not affected by the bug. For Bionic and Focal users, the regular iptables command is affected by the change. As stated in the manpage : E, --rename-chain old-chain new-chain Rename the user specified chain to the user supplied name. This is cosmetic, and has no effect on the structure of the table. In case of a problem, only the modification of the name would be affected as this is clearly outlined as a cosmetic only change. [ Other Info ] The patch is also applied to lunar and mantic, but is fixed in upstream's 1.8.9 release which so far is only in debian testing/unstable. This is being uploaded together with test fixes from bug #1992454 (bionic-specific) and bug #2019023 (focal-specific), which were found and fixed while trying out the DEP8 runs for this package. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1992454/+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 1992454] Re: iptables: segfault when renaming a chain
Hello, Thank you for your help in uploading & fixing the DEP8 tests. I have tested the packages in -proposed using the test script in the SRU description for : - bionic - focal - jammy - kinetic. I confirm that the new package fix the problem in those distros. Thanks. ** Tags removed: verification-needed verification-needed-bionic verification-needed-focal verification-needed-jammy verification-needed-kinetic ** Tags added: verification-done verification-done-bionic verification-done-focal verification-done-jammy verification-done-kinetic -- 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/1992454 Title: iptables: segfault when renaming a chain Status in iptables package in Ubuntu: Fix Released Status in iptables source package in Bionic: Fix Committed Status in iptables source package in Focal: Fix Committed Status in iptables source package in Jammy: Fix Committed Status in iptables source package in Kinetic: Fix Committed Bug description: [ Impact ] * An explanation of the effects of the bug on users This is the description for the upstream fix of this bug[1] : This is an odd bug: If the number of chains is right and one renames the last one in the list, libiptc dereferences a NULL pointer. * justification for backporting the fix to the stable release. Without this patch, users may experience segmentation fault when using the following versions of iptables : - Bionic : iptables - Focal : iptables - Jammy : iptables-legacy - Kinetic: iptables-legacy * In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug. The upstream fix adjust the size of the chain_index if the element is the last chain in the list. [1] http://git.netfilter.org/iptables/commit/?id=97bf4e68fc0794adba3243fd96f40f4568e7216f [ Test Plan ] * detailed instructions how to reproduce the bug The following code (adapted from the upstream commit to work on Kinetic) may be used to reproduce the issue : 8< #!/bin/bash # # Cover for a bug in libiptc: # - the chain 'node-98-tmp' is the last in the list sorted by name # - there are 81 chains in total, so three chain index buckets # - the last index bucket contains only the 'node-98-tmp' chain # => rename temporarily removes it from the bucket, leaving a NULL bucket # behind which is dereferenced later when inserting the chain again with new # name again ( echo "*filter" for chain in node-1 node-10 node-101 node-102 node-104 node-107 node-11 node-12 node-13 node-14 node-15 node-16 node-17 node-18 node-19 node-2 node-20 node-21 node-22 node-23 node-25 node-26 node-27 node-28 node-29 node-3 node-30 node-31 node-32 node-33 node-34 node-36 node-37 node-39 node-4 node-40 node-41 node-42 node-43 node-44 node-45 node-46 node-47 node-48 node-49 node-5 node-50 node-51 node-53 node-54 node-55 node-56 node-57 node-58 node-59 node-6 node-60 node-61 node-62 node-63 node-64 node-65 node-66 node-68 node-69 node-7 node-70 node-71 node-74 node-75 node-76 node-8 node-80 node-81 node-86 node-89 node-9 node-92 node-93 node-95 node-98-tmp; do echo ":$chain - [0:0]" done echo "COMMIT" ) | $XT_MULTI iptables-legacy-restore $XT_MULTI iptables-legacy -E node-98-tmp node-98 exit $? >8 Alternatively, this test has been added to the DEP8 list of tests, and will be executed automatically once the package is accepted into proposed. The DEP8 logs can be inspected for its run. Look for a test named "0006rename-segfault". [ Where problems could occur ] For Jammy and onward, only users of the -legacy commands may be affected. Since Jammy, iptables uses the new nft libraries which are not affected by the bug. For Bionic and Focal users, the regular iptables command is affected by the change. As stated in the manpage : E, --rename-chain old-chain new-chain Rename the user specified chain to the user supplied name. This is cosmetic, and has no effect on the structure of the table. In case of a problem, only the modification of the name would be affected as this is clearly outlined as a cosmetic only change. [ Other Info ] The patch is also applied to lunar and mantic, but is fixed in upstream's 1.8.9 release which so far is only in debian testing/unstable. This is being uploaded together with test fixes from bug #1992454 (bionic-specific) and bug #2019023 (focal-specific), which were found and fixed while trying out the DEP8 runs for this package. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1992454/+subscriptions -- Mailing list:
[Touch-packages] [Bug 1992454] Re: iptables: segfault when renaming a chain
Hello, thanks for the update. Will test when they show up in proposed. -- 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/1992454 Title: iptables: segfault when renaming a chain Status in iptables package in Ubuntu: Fix Released Status in iptables source package in Bionic: In Progress Status in iptables source package in Focal: In Progress Status in iptables source package in Jammy: In Progress Status in iptables source package in Kinetic: In Progress Bug description: [ Impact ] * An explanation of the effects of the bug on users This is the description for the upstream fix of this bug[1] : This is an odd bug: If the number of chains is right and one renames the last one in the list, libiptc dereferences a NULL pointer. * justification for backporting the fix to the stable release. Without this patch, users may experience segmentation fault when using the following versions of iptables : - Bionic : iptables - Focal : iptables - Jammy : iptables-legacy - Kinetic: iptables-legacy * In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug. The upstream fix adjust the size of the chain_index if the element is the last chain in the list. [1] http://git.netfilter.org/iptables/commit/?id=97bf4e68fc0794adba3243fd96f40f4568e7216f [ Test Plan ] * detailed instructions how to reproduce the bug The following code (adapted from the upstream commit to work on Kinetic) may be used to reproduce the issue : 8< #!/bin/bash # # Cover for a bug in libiptc: # - the chain 'node-98-tmp' is the last in the list sorted by name # - there are 81 chains in total, so three chain index buckets # - the last index bucket contains only the 'node-98-tmp' chain # => rename temporarily removes it from the bucket, leaving a NULL bucket # behind which is dereferenced later when inserting the chain again with new # name again ( echo "*filter" for chain in node-1 node-10 node-101 node-102 node-104 node-107 node-11 node-12 node-13 node-14 node-15 node-16 node-17 node-18 node-19 node-2 node-20 node-21 node-22 node-23 node-25 node-26 node-27 node-28 node-29 node-3 node-30 node-31 node-32 node-33 node-34 node-36 node-37 node-39 node-4 node-40 node-41 node-42 node-43 node-44 node-45 node-46 node-47 node-48 node-49 node-5 node-50 node-51 node-53 node-54 node-55 node-56 node-57 node-58 node-59 node-6 node-60 node-61 node-62 node-63 node-64 node-65 node-66 node-68 node-69 node-7 node-70 node-71 node-74 node-75 node-76 node-8 node-80 node-81 node-86 node-89 node-9 node-92 node-93 node-95 node-98-tmp; do echo ":$chain - [0:0]" done echo "COMMIT" ) | $XT_MULTI iptables-legacy-restore $XT_MULTI iptables-legacy -E node-98-tmp node-98 exit $? >8 Alternatively, this test has been added to the DEP8 list of tests, and will be executed automatically once the package is accepted into proposed. The DEP8 logs can be inspected for its run. Look for a test named "0006rename-segfault". [ Where problems could occur ] For Jammy and onward, only users of the -legacy commands may be affected. Since Jammy, iptables uses the new nft libraries which are not affected by the bug. For Bionic and Focal users, the regular iptables command is affected by the change. As stated in the manpage : E, --rename-chain old-chain new-chain Rename the user specified chain to the user supplied name. This is cosmetic, and has no effect on the structure of the table. In case of a problem, only the modification of the name would be affected as this is clearly outlined as a cosmetic only change. [ Other Info ] The patch is also applied to lunar and mantic, but is fixed in upstream's 1.8.9 release which so far is only in debian testing/unstable. This is being uploaded together with test fixes from bug #1992454 (bionic-specific) and bug #2019023 (focal-specific), which were found and fixed while trying out the DEP8 runs for this package. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1992454/+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 1992454] Re: iptables: segfault when renaming a chain
Hello, Is there any chance of seeing this fix being SRUed to the stable releases ? Kind regards, ...Louis -- 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/1992454 Title: iptables: segfault when renaming a chain Status in iptables package in Ubuntu: Fix Released Status in iptables source package in Bionic: In Progress Status in iptables source package in Focal: In Progress Status in iptables source package in Jammy: In Progress Status in iptables source package in Kinetic: In Progress Bug description: [ Impact ] * An explanation of the effects of the bug on users This is the description for the upstream fix of this bug[1] : This is an odd bug: If the number of chains is right and one renames the last one in the list, libiptc dereferences a NULL pointer. * An explanation of the effects of the bug on users and * justification for backporting the fix to the stable release. Without this patch, users may experience segmentation fault when using the following versions of iptables : - Bionic : iptables - Focal : iptables - Jammy : iptables-legacy * In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug. The upstream fix adjust the size of the chain_index if the element is the last chain in the list. [1] http://git.netfilter.org/iptables/commit/?id=97bf4e68fc0794adba3243fd96f40f4568e7216f [ Test Plan ] * detailed instructions how to reproduce the bug The following code (adapted from the upstream commit to work on Kinetic) may be used to reproduce the issue : 8< #!/bin/bash # # Cover for a bug in libiptc: # - the chain 'node-98-tmp' is the last in the list sorted by name # - there are 81 chains in total, so three chain index buckets # - the last index bucket contains only the 'node-98-tmp' chain # => rename temporarily removes it from the bucket, leaving a NULL bucket # behind which is dereferenced later when inserting the chain again with new # name again ( echo "*filter" for chain in node-1 node-10 node-101 node-102 node-104 node-107 node-11 node-12 node-13 node-14 node-15 node-16 node-17 node-18 node-19 node-2 node-20 node-21 node-22 node-23 node-25 node-26 node-27 node-28 node-29 node-3 node-30 node-31 node-32 node-33 node-34 node-36 node-37 node-39 node-4 node-40 node-41 node-42 node-43 node-44 node-45 node-46 node-47 node-48 node-49 node-5 node-50 node-51 node-53 node-54 node-55 node-56 node-57 node-58 node-59 node-6 node-60 node-61 node-62 node-63 node-64 node-65 node-66 node-68 node-69 node-7 node-70 node-71 node-74 node-75 node-76 node-8 node-80 node-81 node-86 node-89 node-9 node-92 node-93 node-95 node-98-tmp; do echo ":$chain - [0:0]" done echo "COMMIT" ) | $XT_MULTI iptables-legacy-restore $XT_MULTI iptables-legacy -E node-98-tmp node-98 exit $? >8 [ Where problems could occur ] For Jammy and onward, only users of the -legacy commands may be affected. Since Jammy, iptables uses the new nft libraries which are not affected by the bug. For Bionic and Focal users, the regular iptables command is affected by the change. As stated in the manpage : E, --rename-chain old-chain new-chain Rename the user specified chain to the user supplied name. This is cosmetic, and has no effect on the structure of the table. In case of a problem, only the modification of the name would be affected as this is clearly outlined as a cosmetic only change. [ Other Info ] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1992454/+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 1992454] Re: iptables: segfault when renaming a chain
Great ! I appreciate your help on this. ...Louis -- 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/1992454 Title: iptables: segfault when renaming a chain Status in iptables package in Ubuntu: Fix Released Status in iptables source package in Bionic: In Progress Status in iptables source package in Focal: In Progress Status in iptables source package in Jammy: In Progress Status in iptables source package in Kinetic: In Progress Bug description: [ Impact ] * An explanation of the effects of the bug on users This is the description for the upstream fix of this bug[1] : This is an odd bug: If the number of chains is right and one renames the last one in the list, libiptc dereferences a NULL pointer. * An explanation of the effects of the bug on users and * justification for backporting the fix to the stable release. Without this patch, users may experience segmentation fault when using the following versions of iptables : - Bionic : iptables - Focal : iptables - Jammy : iptables-legacy * In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug. The upstream fix adjust the size of the chain_index if the element is the last chain in the list. [1] http://git.netfilter.org/iptables/commit/?id=97bf4e68fc0794adba3243fd96f40f4568e7216f [ Test Plan ] * detailed instructions how to reproduce the bug The following code (adapted from the upstream commit to work on Kinetic) may be used to reproduce the issue : 8< #!/bin/bash # # Cover for a bug in libiptc: # - the chain 'node-98-tmp' is the last in the list sorted by name # - there are 81 chains in total, so three chain index buckets # - the last index bucket contains only the 'node-98-tmp' chain # => rename temporarily removes it from the bucket, leaving a NULL bucket # behind which is dereferenced later when inserting the chain again with new # name again ( echo "*filter" for chain in node-1 node-10 node-101 node-102 node-104 node-107 node-11 node-12 node-13 node-14 node-15 node-16 node-17 node-18 node-19 node-2 node-20 node-21 node-22 node-23 node-25 node-26 node-27 node-28 node-29 node-3 node-30 node-31 node-32 node-33 node-34 node-36 node-37 node-39 node-4 node-40 node-41 node-42 node-43 node-44 node-45 node-46 node-47 node-48 node-49 node-5 node-50 node-51 node-53 node-54 node-55 node-56 node-57 node-58 node-59 node-6 node-60 node-61 node-62 node-63 node-64 node-65 node-66 node-68 node-69 node-7 node-70 node-71 node-74 node-75 node-76 node-8 node-80 node-81 node-86 node-89 node-9 node-92 node-93 node-95 node-98-tmp; do echo ":$chain - [0:0]" done echo "COMMIT" ) | $XT_MULTI iptables-legacy-restore $XT_MULTI iptables-legacy -E node-98-tmp node-98 exit $? >8 [ Where problems could occur ] For Jammy and onward, only users of the -legacy commands may be affected. Since Jammy, iptables uses the new nft libraries which are not affected by the bug. For Bionic and Focal users, the regular iptables command is affected by the change. As stated in the manpage : E, --rename-chain old-chain new-chain Rename the user specified chain to the user supplied name. This is cosmetic, and has no effect on the structure of the table. In case of a problem, only the modification of the name would be affected as this is clearly outlined as a cosmetic only change. [ Other Info ] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1992454/+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 1992454] Re: iptables: segfault when renaming a chain
Hello, Sorry for the late response. It is most probably a mistake from my part. Let me know if you want me to upload a corrected debdiff. Regarding focal, since it was added by upstream, I thought that it would be better to add it as well. Kind regards, ...Louis -- 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/1992454 Title: iptables: segfault when renaming a chain Status in iptables package in Ubuntu: In Progress Status in iptables source package in Bionic: In Progress Status in iptables source package in Focal: In Progress Status in iptables source package in Jammy: In Progress Status in iptables source package in Kinetic: In Progress Bug description: [ Impact ] * An explanation of the effects of the bug on users This is the description for the upstream fix of this bug[1] : This is an odd bug: If the number of chains is right and one renames the last one in the list, libiptc dereferences a NULL pointer. * An explanation of the effects of the bug on users and * justification for backporting the fix to the stable release. Without this patch, users may experience segmentation fault when using the following versions of iptables : - Bionic : iptables - Focal : iptables - Jammy : iptables-legacy * In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug. The upstream fix adjust the size of the chain_index if the element is the last chain in the list. [1] http://git.netfilter.org/iptables/commit/?id=97bf4e68fc0794adba3243fd96f40f4568e7216f [ Test Plan ] * detailed instructions how to reproduce the bug The following code (adapted from the upstream commit to work on Kinetic) may be used to reproduce the issue : 8< #!/bin/bash # # Cover for a bug in libiptc: # - the chain 'node-98-tmp' is the last in the list sorted by name # - there are 81 chains in total, so three chain index buckets # - the last index bucket contains only the 'node-98-tmp' chain # => rename temporarily removes it from the bucket, leaving a NULL bucket # behind which is dereferenced later when inserting the chain again with new # name again ( echo "*filter" for chain in node-1 node-10 node-101 node-102 node-104 node-107 node-11 node-12 node-13 node-14 node-15 node-16 node-17 node-18 node-19 node-2 node-20 node-21 node-22 node-23 node-25 node-26 node-27 node-28 node-29 node-3 node-30 node-31 node-32 node-33 node-34 node-36 node-37 node-39 node-4 node-40 node-41 node-42 node-43 node-44 node-45 node-46 node-47 node-48 node-49 node-5 node-50 node-51 node-53 node-54 node-55 node-56 node-57 node-58 node-59 node-6 node-60 node-61 node-62 node-63 node-64 node-65 node-66 node-68 node-69 node-7 node-70 node-71 node-74 node-75 node-76 node-8 node-80 node-81 node-86 node-89 node-9 node-92 node-93 node-95 node-98-tmp; do echo ":$chain - [0:0]" done echo "COMMIT" ) | $XT_MULTI iptables-legacy-restore $XT_MULTI iptables-legacy -E node-98-tmp node-98 exit $? >8 [ Where problems could occur ] For Jammy and onward, only users of the -legacy commands may be affected. Since Jammy, iptables uses the new nft libraries which are not affected by the bug. For Bionic and Focal users, the regular iptables command is affected by the change. As stated in the manpage : E, --rename-chain old-chain new-chain Rename the user specified chain to the user supplied name. This is cosmetic, and has no effect on the structure of the table. In case of a problem, only the modification of the name would be affected as this is clearly outlined as a cosmetic only change. [ Other Info ] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1992454/+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 1992454] Re: iptables: segfault when renaming a chain
Debdiff for Bionic ** Patch added: "iptables_1.6.1-2ubuntu2.1.debdiff" https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1992454/+attachment/5629161/+files/iptables_1.6.1-2ubuntu2.1.debdiff -- 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/1992454 Title: iptables: segfault when renaming a chain Status in iptables package in Ubuntu: In Progress Status in iptables source package in Bionic: In Progress Status in iptables source package in Focal: In Progress Status in iptables source package in Jammy: In Progress Status in iptables source package in Kinetic: In Progress Bug description: [ Impact ] * An explanation of the effects of the bug on users This is the description for the upstream fix of this bug[1] : This is an odd bug: If the number of chains is right and one renames the last one in the list, libiptc dereferences a NULL pointer. * An explanation of the effects of the bug on users and * justification for backporting the fix to the stable release. Without this patch, users may experience segmentation fault when using the following versions of iptables : - Bionic : iptables - Focal : iptables - Jammy : iptables-legacy * In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug. The upstream fix adjust the size of the chain_index if the element is the last chain in the list. [1] http://git.netfilter.org/iptables/commit/?id=97bf4e68fc0794adba3243fd96f40f4568e7216f [ Test Plan ] * detailed instructions how to reproduce the bug The following code (adapted from the upstream commit to work on Kinetic) may be used to reproduce the issue : 8< #!/bin/bash # # Cover for a bug in libiptc: # - the chain 'node-98-tmp' is the last in the list sorted by name # - there are 81 chains in total, so three chain index buckets # - the last index bucket contains only the 'node-98-tmp' chain # => rename temporarily removes it from the bucket, leaving a NULL bucket # behind which is dereferenced later when inserting the chain again with new # name again ( echo "*filter" for chain in node-1 node-10 node-101 node-102 node-104 node-107 node-11 node-12 node-13 node-14 node-15 node-16 node-17 node-18 node-19 node-2 node-20 node-21 node-22 node-23 node-25 node-26 node-27 node-28 node-29 node-3 node-30 node-31 node-32 node-33 node-34 node-36 node-37 node-39 node-4 node-40 node-41 node-42 node-43 node-44 node-45 node-46 node-47 node-48 node-49 node-5 node-50 node-51 node-53 node-54 node-55 node-56 node-57 node-58 node-59 node-6 node-60 node-61 node-62 node-63 node-64 node-65 node-66 node-68 node-69 node-7 node-70 node-71 node-74 node-75 node-76 node-8 node-80 node-81 node-86 node-89 node-9 node-92 node-93 node-95 node-98-tmp; do echo ":$chain - [0:0]" done echo "COMMIT" ) | $XT_MULTI iptables-legacy-restore $XT_MULTI iptables-legacy -E node-98-tmp node-98 exit $? >8 [ Where problems could occur ] For Jammy and onward, only users of the -legacy commands may be affected. Since Jammy, iptables uses the new nft libraries which are not affected by the bug. For Bionic and Focal users, the regular iptables command is affected by the change. As stated in the manpage : E, --rename-chain old-chain new-chain Rename the user specified chain to the user supplied name. This is cosmetic, and has no effect on the structure of the table. In case of a problem, only the modification of the name would be affected as this is clearly outlined as a cosmetic only change. [ Other Info ] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1992454/+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 1992454] Re: iptables: segfault when renaming a chain
Debdiff for Jammy ** Patch added: "iptables_1.8.7-1ubuntu5.1.debdiff" https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1992454/+attachment/5629163/+files/iptables_1.8.7-1ubuntu5.1.debdiff -- 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/1992454 Title: iptables: segfault when renaming a chain Status in iptables package in Ubuntu: In Progress Status in iptables source package in Bionic: In Progress Status in iptables source package in Focal: In Progress Status in iptables source package in Jammy: In Progress Status in iptables source package in Kinetic: In Progress Bug description: [ Impact ] * An explanation of the effects of the bug on users This is the description for the upstream fix of this bug[1] : This is an odd bug: If the number of chains is right and one renames the last one in the list, libiptc dereferences a NULL pointer. * An explanation of the effects of the bug on users and * justification for backporting the fix to the stable release. Without this patch, users may experience segmentation fault when using the following versions of iptables : - Bionic : iptables - Focal : iptables - Jammy : iptables-legacy * In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug. The upstream fix adjust the size of the chain_index if the element is the last chain in the list. [1] http://git.netfilter.org/iptables/commit/?id=97bf4e68fc0794adba3243fd96f40f4568e7216f [ Test Plan ] * detailed instructions how to reproduce the bug The following code (adapted from the upstream commit to work on Kinetic) may be used to reproduce the issue : 8< #!/bin/bash # # Cover for a bug in libiptc: # - the chain 'node-98-tmp' is the last in the list sorted by name # - there are 81 chains in total, so three chain index buckets # - the last index bucket contains only the 'node-98-tmp' chain # => rename temporarily removes it from the bucket, leaving a NULL bucket # behind which is dereferenced later when inserting the chain again with new # name again ( echo "*filter" for chain in node-1 node-10 node-101 node-102 node-104 node-107 node-11 node-12 node-13 node-14 node-15 node-16 node-17 node-18 node-19 node-2 node-20 node-21 node-22 node-23 node-25 node-26 node-27 node-28 node-29 node-3 node-30 node-31 node-32 node-33 node-34 node-36 node-37 node-39 node-4 node-40 node-41 node-42 node-43 node-44 node-45 node-46 node-47 node-48 node-49 node-5 node-50 node-51 node-53 node-54 node-55 node-56 node-57 node-58 node-59 node-6 node-60 node-61 node-62 node-63 node-64 node-65 node-66 node-68 node-69 node-7 node-70 node-71 node-74 node-75 node-76 node-8 node-80 node-81 node-86 node-89 node-9 node-92 node-93 node-95 node-98-tmp; do echo ":$chain - [0:0]" done echo "COMMIT" ) | $XT_MULTI iptables-legacy-restore $XT_MULTI iptables-legacy -E node-98-tmp node-98 exit $? >8 [ Where problems could occur ] For Jammy and onward, only users of the -legacy commands may be affected. Since Jammy, iptables uses the new nft libraries which are not affected by the bug. For Bionic and Focal users, the regular iptables command is affected by the change. As stated in the manpage : E, --rename-chain old-chain new-chain Rename the user specified chain to the user supplied name. This is cosmetic, and has no effect on the structure of the table. In case of a problem, only the modification of the name would be affected as this is clearly outlined as a cosmetic only change. [ Other Info ] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1992454/+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 1992454] Re: iptables: segfault when renaming a chain
Debdiff for Focal ** Patch added: "iptables_1.8.4-3ubuntu2.1.debdiff" https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1992454/+attachment/5629162/+files/iptables_1.8.4-3ubuntu2.1.debdiff -- 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/1992454 Title: iptables: segfault when renaming a chain Status in iptables package in Ubuntu: In Progress Status in iptables source package in Bionic: In Progress Status in iptables source package in Focal: In Progress Status in iptables source package in Jammy: In Progress Status in iptables source package in Kinetic: In Progress Bug description: [ Impact ] * An explanation of the effects of the bug on users This is the description for the upstream fix of this bug[1] : This is an odd bug: If the number of chains is right and one renames the last one in the list, libiptc dereferences a NULL pointer. * An explanation of the effects of the bug on users and * justification for backporting the fix to the stable release. Without this patch, users may experience segmentation fault when using the following versions of iptables : - Bionic : iptables - Focal : iptables - Jammy : iptables-legacy * In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug. The upstream fix adjust the size of the chain_index if the element is the last chain in the list. [1] http://git.netfilter.org/iptables/commit/?id=97bf4e68fc0794adba3243fd96f40f4568e7216f [ Test Plan ] * detailed instructions how to reproduce the bug The following code (adapted from the upstream commit to work on Kinetic) may be used to reproduce the issue : 8< #!/bin/bash # # Cover for a bug in libiptc: # - the chain 'node-98-tmp' is the last in the list sorted by name # - there are 81 chains in total, so three chain index buckets # - the last index bucket contains only the 'node-98-tmp' chain # => rename temporarily removes it from the bucket, leaving a NULL bucket # behind which is dereferenced later when inserting the chain again with new # name again ( echo "*filter" for chain in node-1 node-10 node-101 node-102 node-104 node-107 node-11 node-12 node-13 node-14 node-15 node-16 node-17 node-18 node-19 node-2 node-20 node-21 node-22 node-23 node-25 node-26 node-27 node-28 node-29 node-3 node-30 node-31 node-32 node-33 node-34 node-36 node-37 node-39 node-4 node-40 node-41 node-42 node-43 node-44 node-45 node-46 node-47 node-48 node-49 node-5 node-50 node-51 node-53 node-54 node-55 node-56 node-57 node-58 node-59 node-6 node-60 node-61 node-62 node-63 node-64 node-65 node-66 node-68 node-69 node-7 node-70 node-71 node-74 node-75 node-76 node-8 node-80 node-81 node-86 node-89 node-9 node-92 node-93 node-95 node-98-tmp; do echo ":$chain - [0:0]" done echo "COMMIT" ) | $XT_MULTI iptables-legacy-restore $XT_MULTI iptables-legacy -E node-98-tmp node-98 exit $? >8 [ Where problems could occur ] For Jammy and onward, only users of the -legacy commands may be affected. Since Jammy, iptables uses the new nft libraries which are not affected by the bug. For Bionic and Focal users, the regular iptables command is affected by the change. As stated in the manpage : E, --rename-chain old-chain new-chain Rename the user specified chain to the user supplied name. This is cosmetic, and has no effect on the structure of the table. In case of a problem, only the modification of the name would be affected as this is clearly outlined as a cosmetic only change. [ Other Info ] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1992454/+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 1992454] Re: iptables: segfault when renaming a chain
Here are the debdiffs for Bionic, Focal and Jammy. I will let the sponsor worry about the numbering for Kinetic & Lunar -- 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/1992454 Title: iptables: segfault when renaming a chain Status in iptables package in Ubuntu: In Progress Status in iptables source package in Bionic: In Progress Status in iptables source package in Focal: In Progress Status in iptables source package in Jammy: In Progress Status in iptables source package in Kinetic: In Progress Bug description: [ Impact ] * An explanation of the effects of the bug on users This is the description for the upstream fix of this bug[1] : This is an odd bug: If the number of chains is right and one renames the last one in the list, libiptc dereferences a NULL pointer. * An explanation of the effects of the bug on users and * justification for backporting the fix to the stable release. Without this patch, users may experience segmentation fault when using the following versions of iptables : - Bionic : iptables - Focal : iptables - Jammy : iptables-legacy * In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug. The upstream fix adjust the size of the chain_index if the element is the last chain in the list. [1] http://git.netfilter.org/iptables/commit/?id=97bf4e68fc0794adba3243fd96f40f4568e7216f [ Test Plan ] * detailed instructions how to reproduce the bug The following code (adapted from the upstream commit to work on Kinetic) may be used to reproduce the issue : 8< #!/bin/bash # # Cover for a bug in libiptc: # - the chain 'node-98-tmp' is the last in the list sorted by name # - there are 81 chains in total, so three chain index buckets # - the last index bucket contains only the 'node-98-tmp' chain # => rename temporarily removes it from the bucket, leaving a NULL bucket # behind which is dereferenced later when inserting the chain again with new # name again ( echo "*filter" for chain in node-1 node-10 node-101 node-102 node-104 node-107 node-11 node-12 node-13 node-14 node-15 node-16 node-17 node-18 node-19 node-2 node-20 node-21 node-22 node-23 node-25 node-26 node-27 node-28 node-29 node-3 node-30 node-31 node-32 node-33 node-34 node-36 node-37 node-39 node-4 node-40 node-41 node-42 node-43 node-44 node-45 node-46 node-47 node-48 node-49 node-5 node-50 node-51 node-53 node-54 node-55 node-56 node-57 node-58 node-59 node-6 node-60 node-61 node-62 node-63 node-64 node-65 node-66 node-68 node-69 node-7 node-70 node-71 node-74 node-75 node-76 node-8 node-80 node-81 node-86 node-89 node-9 node-92 node-93 node-95 node-98-tmp; do echo ":$chain - [0:0]" done echo "COMMIT" ) | $XT_MULTI iptables-legacy-restore $XT_MULTI iptables-legacy -E node-98-tmp node-98 exit $? >8 [ Where problems could occur ] For Jammy and onward, only users of the -legacy commands may be affected. Since Jammy, iptables uses the new nft libraries which are not affected by the bug. For Bionic and Focal users, the regular iptables command is affected by the change. As stated in the manpage : E, --rename-chain old-chain new-chain Rename the user specified chain to the user supplied name. This is cosmetic, and has no effect on the structure of the table. In case of a problem, only the modification of the name would be affected as this is clearly outlined as a cosmetic only change. [ Other Info ] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1992454/+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 1992454] Re: iptables: segfault when renaming a chain
** Description changed: + [ Impact ] + * An explanation of the effects of the bug on users + This is the description for the upstream fix of this bug[1] : This is an odd bug: If the number of chains is right and one renames the - last one in the list, libiptc dereferences a NULL pointer. + last one in the list, libiptc dereferences a NULL pointer. * An explanation of the effects of the bug on users and - Commit 97bf4e68fc0794adba3243fd96f40f4568e7216f fixes this bug upstream. - This bug is to have the fix included in Ubuntu in order to avoid such - segmentation faults. + * justification for backporting the fix to the stable release. + Without this patch, users may experience segmentation fault when using + the following versions of iptables : - For Jammy and onward, iptables uses the new nft libraries so the problem - does not appear unless the -legacy commands are used. + - Bionic : iptables + - Focal : iptables + - Jammy : iptables-legacy - The following code (adapted from the upstream commit to work on Kinetic) may be used to reproduce the issue : + * In addition, it is helpful, but not required, to include an +explanation of how the upload fixes this bug. + + The upstream fix adjust the size of the chain_index if the element is the + last chain in the list. + + [1] + http://git.netfilter.org/iptables/commit/?id=97bf4e68fc0794adba3243fd96f40f4568e7216f + + [ Test Plan ] + + * detailed instructions how to reproduce the bug + + The following code (adapted from the upstream commit to work on Kinetic) may be used to reproduce the issue : 8< #!/bin/bash # # Cover for a bug in libiptc: # - the chain 'node-98-tmp' is the last in the list sorted by name # - there are 81 chains in total, so three chain index buckets # - the last index bucket contains only the 'node-98-tmp' chain # => rename temporarily removes it from the bucket, leaving a NULL bucket - #behind which is dereferenced later when inserting the chain again with new - #name again + # behind which is dereferenced later when inserting the chain again with new + # name again ( - echo "*filter" - for chain in node-1 node-10 node-101 node-102 node-104 node-107 node-11 node-12 node-13 node-14 node-15 node-16 node-17 node-18 node-19 node-2 node-20 node-21 node-22 node-23 node-25 node-26 node-27 node-28 node-29 node-3 node-30 node-31 node-32 node-33 node-34 node-36 node-37 node-39 node-4 node-40 node-41 node-42 node-43 node-44 node-45 node-46 node-47 node-48 node-49 node-5 node-50 node-51 node-53 node-54 node-55 node-56 node-57 node-58 node-59 node-6 node-60 node-61 node-62 node-63 node-64 node-65 node-66 node-68 node-69 node-7 node-70 node-71 node-74 node-75 node-76 node-8 node-80 node-81 node-86 node-89 node-9 node-92 node-93 node-95 node-98-tmp; do - echo ":$chain - [0:0]" - done - echo "COMMIT" + echo "*filter" + for chain in node-1 node-10 node-101 node-102 node-104 node-107 node-11 node-12 node-13 node-14 node-15 node-16 node-17 node-18 node-19 node-2 node-20 node-21 node-22 node-23 node-25 node-26 node-27 node-28 node-29 node-3 node-30 node-31 node-32 node-33 node-34 node-36 node-37 node-39 node-4 node-40 node-41 node-42 node-43 node-44 node-45 node-46 node-47 node-48 node-49 node-5 node-50 node-51 node-53 node-54 node-55 node-56 node-57 node-58 node-59 node-6 node-60 node-61 node-62 node-63 node-64 node-65 node-66 node-68 node-69 node-7 node-70 node-71 node-74 node-75 node-76 node-8 node-80 node-81 node-86 node-89 node-9 node-92 node-93 node-95 node-98-tmp; do + echo ":$chain - [0:0]" + done + echo "COMMIT" ) | $XT_MULTI iptables-legacy-restore $XT_MULTI iptables-legacy -E node-98-tmp node-98 exit $? >8 - [1] - http://git.netfilter.org/iptables/commit/?id=97bf4e68fc0794adba3243fd96f40f4568e7216f + [ Where problems could occur ] + + For Jammy and onward, only users of the -legacy commands may be affected. + Since Jammy, iptables uses the new nft libraries which are not affected + by the bug. + + For Bionic and Focal users, the regular iptables command is affected by + the change. + + As stated in the manpage : + E, --rename-chain old-chain new-chain + Rename the user specified chain to the user supplied name. This is cosmetic, and has no effect on the structure of the table. + + In case of a problem, only the modification of the name would be affected + as this is clearly outlined as a cosmetic only change. + + [ Other Info ] -- 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/1992454 Title: iptables: segfault when renaming a chain Status in iptables package in Ubuntu: In Progress Status in iptables source package in
[Touch-packages] [Bug 1992454] Re: iptables: segfault when renaming a chain
Hello, I was waiting for the kinetic upload to get through and I have the debdiffs ready for the SRU. I'll take care of that & the SRU template in the coming days. ...Louis -- 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/1992454 Title: iptables: segfault when renaming a chain Status in iptables package in Ubuntu: In Progress Status in iptables source package in Bionic: In Progress Status in iptables source package in Focal: In Progress Status in iptables source package in Jammy: In Progress Status in iptables source package in Kinetic: In Progress Bug description: This is the description for the upstream fix of this bug[1] : This is an odd bug: If the number of chains is right and one renames the last one in the list, libiptc dereferences a NULL pointer. Commit 97bf4e68fc0794adba3243fd96f40f4568e7216f fixes this bug upstream. This bug is to have the fix included in Ubuntu in order to avoid such segmentation faults. For Jammy and onward, iptables uses the new nft libraries so the problem does not appear unless the -legacy commands are used. The following code (adapted from the upstream commit to work on Kinetic) may be used to reproduce the issue : 8< #!/bin/bash # # Cover for a bug in libiptc: # - the chain 'node-98-tmp' is the last in the list sorted by name # - there are 81 chains in total, so three chain index buckets # - the last index bucket contains only the 'node-98-tmp' chain # => rename temporarily removes it from the bucket, leaving a NULL bucket #behind which is dereferenced later when inserting the chain again with new #name again ( echo "*filter" for chain in node-1 node-10 node-101 node-102 node-104 node-107 node-11 node-12 node-13 node-14 node-15 node-16 node-17 node-18 node-19 node-2 node-20 node-21 node-22 node-23 node-25 node-26 node-27 node-28 node-29 node-3 node-30 node-31 node-32 node-33 node-34 node-36 node-37 node-39 node-4 node-40 node-41 node-42 node-43 node-44 node-45 node-46 node-47 node-48 node-49 node-5 node-50 node-51 node-53 node-54 node-55 node-56 node-57 node-58 node-59 node-6 node-60 node-61 node-62 node-63 node-64 node-65 node-66 node-68 node-69 node-7 node-70 node-71 node-74 node-75 node-76 node-8 node-80 node-81 node-86 node-89 node-9 node-92 node-93 node-95 node-98-tmp; do echo ":$chain - [0:0]" done echo "COMMIT" ) | $XT_MULTI iptables-legacy-restore $XT_MULTI iptables-legacy -E node-98-tmp node-98 exit $? >8 [1] http://git.netfilter.org/iptables/commit/?id=97bf4e68fc0794adba3243fd96f40f4568e7216f To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1992454/+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 1992454] Re: iptables: segfault when renaming a chain
Here is an autopkgtest run with the latest patch : Removing autopkgtest-satdep (0) ... autopkgtest [14:09:03]: test command17: chmod +x ./iptables/tests/shell/testcases/iptables/0007-zero-counters_0 ./iptables/tests/shell/testcases/chain/0006rename-segfault_0; cd iptables/tests/shell; ./run-testst autopkgtest [14:09:03]: test command17: [--- I: [OK] ././testcases/arptables/0001-arptables-save-restore_0 I: [OK] ././testcases/arptables/0002-arptables-restore-defaults_0 I: [OK] ././testcases/arptables/0003-arptables-verbose-output_0 I: [OK] ././testcases/chain/0001duplicate_1 I: [OK] ././testcases/chain/0002newchain_0 I: [OK] ././testcases/chain/0003rename_1 I: [OK] ././testcases/chain/0006rename-segfault_0 ... autopkgtest [14:09:19]: test command17: - - - - - - - - - - results - - - - - - - - - - command17PASS autopkgtest [14:09:19]: summary command1 PASS command2 PASS command3 PASS command4 PASS command5 PASS command6 PASS command7 PASS command8 PASS command9 PASS command10PASS command11PASS command12PASS command13PASS command14PASS command15PASS command16PASS command17PASS -- 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/1992454 Title: iptables: segfault when renaming a chain Status in iptables package in Ubuntu: In Progress Status in iptables source package in Bionic: In Progress Status in iptables source package in Focal: In Progress Status in iptables source package in Jammy: In Progress Status in iptables source package in Kinetic: In Progress Bug description: This is the description for the upstream fix of this bug[1] : This is an odd bug: If the number of chains is right and one renames the last one in the list, libiptc dereferences a NULL pointer. Commit 97bf4e68fc0794adba3243fd96f40f4568e7216f fixes this bug upstream. This bug is to have the fix included in Ubuntu in order to avoid such segmentation faults. For Jammy and onward, iptables uses the new nft libraries so the problem does not appear unless the -legacy commands are used. The following code (adapted from the upstream commit to work on Kinetic) may be used to reproduce the issue : 8< #!/bin/bash # # Cover for a bug in libiptc: # - the chain 'node-98-tmp' is the last in the list sorted by name # - there are 81 chains in total, so three chain index buckets # - the last index bucket contains only the 'node-98-tmp' chain # => rename temporarily removes it from the bucket, leaving a NULL bucket #behind which is dereferenced later when inserting the chain again with new #name again ( echo "*filter" for chain in node-1 node-10 node-101 node-102 node-104 node-107 node-11 node-12 node-13 node-14 node-15 node-16 node-17 node-18 node-19 node-2 node-20 node-21 node-22 node-23 node-25 node-26 node-27 node-28 node-29 node-3 node-30 node-31 node-32 node-33 node-34 node-36 node-37 node-39 node-4 node-40 node-41 node-42 node-43 node-44 node-45 node-46 node-47 node-48 node-49 node-5 node-50 node-51 node-53 node-54 node-55 node-56 node-57 node-58 node-59 node-6 node-60 node-61 node-62 node-63 node-64 node-65 node-66 node-68 node-69 node-7 node-70 node-71 node-74 node-75 node-76 node-8 node-80 node-81 node-86 node-89 node-9 node-92 node-93 node-95 node-98-tmp; do echo ":$chain - [0:0]" done echo "COMMIT" ) | $XT_MULTI iptables-legacy-restore $XT_MULTI iptables-legacy -E node-98-tmp node-98 exit $? >8 [1] http://git.netfilter.org/iptables/commit/?id=97bf4e68fc0794adba3243fd96f40f4568e7216f To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1992454/+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 1992454] Re: iptables: segfault when renaming a chain
Slightly modified debdiff which will only run the tests once. ** Patch removed: "iptables_1.8.7-1ubuntu7.debdiff" https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1992454/+attachment/5623037/+files/iptables_1.8.7-1ubuntu7.debdiff ** Patch removed: "iptables_1.8.7-1ubuntu7.debdiff" https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1992454/+attachment/5622997/+files/iptables_1.8.7-1ubuntu7.debdiff ** Patch added: "iptables_1.8.7-1ubuntu7.debdiff" https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1992454/+attachment/5623422/+files/iptables_1.8.7-1ubuntu7.debdiff -- 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/1992454 Title: iptables: segfault when renaming a chain Status in iptables package in Ubuntu: In Progress Status in iptables source package in Bionic: In Progress Status in iptables source package in Focal: In Progress Status in iptables source package in Jammy: In Progress Status in iptables source package in Kinetic: In Progress Bug description: This is the description for the upstream fix of this bug[1] : This is an odd bug: If the number of chains is right and one renames the last one in the list, libiptc dereferences a NULL pointer. Commit 97bf4e68fc0794adba3243fd96f40f4568e7216f fixes this bug upstream. This bug is to have the fix included in Ubuntu in order to avoid such segmentation faults. For Jammy and onward, iptables uses the new nft libraries so the problem does not appear unless the -legacy commands are used. The following code (adapted from the upstream commit to work on Kinetic) may be used to reproduce the issue : 8< #!/bin/bash # # Cover for a bug in libiptc: # - the chain 'node-98-tmp' is the last in the list sorted by name # - there are 81 chains in total, so three chain index buckets # - the last index bucket contains only the 'node-98-tmp' chain # => rename temporarily removes it from the bucket, leaving a NULL bucket #behind which is dereferenced later when inserting the chain again with new #name again ( echo "*filter" for chain in node-1 node-10 node-101 node-102 node-104 node-107 node-11 node-12 node-13 node-14 node-15 node-16 node-17 node-18 node-19 node-2 node-20 node-21 node-22 node-23 node-25 node-26 node-27 node-28 node-29 node-3 node-30 node-31 node-32 node-33 node-34 node-36 node-37 node-39 node-4 node-40 node-41 node-42 node-43 node-44 node-45 node-46 node-47 node-48 node-49 node-5 node-50 node-51 node-53 node-54 node-55 node-56 node-57 node-58 node-59 node-6 node-60 node-61 node-62 node-63 node-64 node-65 node-66 node-68 node-69 node-7 node-70 node-71 node-74 node-75 node-76 node-8 node-80 node-81 node-86 node-89 node-9 node-92 node-93 node-95 node-98-tmp; do echo ":$chain - [0:0]" done echo "COMMIT" ) | $XT_MULTI iptables-legacy-restore $XT_MULTI iptables-legacy -E node-98-tmp node-98 exit $? >8 [1] http://git.netfilter.org/iptables/commit/?id=97bf4e68fc0794adba3243fd96f40f4568e7216f To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1992454/+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 1992454] Re: iptables: segfault when renaming a chain
Hello, Thanks for picking this up. Reference to the test was added to debian/test/control & test ran fine as we can see in the logs : Removing autopkgtest-satdep (0) ... autopkgtest [17:00:57]: test command18: chmod +x ./iptables/tests/shell/testcases/chain/0006rename-segfault_0; cd iptables/tests/shell; ./run-tests.sh --host autopkgtest [17:00:57]: test command18: [--- I: [OK] ././testcases/arptables/0001-arptables-save-restore_0 I: [OK] ././testcases/arptables/0002-arptables-restore-defaults_0 I: [OK] ././testcases/arptables/0003-arptables-verbose-output_0 I: [OK] ././testcases/chain/0001duplicate_1 I: [OK] ././testcases/chain/0002newchain_0 I: [OK] ././testcases/chain/0003rename_1 I: [OK] ././testcases/chain/0006rename-segfault_0 Here is a new debdiff with the added bits. ** Patch added: "iptables_1.8.7-1ubuntu7.debdiff" https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1992454/+attachment/5623037/+files/iptables_1.8.7-1ubuntu7.debdiff -- 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/1992454 Title: iptables: segfault when renaming a chain Status in iptables package in Ubuntu: In Progress Status in iptables source package in Bionic: In Progress Status in iptables source package in Focal: In Progress Status in iptables source package in Jammy: In Progress Status in iptables source package in Kinetic: In Progress Bug description: This is the description for the upstream fix of this bug[1] : This is an odd bug: If the number of chains is right and one renames the last one in the list, libiptc dereferences a NULL pointer. Commit 97bf4e68fc0794adba3243fd96f40f4568e7216f fixes this bug upstream. This bug is to have the fix included in Ubuntu in order to avoid such segmentation faults. For Jammy and onward, iptables uses the new nft libraries so the problem does not appear unless the -legacy commands are used. The following code (adapted from the upstream commit to work on Kinetic) may be used to reproduce the issue : 8< #!/bin/bash # # Cover for a bug in libiptc: # - the chain 'node-98-tmp' is the last in the list sorted by name # - there are 81 chains in total, so three chain index buckets # - the last index bucket contains only the 'node-98-tmp' chain # => rename temporarily removes it from the bucket, leaving a NULL bucket #behind which is dereferenced later when inserting the chain again with new #name again ( echo "*filter" for chain in node-1 node-10 node-101 node-102 node-104 node-107 node-11 node-12 node-13 node-14 node-15 node-16 node-17 node-18 node-19 node-2 node-20 node-21 node-22 node-23 node-25 node-26 node-27 node-28 node-29 node-3 node-30 node-31 node-32 node-33 node-34 node-36 node-37 node-39 node-4 node-40 node-41 node-42 node-43 node-44 node-45 node-46 node-47 node-48 node-49 node-5 node-50 node-51 node-53 node-54 node-55 node-56 node-57 node-58 node-59 node-6 node-60 node-61 node-62 node-63 node-64 node-65 node-66 node-68 node-69 node-7 node-70 node-71 node-74 node-75 node-76 node-8 node-80 node-81 node-86 node-89 node-9 node-92 node-93 node-95 node-98-tmp; do echo ":$chain - [0:0]" done echo "COMMIT" ) | $XT_MULTI iptables-legacy-restore $XT_MULTI iptables-legacy -E node-98-tmp node-98 exit $? >8 [1] http://git.netfilter.org/iptables/commit/?id=97bf4e68fc0794adba3243fd96f40f4568e7216f To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1992454/+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 1992454] Re: iptables: segfault when renaming a chain
Here is the debdiff for upload to Kinetic. ** Patch added: "iptables_1.8.7-1ubuntu7.debdiff" https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1992454/+attachment/5622997/+files/iptables_1.8.7-1ubuntu7.debdiff -- 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/1992454 Title: iptables: segfault when renaming a chain Status in iptables package in Ubuntu: In Progress Status in iptables source package in Bionic: In Progress Status in iptables source package in Focal: In Progress Status in iptables source package in Jammy: In Progress Status in iptables source package in Kinetic: In Progress Bug description: This is the description for the upstream fix of this bug[1] : This is an odd bug: If the number of chains is right and one renames the last one in the list, libiptc dereferences a NULL pointer. Commit 97bf4e68fc0794adba3243fd96f40f4568e7216f fixes this bug upstream. This bug is to have the fix included in Ubuntu in order to avoid such segmentation faults. For Jammy and onward, iptables uses the new nft libraries so the problem does not appear unless the -legacy commands are used. The following code (adapted from the upstream commit to work on Kinetic) may be used to reproduce the issue : 8< #!/bin/bash # # Cover for a bug in libiptc: # - the chain 'node-98-tmp' is the last in the list sorted by name # - there are 81 chains in total, so three chain index buckets # - the last index bucket contains only the 'node-98-tmp' chain # => rename temporarily removes it from the bucket, leaving a NULL bucket #behind which is dereferenced later when inserting the chain again with new #name again ( echo "*filter" for chain in node-1 node-10 node-101 node-102 node-104 node-107 node-11 node-12 node-13 node-14 node-15 node-16 node-17 node-18 node-19 node-2 node-20 node-21 node-22 node-23 node-25 node-26 node-27 node-28 node-29 node-3 node-30 node-31 node-32 node-33 node-34 node-36 node-37 node-39 node-4 node-40 node-41 node-42 node-43 node-44 node-45 node-46 node-47 node-48 node-49 node-5 node-50 node-51 node-53 node-54 node-55 node-56 node-57 node-58 node-59 node-6 node-60 node-61 node-62 node-63 node-64 node-65 node-66 node-68 node-69 node-7 node-70 node-71 node-74 node-75 node-76 node-8 node-80 node-81 node-86 node-89 node-9 node-92 node-93 node-95 node-98-tmp; do echo ":$chain - [0:0]" done echo "COMMIT" ) | $XT_MULTI iptables-legacy-restore $XT_MULTI iptables-legacy -E node-98-tmp node-98 exit $? >8 [1] http://git.netfilter.org/iptables/commit/?id=97bf4e68fc0794adba3243fd96f40f4568e7216f To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1992454/+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 1992454] Re: iptables: segfault when renaming a chain
** Description changed: This is the description for the upstream fix of this bug[1] : This is an odd bug: If the number of chains is right and one renames the last one in the list, libiptc dereferences a NULL pointer. Commit 97bf4e68fc0794adba3243fd96f40f4568e7216f fixes this bug upstream. This bug is to have the fix included in Ubuntu in order to avoid such segmentation faults. + For Jammy and onward, iptables uses the new nft libraries so the problem + does not appear unless the -legacy commands are used. + + The following code (adapted from the upstream commit to work on Kinetic) may be used to reproduce the issue : + 8< + #!/bin/bash + # + # Cover for a bug in libiptc: + # - the chain 'node-98-tmp' is the last in the list sorted by name + # - there are 81 chains in total, so three chain index buckets + # - the last index bucket contains only the 'node-98-tmp' chain + # => rename temporarily removes it from the bucket, leaving a NULL bucket + #behind which is dereferenced later when inserting the chain again with new + #name again + + ( + echo "*filter" + for chain in node-1 node-10 node-101 node-102 node-104 node-107 node-11 node-12 node-13 node-14 node-15 node-16 node-17 node-18 node-19 node-2 node-20 node-21 node-22 node-23 node-25 node-26 node-27 node-28 node-29 node-3 node-30 node-31 node-32 node-33 node-34 node-36 node-37 node-39 node-4 node-40 node-41 node-42 node-43 node-44 node-45 node-46 node-47 node-48 node-49 node-5 node-50 node-51 node-53 node-54 node-55 node-56 node-57 node-58 node-59 node-6 node-60 node-61 node-62 node-63 node-64 node-65 node-66 node-68 node-69 node-7 node-70 node-71 node-74 node-75 node-76 node-8 node-80 node-81 node-86 node-89 node-9 node-92 node-93 node-95 node-98-tmp; do + echo ":$chain - [0:0]" + done + echo "COMMIT" + ) | $XT_MULTI iptables-legacy-restore + $XT_MULTI iptables-legacy -E node-98-tmp node-98 + exit $? + >8 + [1] http://git.netfilter.org/iptables/commit/?id=97bf4e68fc0794adba3243fd96f40f4568e7216f -- 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/1992454 Title: iptables: segfault when renaming a chain Status in iptables package in Ubuntu: In Progress Status in iptables source package in Bionic: In Progress Status in iptables source package in Focal: In Progress Status in iptables source package in Jammy: In Progress Status in iptables source package in Kinetic: In Progress Bug description: This is the description for the upstream fix of this bug[1] : This is an odd bug: If the number of chains is right and one renames the last one in the list, libiptc dereferences a NULL pointer. Commit 97bf4e68fc0794adba3243fd96f40f4568e7216f fixes this bug upstream. This bug is to have the fix included in Ubuntu in order to avoid such segmentation faults. For Jammy and onward, iptables uses the new nft libraries so the problem does not appear unless the -legacy commands are used. The following code (adapted from the upstream commit to work on Kinetic) may be used to reproduce the issue : 8< #!/bin/bash # # Cover for a bug in libiptc: # - the chain 'node-98-tmp' is the last in the list sorted by name # - there are 81 chains in total, so three chain index buckets # - the last index bucket contains only the 'node-98-tmp' chain # => rename temporarily removes it from the bucket, leaving a NULL bucket #behind which is dereferenced later when inserting the chain again with new #name again ( echo "*filter" for chain in node-1 node-10 node-101 node-102 node-104 node-107 node-11 node-12 node-13 node-14 node-15 node-16 node-17 node-18 node-19 node-2 node-20 node-21 node-22 node-23 node-25 node-26 node-27 node-28 node-29 node-3 node-30 node-31 node-32 node-33 node-34 node-36 node-37 node-39 node-4 node-40 node-41 node-42 node-43 node-44 node-45 node-46 node-47 node-48 node-49 node-5 node-50 node-51 node-53 node-54 node-55 node-56 node-57 node-58 node-59 node-6 node-60 node-61 node-62 node-63 node-64 node-65 node-66 node-68 node-69 node-7 node-70 node-71 node-74 node-75 node-76 node-8 node-80 node-81 node-86 node-89 node-9 node-92 node-93 node-95 node-98-tmp; do echo ":$chain - [0:0]" done echo "COMMIT" ) | $XT_MULTI iptables-legacy-restore $XT_MULTI iptables-legacy -E node-98-tmp node-98 exit $? >8 [1] http://git.netfilter.org/iptables/commit/?id=97bf4e68fc0794adba3243fd96f40f4568e7216f To manage notifications about this bug go to:
[Touch-packages] [Bug 1992454] Re: iptables: segfault when renaming a chain
** Changed in: iptables (Ubuntu Bionic) Status: New => In Progress ** Changed in: iptables (Ubuntu Focal) Status: New => In Progress ** Changed in: iptables (Ubuntu Jammy) Status: New => In Progress ** Changed in: iptables (Ubuntu Kinetic) Status: New => In Progress ** Changed in: iptables (Ubuntu Bionic) Assignee: (unassigned) => Louis Bouchard (louis) ** Changed in: iptables (Ubuntu Focal) Assignee: (unassigned) => Louis Bouchard (louis) ** Changed in: iptables (Ubuntu Jammy) Assignee: (unassigned) => Louis Bouchard (louis) ** Changed in: iptables (Ubuntu Kinetic) Assignee: (unassigned) => Louis Bouchard (louis) -- 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/1992454 Title: iptables: segfault when renaming a chain Status in iptables package in Ubuntu: In Progress Status in iptables source package in Bionic: In Progress Status in iptables source package in Focal: In Progress Status in iptables source package in Jammy: In Progress Status in iptables source package in Kinetic: In Progress Bug description: This is the description for the upstream fix of this bug[1] : This is an odd bug: If the number of chains is right and one renames the last one in the list, libiptc dereferences a NULL pointer. Commit 97bf4e68fc0794adba3243fd96f40f4568e7216f fixes this bug upstream. This bug is to have the fix included in Ubuntu in order to avoid such segmentation faults. [1] http://git.netfilter.org/iptables/commit/?id=97bf4e68fc0794adba3243fd96f40f4568e7216f To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1992454/+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 1992454] [NEW] iptables: segfault when renaming a chain
Public bug reported: This is the description for the upstream fix of this bug[1] : This is an odd bug: If the number of chains is right and one renames the last one in the list, libiptc dereferences a NULL pointer. Commit 97bf4e68fc0794adba3243fd96f40f4568e7216f fixes this bug upstream. This bug is to have the fix included in Ubuntu in order to avoid such segmentation faults. [1] http://git.netfilter.org/iptables/commit/?id=97bf4e68fc0794adba3243fd96f40f4568e7216f ** Affects: iptables (Ubuntu) Importance: Undecided Status: New ** Affects: iptables (Ubuntu Bionic) Importance: Undecided Status: New ** Affects: iptables (Ubuntu Focal) Importance: Undecided Status: New ** Affects: iptables (Ubuntu Jammy) Importance: Undecided Status: New ** Affects: iptables (Ubuntu Kinetic) Importance: Undecided Status: New ** Also affects: iptables (Ubuntu Kinetic) Importance: Undecided Status: New ** Also affects: iptables (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: iptables (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: iptables (Ubuntu Bionic) 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/1992454 Title: iptables: segfault when renaming a chain Status in iptables package in Ubuntu: New Status in iptables source package in Bionic: New Status in iptables source package in Focal: New Status in iptables source package in Jammy: New Status in iptables source package in Kinetic: New Bug description: This is the description for the upstream fix of this bug[1] : This is an odd bug: If the number of chains is right and one renames the last one in the list, libiptc dereferences a NULL pointer. Commit 97bf4e68fc0794adba3243fd96f40f4568e7216f fixes this bug upstream. This bug is to have the fix included in Ubuntu in order to avoid such segmentation faults. [1] http://git.netfilter.org/iptables/commit/?id=97bf4e68fc0794adba3243fd96f40f4568e7216f To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1992454/+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 1805183] Re: systemd-resolved constantly restarts on Bionic upgraded from Xenial
Ok, I'll have a look at it; I only backported the Eoan fix to Bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1805183 Title: systemd-resolved constantly restarts on Bionic upgraded from Xenial Status in systemd package in Ubuntu: Triaged Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: Won't Fix Status in systemd source package in Disco: Confirmed Bug description: [Impact] Log noise due to needless restart of resolved on lease expiry, maybe loss of cached state? Application that require Name Resolution may fail while the service is being unnecessarily restarted [Test case] (1) Append make_resolv_conf to the end of the file, so it gets executed (2) Execute the file with bash -x and different settings and ensure there are no restarts if the settings are the same, and that there are if settings change; for example: sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => no restart sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => should restart sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => no restart sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => should restart [Regression potential] The change only restarts resolved when the settings change. If there's a bug in the logic, resolved might not be restarted when it should be. Also, since there will be less restarts of resolved, it will run longer, so if there are memory leaks they will become more apparent. [Original bug report] If a cloud server is upgraded from Xenial to Bionic, the dhclient system remains in place and any DHCP lease refreshes cause a needless restart of the system-resolved daemon Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPREQUEST of 10.226.209.106 on ens3 to 10.226.209.105 port 67 (xid=0x2bd41d7d) Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPACK of 10.226.209.106 from 10.226.209.105 Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopping Network Name Resolution... Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopped Network Name Resolution. Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting Network Name Resolution... Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Positive Trust Anchors: Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5 Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 1 Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Using system hostname 'srv-qvjhx'. Nov 26 16:59:41 srv-qvjhx systemd[1]: Started Network Name Resolution. Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting resolvconf-pull-resolved.service... Nov 26 16:59:41 srv-qvjhx dhclient[825]: bound to 10.226.209.106 -- renewal in 1466 seconds. Nov 26 16:59:41 srv-qvjhx systemd[1]: Started resolvconf-pull-resolved.service. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: ubuntu-release-upgrader-core 1:16.04.25 ProcVersionSignature: Ubuntu 4.4.0-139.165-generic 4.4.160 Uname: Linux 4.4.0-139-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 CrashDB: ubuntu Date: Mon Nov 26 16:17:52 2018 PackageArchitecture: all SourcePackage: ubuntu-release-upgrader UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1805183/+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 1805183] Re: systemd-resolved constantly restarts on Bionic upgraded from Xenial
For Info, I'm repearing an SRU upload for Bionic hopefully available by End Of Day ** Description changed: [Impact] Log noise due to needless restart of resolved on lease expiry, maybe loss of cached state? + Application that require Name Resolution may fail while the service is being unnecessarily restarted [Test case] (1) Append make_resolv_conf to the end of the file, so it gets executed (2) Execute the file with bash -x and different settings and ensure there are no restarts if the settings are the same, and that there are if settings change; for example: sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => no restart sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => should restart sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => no restart sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => should restart [Regression potential] The change only restarts resolved when the settings change. If there's a bug in the logic, resolved might not be restarted when it should be. Also, since there will be less restarts of resolved, it will run longer, so if there are memory leaks they will become more apparent. [Original bug report] If a cloud server is upgraded from Xenial to Bionic, the dhclient system remains in place and any DHCP lease refreshes cause a needless restart of the system-resolved daemon Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPREQUEST of 10.226.209.106 on ens3 to 10.226.209.105 port 67 (xid=0x2bd41d7d) Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPACK of 10.226.209.106 from 10.226.209.105 Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopping Network Name Resolution... Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopped Network Name Resolution. Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting Network Name Resolution... Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Positive Trust Anchors: Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5 Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 1 Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Using system hostname 'srv-qvjhx'. Nov 26 16:59:41 srv-qvjhx systemd[1]: Started Network Name Resolution. Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting resolvconf-pull-resolved.service... Nov 26 16:59:41 srv-qvjhx dhclient[825]: bound to 10.226.209.106 -- renewal in 1466 seconds. Nov 26 16:59:41 srv-qvjhx systemd[1]: Started resolvconf-pull-resolved.service. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: ubuntu-release-upgrader-core 1:16.04.25 ProcVersionSignature: Ubuntu 4.4.0-139.165-generic 4.4.160 Uname: Linux 4.4.0-139-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 CrashDB: ubuntu Date: Mon Nov 26 16:17:52 2018 PackageArchitecture: all SourcePackage: ubuntu-release-upgrader UpgradeStatus: No upgrade log present (probably fresh install) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1805183 Title: systemd-resolved constantly restarts on Bionic upgraded from Xenial Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: Confirmed Status in systemd source package in Disco: Confirmed Bug description: [Impact] Log noise due to needless restart of resolved on lease expiry, maybe loss of cached state? Application that require Name Resolution may fail while the service is being unnecessarily restarted [Test case] (1) Append make_resolv_conf to the end of the file, so it gets executed (2) Execute the file with bash -x and different settings and ensure there are no restarts if the settings are the same, and that there are if settings change; for example: sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => no restart sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => should restart
[Touch-packages] [Bug 1805183] Re: systemd-resolved constantly restarts on Bionic upgraded from Xenial
** Changed in: systemd (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: systemd (Ubuntu Bionic) Assignee: (unassigned) => Louis Bouchard (louis) ** Changed in: systemd (Ubuntu Bionic) Status: Confirmed => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1805183 Title: systemd-resolved constantly restarts on Bionic upgraded from Xenial Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: Confirmed Status in systemd source package in Disco: Confirmed Bug description: [Impact] Log noise due to needless restart of resolved on lease expiry, maybe loss of cached state? [Test case] (1) Append make_resolv_conf to the end of the file, so it gets executed (2) Execute the file with bash -x and different settings and ensure there are no restarts if the settings are the same, and that there are if settings change; for example: sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => no restart sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => should restart sudo new_domain_name_servers=8.8.8.8 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => no restart sudo new_domain_name_servers=8.8.4.4 interface="wlp61s0" reason=REBIND bash -x debian/extra/dhclient-enter-resolved-hook => should restart [Regression potential] The change only restarts resolved when the settings change. If there's a bug in the logic, resolved might not be restarted when it should be. Also, since there will be less restarts of resolved, it will run longer, so if there are memory leaks they will become more apparent. [Original bug report] If a cloud server is upgraded from Xenial to Bionic, the dhclient system remains in place and any DHCP lease refreshes cause a needless restart of the system-resolved daemon Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPREQUEST of 10.226.209.106 on ens3 to 10.226.209.105 port 67 (xid=0x2bd41d7d) Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPACK of 10.226.209.106 from 10.226.209.105 Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopping Network Name Resolution... Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopped Network Name Resolution. Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting Network Name Resolution... Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Positive Trust Anchors: Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 19036 8 2 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5 Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Negative trust anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 1 Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Using system hostname 'srv-qvjhx'. Nov 26 16:59:41 srv-qvjhx systemd[1]: Started Network Name Resolution. Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting resolvconf-pull-resolved.service... Nov 26 16:59:41 srv-qvjhx dhclient[825]: bound to 10.226.209.106 -- renewal in 1466 seconds. Nov 26 16:59:41 srv-qvjhx systemd[1]: Started resolvconf-pull-resolved.service. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: ubuntu-release-upgrader-core 1:16.04.25 ProcVersionSignature: Ubuntu 4.4.0-139.165-generic 4.4.160 Uname: Linux 4.4.0-139-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 CrashDB: ubuntu Date: Mon Nov 26 16:17:52 2018 PackageArchitecture: all SourcePackage: ubuntu-release-upgrader UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1805183/+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 1638695] Re: Python 2.7.12 performance regression
** Changed in: python2.7 (Ubuntu) Assignee: Louis Bouchard (louis) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python2.7 in Ubuntu. https://bugs.launchpad.net/bugs/1638695 Title: Python 2.7.12 performance regression Status in python2.7 package in Ubuntu: Confirmed Bug description: I work on the OpenStack-Ansible project and we've noticed that testing jobs on 16.04 take quite a bit longer to complete than on 14.04. They complete within an hour on 14.04 but they normally take 90 minutes or more on 16.04. We use the same version of Ansible with both versions of Ubuntu. After more digging, I tested python performance (using the 'performance' module) on 14.04 (2.7.6) and on 16.04 (2.7.12). There is a significant performance difference between each version of python. That is detailed in a spreadsheet[0]. I began using perf to dig into the differences when running the python performance module and when using Ansible playbooks. CPU migrations (as measured by perf) are doubled in Ubuntu 16.04 when running the same python workloads. I tried changing some of the kerne.sched sysctl configurables but they had very little effect on the results. I compiled python 2.7.12 from source on 14.04 and found the performance to be unchanged there. I'm not entirely sure where the problem might be now. We also have a bug open in OpenStack-Ansible[1] that provides additional detail. Thanks in advance for any help you can provide! [0] https://docs.google.com/spreadsheets/d/18MmptS_DAd1YP3OhHWQqLYVA9spC3xLt4PS3STI6tds/edit?usp=sharing [1] https://bugs.launchpad.net/openstack-ansible/+bug/1637494 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1638695/+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 1654600] Re: unattended-upgrade-shutdown hangs when /var is a separate filesystem
** Changed in: unattended-upgrades (Ubuntu Xenial)
Assignee: Louis Bouchard (louis) => (unassigned)
** Changed in: unattended-upgrades (Ubuntu Yakkety)
Assignee: Louis Bouchard (louis) => (unassigned)
** Changed in: unattended-upgrades (Ubuntu Zesty)
Assignee: Louis Bouchard (louis) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
https://bugs.launchpad.net/bugs/1654600
Title:
unattended-upgrade-shutdown hangs when /var is a separate filesystem
Status in unattended-upgrades package in Ubuntu:
Fix Released
Status in unattended-upgrades source package in Xenial:
Fix Released
Status in unattended-upgrades source package in Yakkety:
Fix Released
Status in unattended-upgrades source package in Zesty:
Fix Released
Status in unattended-upgrades package in Debian:
Fix Released
Bug description:
[SRU justification]
This fix is needed to make sure that the system does not hang on shutdown
when /var is a speparate file system
[Impact]
System can hang up to 10 minutes if not fixed.
[Fix]
Change the systemd unit's ExecStart to an ExecStop so the unit is correctly
sequenced.
Change WantedBy to multi-user.target. This requires working around Debian Bug
#797108 which causes the new unit not to be enabled.
Remove the unneeded override_dh_isntallinit
Add Default-Start levels to the SysV initscript
Improve DEP8 testing
[Test Case]
In a VM with /var separated from the / file system, shutdown the VM. It will
hang for 10 minutes
[Regression]
Upgrade has been tested on Xenial, Yakkety, Zesty. do-release-upgrade has
been tested from Trusty to Xenial. All behave as expected.
A change of behavior may occur now that the systemd unit is correctly
enabled, which would make functionalities like InstallOnShutdown to
work as expected whereas it could have been broken previously. This
cannot be considered as a regression as it is expected behavior.
Shutdown may be slowed down as it now correctly depends on /var and
/boot to be available so the unit will run earlier than previously.
[Original description of the problem]
The systemd unit file unattended-upgrades.service is used to stop a running
unattended-upgrade
process during shutdown. This unit file is running together with all
filesystem
unmount services.
The unattended-upgrades service checks if the lockfile for unattended-upgrade
(in /var/run) exists, and if it does, there is an unattended-upgrade in
progress
and the service will wait until it finishes (and therefore automatically wait
at
shutdown).
However, if /var is a separate filesystem, it will get unmounted even though
/var/run
is a tmpfs that's still mounted on top of the /var/run directory in the /var
filesystem.
The unattended-upgrade script will fail to find lockfile, sleeps for 5
seconds, and
tries to check the lockfile again. After 10 minutes (the default timeout), it
will finally
exit and the system will continue shutdown.
The problem is the error handling in
/usr/share/unattended-upgrades/unattended-upgrade-shutdown
where it tries to lock itself:
while True:
res = apt_pkg.get_lock(options.lock_file)
logging.debug("get_lock returned %i" % res)
# exit here if there is no lock
if res > 0:
logging.debug("lock not taken")
break
lock_was_taken = True
The function apt_pkg.get_lock() either returns a file descriptor, or -1 on an
error.
File descriptors are just C file descriptors, so they are always positive
integers.
The code should check the result to be negative, not positive. I have
attached a patch
to reverse the logic.
Additional information:
1)
Description: Ubuntu 16.04.1 LTS
Release: 16.04
2)
unattended-upgrades:
Installed: 0.90ubuntu0.3
Candidate: 0.90ubuntu0.3
Version table:
*** 0.90ubuntu0.3 500
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64
Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main i386
Packages
100 /var/lib/dpkg/status
0.90 500
500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial/main i386 Packages
3)
Fast reboot
4)
Very slow reboot (after a 10 minutes timeout)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1654600/+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 1654600] Re: unattended-upgrade-shutdown hangs when /var is a separate filesystem
Test performed for verification-done for :
- Xenial
- Yakkety
- Zesty
1) Installed unattended-upgrades from -proposed
2) Verified the status of the unattended-upgrades service. All displayed :
# systemctl status unattended-upgrades
● unattended-upgrades.service - Unattended Upgrades Shutdown
Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; enabled;
vendor preset: enabled)
Active: active (exited) since Fri 2017-04-28 14:02:35 CEST; 47s ago
Docs: man:unattended-upgrade(8)
3) Enabled Unattended-Upgrade::InstallOnShutdown "true"; in
/etc/apt/apt.conf.d/50unattended-upgrades and rebooted. All releases
applied the upgradeable packages upon reboot (some had too many and the
timeout ran out before end of update)
4) Ran apt -y dist-upgrade on all releases. Rebooted. systems rebooted
normally.
5) Enabled trusty-proposed on a Trusty system and ran do-release-upgrade
to go to Xenial. After completion of the full upgrade, unattended-
upgrades service was active (as seen in #2)
6) Enabled zesty-proposed on a system with /var as a separate file
system. Upgraded unattended-upgrades. After upgrade, unattended-upgrades
service was active (as seen in #2)
7) Verified that the workaround for Debian Bug #809669 left the upgraded
system in an adequate configuration :
cat
/var/lib/systemd/deb-systemd-helper-enabled/unattended-upgrades.service.dsh-also
/etc/systemd/system/multi-user.target.wants/unattended-upgrades.service
# find /etc/systemd | grep unatt
/etc/systemd/system/multi-user.target.wants/unattended-upgrades.service
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
https://bugs.launchpad.net/bugs/1654600
Title:
unattended-upgrade-shutdown hangs when /var is a separate filesystem
Status in unattended-upgrades package in Ubuntu:
Fix Released
Status in unattended-upgrades source package in Xenial:
Fix Committed
Status in unattended-upgrades source package in Yakkety:
Fix Committed
Status in unattended-upgrades source package in Zesty:
Fix Committed
Status in unattended-upgrades package in Debian:
New
Bug description:
[SRU justification]
This fix is needed to make sure that the system does not hang on shutdown
when /var is a speparate file system
[Impact]
System can hang up to 10 minutes if not fixed.
[Fix]
Change the systemd unit's ExecStart to an ExecStop so the unit is correctly
sequenced.
Change WantedBy to multi-user.target. This requires working around Debian Bug
#797108 which causes the new unit not to be enabled.
Remove the unneeded override_dh_isntallinit
Add Default-Start levels to the SysV initscript
Improve DEP8 testing
[Test Case]
In a VM with /var separated from the / file system, shutdown the VM. It will
hang for 10 minutes
[Regression]
Upgrade has been tested on Xenial, Yakkety, Zesty. do-release-upgrade has
been tested from Trusty to Xenial. All behave as expected.
A change of behavior may occur now that the systemd unit is correctly
enabled, which would make functionalities like InstallOnShutdown to
work as expected whereas it could have been broken previously. This
cannot be considered as a regression as it is expected behavior.
Shutdown may be slowed down as it now correctly depends on /var and
/boot to be available so the unit will run earlier than previously.
[Original description of the problem]
The systemd unit file unattended-upgrades.service is used to stop a running
unattended-upgrade
process during shutdown. This unit file is running together with all
filesystem
unmount services.
The unattended-upgrades service checks if the lockfile for unattended-upgrade
(in /var/run) exists, and if it does, there is an unattended-upgrade in
progress
and the service will wait until it finishes (and therefore automatically wait
at
shutdown).
However, if /var is a separate filesystem, it will get unmounted even though
/var/run
is a tmpfs that's still mounted on top of the /var/run directory in the /var
filesystem.
The unattended-upgrade script will fail to find lockfile, sleeps for 5
seconds, and
tries to check the lockfile again. After 10 minutes (the default timeout), it
will finally
exit and the system will continue shutdown.
The problem is the error handling in
/usr/share/unattended-upgrades/unattended-upgrade-shutdown
where it tries to lock itself:
while True:
res = apt_pkg.get_lock(options.lock_file)
logging.debug("get_lock returned %i" % res)
# exit here if there is no lock
if res > 0:
logging.debug("lock not taken")
break
lock_was_taken = True
The function apt_pkg.get_lock() either returns a file descriptor, or -1 on an
error.
File descriptors are just C file descriptors, so they are always positive
integers.
The code should check the result to be negative, not
[Touch-packages] [Bug 1654600] Re: unattended-upgrade-shutdown hangs when /var is a separate filesystem
** Tags removed: sts-sru-needed verification-needed
** Tags added: verification-done
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
https://bugs.launchpad.net/bugs/1654600
Title:
unattended-upgrade-shutdown hangs when /var is a separate filesystem
Status in unattended-upgrades package in Ubuntu:
Fix Released
Status in unattended-upgrades source package in Xenial:
Fix Committed
Status in unattended-upgrades source package in Yakkety:
Fix Committed
Status in unattended-upgrades source package in Zesty:
Fix Committed
Status in unattended-upgrades package in Debian:
New
Bug description:
[SRU justification]
This fix is needed to make sure that the system does not hang on shutdown
when /var is a speparate file system
[Impact]
System can hang up to 10 minutes if not fixed.
[Fix]
Change the systemd unit's ExecStart to an ExecStop so the unit is correctly
sequenced.
Change WantedBy to multi-user.target. This requires working around Debian Bug
#797108 which causes the new unit not to be enabled.
Remove the unneeded override_dh_isntallinit
Add Default-Start levels to the SysV initscript
Improve DEP8 testing
[Test Case]
In a VM with /var separated from the / file system, shutdown the VM. It will
hang for 10 minutes
[Regression]
Upgrade has been tested on Xenial, Yakkety, Zesty. do-release-upgrade has
been tested from Trusty to Xenial. All behave as expected.
A change of behavior may occur now that the systemd unit is correctly
enabled, which would make functionalities like InstallOnShutdown to
work as expected whereas it could have been broken previously. This
cannot be considered as a regression as it is expected behavior.
Shutdown may be slowed down as it now correctly depends on /var and
/boot to be available so the unit will run earlier than previously.
[Original description of the problem]
The systemd unit file unattended-upgrades.service is used to stop a running
unattended-upgrade
process during shutdown. This unit file is running together with all
filesystem
unmount services.
The unattended-upgrades service checks if the lockfile for unattended-upgrade
(in /var/run) exists, and if it does, there is an unattended-upgrade in
progress
and the service will wait until it finishes (and therefore automatically wait
at
shutdown).
However, if /var is a separate filesystem, it will get unmounted even though
/var/run
is a tmpfs that's still mounted on top of the /var/run directory in the /var
filesystem.
The unattended-upgrade script will fail to find lockfile, sleeps for 5
seconds, and
tries to check the lockfile again. After 10 minutes (the default timeout), it
will finally
exit and the system will continue shutdown.
The problem is the error handling in
/usr/share/unattended-upgrades/unattended-upgrade-shutdown
where it tries to lock itself:
while True:
res = apt_pkg.get_lock(options.lock_file)
logging.debug("get_lock returned %i" % res)
# exit here if there is no lock
if res > 0:
logging.debug("lock not taken")
break
lock_was_taken = True
The function apt_pkg.get_lock() either returns a file descriptor, or -1 on an
error.
File descriptors are just C file descriptors, so they are always positive
integers.
The code should check the result to be negative, not positive. I have
attached a patch
to reverse the logic.
Additional information:
1)
Description: Ubuntu 16.04.1 LTS
Release: 16.04
2)
unattended-upgrades:
Installed: 0.90ubuntu0.3
Candidate: 0.90ubuntu0.3
Version table:
*** 0.90ubuntu0.3 500
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64
Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main i386
Packages
100 /var/lib/dpkg/status
0.90 500
500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial/main i386 Packages
3)
Fast reboot
4)
Very slow reboot (after a 10 minutes timeout)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1654600/+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 1654600] Re: unattended-upgrade-shutdown hangs when /var is a separate filesystem
** Description changed:
[SRU justification]
This fix is needed to make sure that the system does not hang on shutdown
when /var is a speparate file system
[Impact]
System can hang up to 10 minutes if not fixed.
[Fix]
Change the systemd unit's ExecStart to an ExecStop so the unit is correctly
sequenced.
+ Change WantedBy to multi-user.target. This requires working around Debian Bug
#797108 which causes the new unit not to be enabled.
+ Remove the unneeded override_dh_isntallinit
+ Add Default-Start levels to the SysV initscript
+ Improve DEP8 testing
[Test Case]
In a VM with /var separated from the / file system, shutdown the VM. It will
hang for 10 minutes
[Regression]
- None to be expected. A ExecStop unit will be sequenced before the Before=
units which is earlier than previously.
+ Upgrade has been tested on Xenial, Yakkety, Zesty. do-release-upgrade has
been tested from Trusty to Xenial. All behave as expected.
+
+ A change of behavior may occur now that the systemd unit is correctly
+ enabled, which would make functionalities like InstallOnShutdown to work
+ as expected whereas it could have been broken previously. This cannot be
+ considered as a regression as it is expected behavior.
+
+ Shutdown may be slowed down as it now correctly depends on /var and
+ /boot to be available so the unit will run earlier than previously.
[Original description of the problem]
The systemd unit file unattended-upgrades.service is used to stop a running
unattended-upgrade
process during shutdown. This unit file is running together with all
filesystem
unmount services.
The unattended-upgrades service checks if the lockfile for unattended-upgrade
(in /var/run) exists, and if it does, there is an unattended-upgrade in
progress
and the service will wait until it finishes (and therefore automatically wait
at
shutdown).
However, if /var is a separate filesystem, it will get unmounted even though
/var/run
is a tmpfs that's still mounted on top of the /var/run directory in the /var
filesystem.
The unattended-upgrade script will fail to find lockfile, sleeps for 5
seconds, and
tries to check the lockfile again. After 10 minutes (the default timeout), it
will finally
exit and the system will continue shutdown.
The problem is the error handling in
/usr/share/unattended-upgrades/unattended-upgrade-shutdown
where it tries to lock itself:
while True:
res = apt_pkg.get_lock(options.lock_file)
logging.debug("get_lock returned %i" % res)
# exit here if there is no lock
if res > 0:
logging.debug("lock not taken")
break
lock_was_taken = True
The function apt_pkg.get_lock() either returns a file descriptor, or -1 on an
error.
File descriptors are just C file descriptors, so they are always positive
integers.
The code should check the result to be negative, not positive. I have
attached a patch
to reverse the logic.
Additional information:
1)
Description: Ubuntu 16.04.1 LTS
Release: 16.04
2)
unattended-upgrades:
Installed: 0.90ubuntu0.3
Candidate: 0.90ubuntu0.3
Version table:
*** 0.90ubuntu0.3 500
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64
Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main i386
Packages
100 /var/lib/dpkg/status
0.90 500
500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial/main i386 Packages
3)
Fast reboot
4)
Very slow reboot (after a 10 minutes timeout)
** Changed in: unattended-upgrades (Ubuntu Yakkety)
Status: Triaged => In Progress
** Changed in: unattended-upgrades (Ubuntu Xenial)
Status: Triaged => In Progress
** Changed in: unattended-upgrades (Ubuntu)
Assignee: Louis Bouchard (louis) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
https://bugs.launchpad.net/bugs/1654600
Title:
unattended-upgrade-shutdown hangs when /var is a separate filesystem
Status in unattended-upgrades package in Ubuntu:
Fix Released
Status in unattended-upgrades source package in Xenial:
In Progress
Status in unattended-upgrades source package in Yakkety:
In Progress
Status in unattended-upgrades source package in Zesty:
In Progress
Status in unattended-upgrades package in Debian:
New
Bug description:
[SRU justification]
This fix is needed to make sure that the system does not hang on shutdown
when /var is a speparate file system
[Impact]
System can hang up to 10 minutes if not fixed.
[Fix]
Change the systemd unit's ExecStart to an ExecStop so the unit is correctly
sequenced.
Change WantedBy to multi-user.target. This requires working around
[Touch-packages] [Bug 1654600] Re: unattended-upgrade-shutdown hangs when /var is a separate filesystem
Brief update to tell everyone that I have a fix ready for all stable
releases. I will update it to Artful soon and the SRU will follow soon.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
https://bugs.launchpad.net/bugs/1654600
Title:
unattended-upgrade-shutdown hangs when /var is a separate filesystem
Status in unattended-upgrades package in Ubuntu:
In Progress
Status in unattended-upgrades source package in Xenial:
Triaged
Status in unattended-upgrades source package in Yakkety:
Triaged
Status in unattended-upgrades source package in Zesty:
In Progress
Status in unattended-upgrades package in Debian:
New
Bug description:
[SRU justification]
This fix is needed to make sure that the system does not hang on shutdown
when /var is a speparate file system
[Impact]
System can hang up to 10 minutes if not fixed.
[Fix]
Change the systemd unit's ExecStart to an ExecStop so the unit is correctly
sequenced.
[Test Case]
In a VM with /var separated from the / file system, shutdown the VM. It will
hang for 10 minutes
[Regression]
None to be expected. A ExecStop unit will be sequenced before the Before=
units which is earlier than previously.
[Original description of the problem]
The systemd unit file unattended-upgrades.service is used to stop a running
unattended-upgrade
process during shutdown. This unit file is running together with all
filesystem
unmount services.
The unattended-upgrades service checks if the lockfile for unattended-upgrade
(in /var/run) exists, and if it does, there is an unattended-upgrade in
progress
and the service will wait until it finishes (and therefore automatically wait
at
shutdown).
However, if /var is a separate filesystem, it will get unmounted even though
/var/run
is a tmpfs that's still mounted on top of the /var/run directory in the /var
filesystem.
The unattended-upgrade script will fail to find lockfile, sleeps for 5
seconds, and
tries to check the lockfile again. After 10 minutes (the default timeout), it
will finally
exit and the system will continue shutdown.
The problem is the error handling in
/usr/share/unattended-upgrades/unattended-upgrade-shutdown
where it tries to lock itself:
while True:
res = apt_pkg.get_lock(options.lock_file)
logging.debug("get_lock returned %i" % res)
# exit here if there is no lock
if res > 0:
logging.debug("lock not taken")
break
lock_was_taken = True
The function apt_pkg.get_lock() either returns a file descriptor, or -1 on an
error.
File descriptors are just C file descriptors, so they are always positive
integers.
The code should check the result to be negative, not positive. I have
attached a patch
to reverse the logic.
Additional information:
1)
Description: Ubuntu 16.04.1 LTS
Release: 16.04
2)
unattended-upgrades:
Installed: 0.90ubuntu0.3
Candidate: 0.90ubuntu0.3
Version table:
*** 0.90ubuntu0.3 500
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64
Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main i386
Packages
100 /var/lib/dpkg/status
0.90 500
500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial/main i386 Packages
3)
Fast reboot
4)
Very slow reboot (after a 10 minutes timeout)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1654600/+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 1654600] Re: unattended-upgrade-shutdown hangs when /var is a separate filesystem
Targetting Zesty as the fix will come after release so as a SRU.
** Also affects: unattended-upgrades (Ubuntu Zesty)
Importance: High
Assignee: Louis Bouchard (louis-bouchard)
Status: In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
https://bugs.launchpad.net/bugs/1654600
Title:
unattended-upgrade-shutdown hangs when /var is a separate filesystem
Status in unattended-upgrades package in Ubuntu:
In Progress
Status in unattended-upgrades source package in Xenial:
Triaged
Status in unattended-upgrades source package in Yakkety:
Triaged
Status in unattended-upgrades source package in Zesty:
In Progress
Status in unattended-upgrades package in Debian:
New
Bug description:
[SRU justification]
This fix is needed to make sure that the system does not hang on shutdown
when /var is a speparate file system
[Impact]
System can hang up to 10 minutes if not fixed.
[Fix]
Change the systemd unit's ExecStart to an ExecStop so the unit is correctly
sequenced.
[Test Case]
In a VM with /var separated from the / file system, shutdown the VM. It will
hang for 10 minutes
[Regression]
None to be expected. A ExecStop unit will be sequenced before the Before=
units which is earlier than previously.
[Original description of the problem]
The systemd unit file unattended-upgrades.service is used to stop a running
unattended-upgrade
process during shutdown. This unit file is running together with all
filesystem
unmount services.
The unattended-upgrades service checks if the lockfile for unattended-upgrade
(in /var/run) exists, and if it does, there is an unattended-upgrade in
progress
and the service will wait until it finishes (and therefore automatically wait
at
shutdown).
However, if /var is a separate filesystem, it will get unmounted even though
/var/run
is a tmpfs that's still mounted on top of the /var/run directory in the /var
filesystem.
The unattended-upgrade script will fail to find lockfile, sleeps for 5
seconds, and
tries to check the lockfile again. After 10 minutes (the default timeout), it
will finally
exit and the system will continue shutdown.
The problem is the error handling in
/usr/share/unattended-upgrades/unattended-upgrade-shutdown
where it tries to lock itself:
while True:
res = apt_pkg.get_lock(options.lock_file)
logging.debug("get_lock returned %i" % res)
# exit here if there is no lock
if res > 0:
logging.debug("lock not taken")
break
lock_was_taken = True
The function apt_pkg.get_lock() either returns a file descriptor, or -1 on an
error.
File descriptors are just C file descriptors, so they are always positive
integers.
The code should check the result to be negative, not positive. I have
attached a patch
to reverse the logic.
Additional information:
1)
Description: Ubuntu 16.04.1 LTS
Release: 16.04
2)
unattended-upgrades:
Installed: 0.90ubuntu0.3
Candidate: 0.90ubuntu0.3
Version table:
*** 0.90ubuntu0.3 500
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64
Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main i386
Packages
100 /var/lib/dpkg/status
0.90 500
500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial/main i386 Packages
3)
Fast reboot
4)
Very slow reboot (after a 10 minutes timeout)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1654600/+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 1654600] Re: unattended-upgrade-shutdown hangs when /var is a separate filesystem
** Tags added: sts-sru-needed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
https://bugs.launchpad.net/bugs/1654600
Title:
unattended-upgrade-shutdown hangs when /var is a separate filesystem
Status in unattended-upgrades package in Ubuntu:
In Progress
Status in unattended-upgrades source package in Xenial:
Triaged
Status in unattended-upgrades source package in Yakkety:
Triaged
Status in unattended-upgrades package in Debian:
New
Bug description:
[SRU justification]
This fix is needed to make sure that the system does not hang on shutdown
when /var is a speparate file system
[Impact]
System can hang up to 10 minutes if not fixed.
[Fix]
Change the systemd unit's ExecStart to an ExecStop so the unit is correctly
sequenced.
[Test Case]
In a VM with /var separated from the / file system, shutdown the VM. It will
hang for 10 minutes
[Regression]
None to be expected. A ExecStop unit will be sequenced before the Before=
units which is earlier than previously.
[Original description of the problem]
The systemd unit file unattended-upgrades.service is used to stop a running
unattended-upgrade
process during shutdown. This unit file is running together with all
filesystem
unmount services.
The unattended-upgrades service checks if the lockfile for unattended-upgrade
(in /var/run) exists, and if it does, there is an unattended-upgrade in
progress
and the service will wait until it finishes (and therefore automatically wait
at
shutdown).
However, if /var is a separate filesystem, it will get unmounted even though
/var/run
is a tmpfs that's still mounted on top of the /var/run directory in the /var
filesystem.
The unattended-upgrade script will fail to find lockfile, sleeps for 5
seconds, and
tries to check the lockfile again. After 10 minutes (the default timeout), it
will finally
exit and the system will continue shutdown.
The problem is the error handling in
/usr/share/unattended-upgrades/unattended-upgrade-shutdown
where it tries to lock itself:
while True:
res = apt_pkg.get_lock(options.lock_file)
logging.debug("get_lock returned %i" % res)
# exit here if there is no lock
if res > 0:
logging.debug("lock not taken")
break
lock_was_taken = True
The function apt_pkg.get_lock() either returns a file descriptor, or -1 on an
error.
File descriptors are just C file descriptors, so they are always positive
integers.
The code should check the result to be negative, not positive. I have
attached a patch
to reverse the logic.
Additional information:
1)
Description: Ubuntu 16.04.1 LTS
Release: 16.04
2)
unattended-upgrades:
Installed: 0.90ubuntu0.3
Candidate: 0.90ubuntu0.3
Version table:
*** 0.90ubuntu0.3 500
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64
Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main i386
Packages
100 /var/lib/dpkg/status
0.90 500
500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial/main i386 Packages
3)
Fast reboot
4)
Very slow reboot (after a 10 minutes timeout)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1654600/+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 1668639] Re: Add a trigger to reload rsyslog when a new configuration file is dropped in /etc/rsyslog.d
Too late now for sponsorship to Zesty. Since it will come with the next rsyslog merge in 8.24.0-1, well go forward with the SRU post-merge of the next rsyslog -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1668639 Title: Add a trigger to reload rsyslog when a new configuration file is dropped in /etc/rsyslog.d Status in rsyslog package in Ubuntu: New Status in rsyslog source package in Trusty: New Status in rsyslog source package in Xenial: New Status in rsyslog source package in Yakkety: New Status in rsyslog package in Debian: Fix Released Bug description: [Impact] Servers or cloud instances will not log important messages after initial deployment. Manual reboot or restart of services is necessary to get expected behaviour. [Test Case] 1) Install, enable and start haproxy 2) Observe that /etc/rsyslog.d/49-haproxy.conf is installed 3) Observe that /var/lib/haproxy/dev/log and /var/log/haproxy.log is NOT created 4) Restart rsyslog service 5) Observe that /var/lib/haproxy/dev/log and /var/log/haproxy.log IS created 6) Restart haproxy service and observe that log now is filled with entries With the patched deb steps 3,4 and 6 becomes irrelevant and everything works out of the box. [Regression Potential] Minimal. This patch merges a patch from Debian where a trigger is added to the rsyslog package that fires when other debs drop files into /etc/rsyslog.d. [Original Bug Description] rsyslog should reload its configuration when other packages drop configuration in /etc/rsyslog.d https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791337 https://anonscm.debian.org/cgit/collab- maint/rsyslog.git/commit/?id=8d4074003f8fb19dae07c59dd19f0540a639210f To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1668639/+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 1679623] [NEW] Zesty : VPN connections appear grayed out - impossible to launch VPN connection from nm-applet
Public bug reported:
nm-applet display each configured VPN connection as greyed out so it is
impossible to launch any of the openVPN connection from the network
indicator.
It is still possible to enable the VPN connection using :
$ nmcli conn up {VPN}
ProblemType: Bug
DistroRelease: Ubuntu 17.04
Package: network-manager 1.4.4-1ubuntu3
ProcVersionSignature: Ubuntu 4.10.0-14.16-generic 4.10.3
Uname: Linux 4.10.0-14-generic x86_64
ApportVersion: 2.20.4-0ubuntu2
Architecture: amd64
CurrentDesktop: Unity:Unity7
Date: Tue Apr 4 12:45:27 2017
IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8)
InstallationDate: Installed on 2016-06-27 (281 days ago)
InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
NetworkManager.conf:
[main]
plugins=ifupdown,keyfile
[ifupdown]
managed=false
NetworkManager.state:
[main]
NetworkingEnabled=true
WirelessEnabled=true
WWANEnabled=false
SourcePackage: network-manager
UpgradeStatus: No upgrade log present (probably fresh install)
nmcli-nm:
RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW
WIFI WWAN-HW WWAN
running 1.4.4connecting starting none enabled enabled
enabled enabled disabled
** Affects: network-manager (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug zesty
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1679623
Title:
Zesty : VPN connections appear grayed out - impossible to launch VPN
connection from nm-applet
Status in network-manager package in Ubuntu:
New
Bug description:
nm-applet display each configured VPN connection as greyed out so it
is impossible to launch any of the openVPN connection from the network
indicator.
It is still possible to enable the VPN connection using :
$ nmcli conn up {VPN}
ProblemType: Bug
DistroRelease: Ubuntu 17.04
Package: network-manager 1.4.4-1ubuntu3
ProcVersionSignature: Ubuntu 4.10.0-14.16-generic 4.10.3
Uname: Linux 4.10.0-14-generic x86_64
ApportVersion: 2.20.4-0ubuntu2
Architecture: amd64
CurrentDesktop: Unity:Unity7
Date: Tue Apr 4 12:45:27 2017
IfupdownConfig: # interfaces(5) file used by ifup(8) and ifdown(8)
InstallationDate: Installed on 2016-06-27 (281 days ago)
InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64
(20160420.1)
NetworkManager.conf:
[main]
plugins=ifupdown,keyfile
[ifupdown]
managed=false
NetworkManager.state:
[main]
NetworkingEnabled=true
WirelessEnabled=true
WWANEnabled=false
SourcePackage: network-manager
UpgradeStatus: No upgrade log present (probably fresh install)
nmcli-nm:
RUNNING VERSION STATE STARTUP CONNECTIVITY NETWORKING WIFI-HW
WIFI WWAN-HW WWAN
running 1.4.4connecting starting none enabled enabled
enabled enabled disabled
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1679623/+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
Re: [Touch-packages] [Bug 1438510] Re: [REGRESSION] bluetooth headset no longer supports a2dp in 16.04 xenial and 16.10 yakkety
Hello, Le 03/04/2017 à 12:02, Konrad Zapałowicz a écrit : > Hey, to everyone interested we are currently testing and reviewing an > improvement to PA that fixes problems with selecting A2DP mode for BT > headsets. > > Right now it is being tested internally with good results for Sony > headsets, QC35 from Bose and BT speakers. Once it is in a silo/ppa I > will share this information for much wider testing. Then it will be > submitted as a SRU and will land in xenial. > I've been subscribed to this bug for ages & I'm still seeing this issue with my BT headset so I'd be more than happy to help you tests. Kind regards, ...Louis -- Louis Bouchard Software engineer, Cloud & Sustaining eng. Canonical Ltd Ubuntu developer Debian Maintainer GPG : 429D 7A3B DD05 B6F8 AF63 B9C4 8B3D 867C 823E 7A61 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1438510 Title: [REGRESSION] bluetooth headset no longer supports a2dp in 16.04 xenial and 16.10 yakkety Status in PulseAudio: Confirmed Status in bluez package in Ubuntu: Confirmed Status in pulseaudio package in Ubuntu: Confirmed Status in bluez source package in Vivid: Won't Fix Status in pulseaudio source package in Vivid: Won't Fix Bug description: Just installed 15.04 fresh from the latest ISO (beta2). I'm bummed to see my bluetooth headset (Bose Soundlink overear) seems to have regressed in functionality. In 14.10, I was able to set the output profile either to a2dp or hsp/hfp (telephony duplex). In 15.04, it only works in telephony duplex mode. I can't get high fidelity sound playback to work at all. This thread seems to be related, though the workaround within did not solve the problem for me: https://bbs.archlinux.org/viewtopic.php?id=194006 The bug is still present in 16.04 LTS and 16.10. To manage notifications about this bug go to: https://bugs.launchpad.net/pulseaudio/+bug/1438510/+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 1654600] Re: unattended-upgrade-shutdown hangs when /var is a separate filesystem
A quick update on this issue. I have a solution ready to fix this.
Unfortunately it requires changing the WantedBy= statement, which
triggers a deb-systemd-helper bug : https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=797108
This has the effect of leaving the service disabled after upgrade. I'm
working on fixing that.
** Bug watch added: Debian Bug tracker #797108
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797108
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
https://bugs.launchpad.net/bugs/1654600
Title:
unattended-upgrade-shutdown hangs when /var is a separate filesystem
Status in unattended-upgrades package in Ubuntu:
In Progress
Status in unattended-upgrades source package in Xenial:
Triaged
Status in unattended-upgrades source package in Yakkety:
Triaged
Status in unattended-upgrades package in Debian:
New
Bug description:
[SRU justification]
This fix is needed to make sure that the system does not hang on shutdown
when /var is a speparate file system
[Impact]
System can hang up to 10 minutes if not fixed.
[Fix]
Change the systemd unit's ExecStart to an ExecStop so the unit is correctly
sequenced.
[Test Case]
In a VM with /var separated from the / file system, shutdown the VM. It will
hang for 10 minutes
[Regression]
None to be expected. A ExecStop unit will be sequenced before the Before=
units which is earlier than previously.
[Original description of the problem]
The systemd unit file unattended-upgrades.service is used to stop a running
unattended-upgrade
process during shutdown. This unit file is running together with all
filesystem
unmount services.
The unattended-upgrades service checks if the lockfile for unattended-upgrade
(in /var/run) exists, and if it does, there is an unattended-upgrade in
progress
and the service will wait until it finishes (and therefore automatically wait
at
shutdown).
However, if /var is a separate filesystem, it will get unmounted even though
/var/run
is a tmpfs that's still mounted on top of the /var/run directory in the /var
filesystem.
The unattended-upgrade script will fail to find lockfile, sleeps for 5
seconds, and
tries to check the lockfile again. After 10 minutes (the default timeout), it
will finally
exit and the system will continue shutdown.
The problem is the error handling in
/usr/share/unattended-upgrades/unattended-upgrade-shutdown
where it tries to lock itself:
while True:
res = apt_pkg.get_lock(options.lock_file)
logging.debug("get_lock returned %i" % res)
# exit here if there is no lock
if res > 0:
logging.debug("lock not taken")
break
lock_was_taken = True
The function apt_pkg.get_lock() either returns a file descriptor, or -1 on an
error.
File descriptors are just C file descriptors, so they are always positive
integers.
The code should check the result to be negative, not positive. I have
attached a patch
to reverse the logic.
Additional information:
1)
Description: Ubuntu 16.04.1 LTS
Release: 16.04
2)
unattended-upgrades:
Installed: 0.90ubuntu0.3
Candidate: 0.90ubuntu0.3
Version table:
*** 0.90ubuntu0.3 500
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64
Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main i386
Packages
100 /var/lib/dpkg/status
0.90 500
500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial/main i386 Packages
3)
Fast reboot
4)
Very slow reboot (after a 10 minutes timeout)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1654600/+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 1447715] Re: dhclient -6: Can't bind to dhcp address: Cannot assign requested address
** Tags removed: sts-sru ** Tags added: sts-sru-done -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ifupdown in Ubuntu. https://bugs.launchpad.net/bugs/1447715 Title: dhclient -6: Can't bind to dhcp address: Cannot assign requested address Status in ifupdown package in Ubuntu: Fix Released Status in ifupdown source package in Xenial: Won't Fix Status in ifupdown package in Debian: Fix Released Bug description: [Impact] When using dhcpv6 configured via ifupdown, the interface's dhcp client fails to start at boot with the error: Can't bind to dhcp address: Cannot assign requested address This is because ifupdown doesn't wait, after bringing the interface up, for it to complete its link-local Duplicate Address Detection (DAD), and the dhcp client can't bind to the link-local address because it's still in "tentative" state (until DAD completes). This is fixed upstream in debian ifupdown in version 0.8.11 by adding '-tentative' to the /lib/ifupdown/wait-for-ll6.sh script; before the script was only waiting for the link-local address to appear, now it waits until the link-local address appears and is not in 'tentative' state. [Test Case] Configure an interface, using ifupdown, with dhcpv6 (e.g. iface eth0 inet6 dhcp) and reboot. It will fail to get a dhcp address during boot. [Regression Potential] None [Other Info] After upgrading to Ubuntu 15.04 my computer is unable to obtain an IPv6 address via DHCPv6. The root cause is that dhclient is exiting with the following message: - Can't bind to dhcp address: Cannot assign requested address Please make sure there is no other dhcp server running and that there's no entry for dhcp or bootp in /etc/inetd.conf. Also make sure you are not running HP JetAdmin software, which includes a bootp server. If you think you have received this message due to a bug rather than a configuration issue please read the section on submitting bugs on either our web page at www.isc.org or in the README file before submitting a bug. These pages explain the proper process and the information we find helpful for debugging.. exiting. - The problem seems to exist in isc-dhcp-client 4.3.1-5ubuntu2 (15.04 version) because downgrading to isc-dhcp-client 4.2.4-7ubuntu14 (14.10 version) allows me to obtain an address. NetworkManager is the one launching dhclient. The two invocations (one for IPv4 and one for IPv6) are: dhclient_start(): running: /sbin/dhclient -d -q -sf /usr/lib/NetworkManager/nm-dhcp-helper -pf /run/sendsigs.omit.d /network-manager.dhclient-eth0.pid -lf /var/lib/NetworkManager /dhclient-c0a3dfde-5c0b-4cef-9c3b-563cfb1fb9d2-eth0.lease -cf /var/lib/NetworkManager/dhclient-eth0.conf eth0 dhclient_start(): running: /sbin/dhclient -d -q -6 -N -sf /usr/lib/NetworkManager/nm-dhcp-helper -pf /run/sendsigs.omit.d /network-manager.dhclient6-eth0.pid -lf /var/lib/NetworkManager/dhclient6-c0a3dfde-5c0b-4cef-9c3b- 563cfb1fb9d2-eth0.lease -cf /var/lib/NetworkManager/dhclient6-eth0.conf eth0 I do not see anything suspicious with the way both dhclients are invoked. Given that a downgrade allows me to obtain an IPv6 address I think this might be a bug in the ISC DHCP client rather than in NetworkManager. Related Bugs: * bug 1633479: dhclient does not wait for ipv6 dad (duplicate address detection) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1447715/+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 1642903] Re: introduce disk/by-id (model_serial) symlinks for NVMe drives
** Tags removed: sts-sru ** Tags added: sts-sru-done -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1642903 Title: introduce disk/by-id (model_serial) symlinks for NVMe drives Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Trusty: Fix Released Status in systemd source package in Xenial: Fix Released Status in systemd source package in Yakkety: Fix Released Status in systemd source package in Zesty: Fix Released Bug description: [Impact] NVMe drives can't be identified/accessed via /dev/disk/by-id/nvme- SERIAL symlinks. [Test Case] On a system with an NVMe drive, check the /dev/disk/by-id/ directory; with the patch, it will contain link(s) named by the drive serial number. This should be the *only* change in `ls -l /dev/disk/*/*`. On a system without NVMe, verify that `ls -l /dev/disk/*/*` is identical (aside from dates, of course) before and after the upgrade to the -proposed version. [Regression Potential] Errors in udev rules can lead to an unbootable or otherwise completely broken system if they unintentionally break or clobber existing /dev/disks/ symlinks. [Other Info] This patch is already included upstream and in zesty systemd. Related bugs: * bug 1647485: NVMe symlinks broken by devices with spaces in model or serial strings * bug 1651602: NVMe driver regression for non-smp/1-cpu systems * bug 1649635: export nvme drive model/serial strings via sysfs (trusty) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1642903/+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 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings
** Tags removed: sts-sru
** Tags added: sts-sru-done
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1647485
Title:
NVMe symlinks broken by devices with spaces in model or serial strings
Status in maas-images:
Fix Released
Status in systemd:
New
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Trusty:
Fix Released
Status in systemd source package in Xenial:
Fix Released
Status in systemd source package in Yakkety:
Fix Released
Status in systemd source package in Zesty:
Fix Released
Status in systemd package in Debian:
Fix Released
Bug description:
[Impact]
After including the patch from bug 1642903, NVMe devices that include spaces
in their model or serial strings result in incorrect symlinks, e.g. if the
model string is "XYZ Corp NVMe drive" then instead of creating:
/dev/disk/by-id/nvme-XYZ Corp NVMe drive_SERIAL -> ../../nvme0n1
it creates:
/dev/disk/by-id/nvme-XYZ -> ../../nvme0n1
/dev/Corp -> nvme0n1
/dev/NVMe -> nvme0n1
/dev/drive_SERIAL -> nvme0n1
This is because of the way udev handles the SYMLINK value strings; by
default, it does not do any whitespace replacement. To enable
whitespace replacement of a symlink value, the rule must also include
OPTIONS+="string_escape=replace". This is done for 'md' and 'dm'
devices in their rules. However, there are no rules that actually
want to specify multiple symlinks, and defaulting to not replacing
whitespace makes no sense; instead, the default should be to replace
all whitespace in each symlink value, unless the rule explicitly
specifies OPTIONS+="string_escape=none".
[Test Case]
This assumes using udev with the patch from bug 1642903.
Without this patch, when using a NVMe drive that contains spaces in
its model and/or serial strings, check the /dev/disk/by-id/ directory.
It should contain a partially-correct symlink to the NVMe drive, with
the name up to the first space. All following space-separated parts
of the mode/serial string should have symlinks in the /dev/ directory.
This is the incorrect behavior.
With this patch, check the /dev/disk/by-id/ directory. It should
contain a fully-correct symlink to the NVMe drive, and no part of the
drive's model/serial number string should be a link in the /dev
directory.
An example of the correct/incorrect naming is in the Impact section.
There should be no other changes to any of the symlinks under /dev
before and after this patch. Typical locations for symlinks are
/dev/, /dev/disk/by-name/, /dev/disk/by-id/, /dev/disk/by-uuid/,
/dev/disk/by-label/
[Regression Potential]
Errors in udev rules can lead to an unbootable or otherwise completely
broken system if they unintentionally break or clobber existing
/dev/disks/ symlinks.
[Other Info]
This is also tracked with upstream systemd (udev) bug 4833:
https://github.com/systemd/systemd/issues/4833
Also note, this can be worked around in individual rules ONLY (i.e.
not fixed for all rules) by appending OPTIONS+="string_escape=replace"
to each of the NVMe rules with SYMLINK+="..." assignment, e.g.:
KERNEL=="nvme*[0-9]n*[0-9]", ENV{DEVTYPE}=="disk", ATTRS{model}=="?*",
ENV{ID_SERIAL_SHORT}=="?*",
ENV{ID_SERIAL}="$attr{model}_$env{ID_SERIAL_SHORT}", SYMLINK+="disk
/by-id/nvme-$env{ID_SERIAL}", OPTIONS+="string_escape=replace"
Related bugs:
* bug 1642903: introduce disk/by-id (model_serial) symlinks for NVMe drives
* bug 1651602: NVMe driver regression for non-smp/1-cpu systems
* bug 1649635: export nvme drive model/serial strings via sysfs (trusty)
To manage notifications about this bug go to:
https://bugs.launchpad.net/maas-images/+bug/1647485/+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 1665018] Re: client tools ignore -h option without port number
** Tags removed: sts-sru ** Tags added: sts-sru-done -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1665018 Title: client tools ignore -h option without port number Status in cups package in Ubuntu: Fix Released Status in cups source package in Trusty: Fix Released Bug description: [Impact] Prevents user from overriding default print server on cmdline if he's not aware of the fact that this bug may be overriden by giving a port number. [Test Case] 1. Setup 2 cups servers with a shared printer set as default destination: server1, server2. 2. On a trusty client try: export CUPS_SERVER=server1 lpstat -h server2 -H 3. Expected result: server2:631 4. Actual result: server1:631 (server given by CUPS_SERVER is used instead of the one given by -h option). [Regression Potential] Minimal. ipp_port is initialized to default value if not given explicitly. Fix is a backport from Xenial version and already present in upstream release. [Other Info] * Original bug description: Some commandline tools (e.g. lp, lpstat) ignore -h option if no port number is given. This version affects Trusty with cups-client 1.7.2-0ubuntu1.7. Xenial works fine. Test to reproduce: 1. Setup 2 cups servers with a shared printer set as default destination: server1, server2. 2. On a trusty client try: export CUPS_SERVER=server1 lpstat -h server2 -H 3. Expected result: server2:631 4. Actual result: server1:631 (server given by CUPS_SERVER is used instead of the one given by -h option). If a port number is given (e.g. server2:631) the commands work as expected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1665018/+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 1648901] Re: SPNEGO crash on mechanism failure
** Tags removed: sts-sru ** Tags added: sts-sru-done -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to krb5 in Ubuntu. https://bugs.launchpad.net/bugs/1648901 Title: SPNEGO crash on mechanism failure Status in krb5 package in Ubuntu: Fix Released Status in krb5 source package in Xenial: Fix Released Bug description: == SRU JUSTIFICATION == [Impact] * Chrome (and other things) crash (segfault) when Kerberos fails to authenticate. Thread 22 "Chrome_IOThread" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffdd687700 (LWP 14851)] spnego_gss_inquire_context (minor_status=0x7fffdd68573c, context_handle=0x0, src_name=0x7fffdd685670, targ_name=0x7fffdd685668, lifetime_rec=0x7fffdd685738, mech_type=0x7fffdd685660, ctx_flags=0x7fffdd685734, locally_initiated=0x7fffdd685730, opened=0x7fffdd68572c) at ../../../../src/lib/gssapi/spnego/spnego_mech.c:2315 2315 ../../../../src/lib/gssapi/spnego/spnego_mech.c: No such file or directory. (gdb) bt #0 spnego_gss_inquire_context (minor_status=0x7fffdd68573c, context_handle=0x0, src_name=0x7fffdd685670, targ_name=0x7fffdd685668, lifetime_rec=0x7fffdd685738, mech_type=0x7fffdd685660, ctx_flags=0x7fffdd685734, locally_initiated=0x7fffdd685730, opened=0x7fffdd68572c) at ../../../../src/lib/gssapi/spnego/spnego_mech.c:2315 #1 0x7fffef72be54 in gss_inquire_context (minor_status=0x7fffdd68573c, context_handle=, src_name=0x7fffdd685788, targ_name=0x7fffdd685750, lifetime_rec=0x7fffdd685738, mech_type=0x7fffdd685780, ctx_flags=0x7fffdd685734, locally_initiated=0x7fffdd685730, opened=0x7fffdd68572c) at ../../../../src/lib/gssapi/mechglue/g_inq_context.c:114 * context_handle=0x0, segfault occurs trying to dereference a null pointer. [Test Case] * Reproducer See dwmw2's (reporter of the bug) comment #3 : https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1648901/comments/3 [Regression Potential] * none expected Y and Z release already has the krb5 upstream patch. * Debian has the patch as well. * A test package has been tested by more than 1 user with success (can't reproduce the crash) anymore) [Other Info] * Upstream fix : https://github.com/krb5/krb5/commit/3beb564cea3d219efcf71682b6576cad548c2d23 * Pull Request : https://github.com/krb5/krb5/pull/385 * Chrome Bug : https://bugs.chromium.org/p/chromium/issues/detail?id=554905 * A test pkg including the upstream commit has been proven to fix the crash. See: https://bugs.launchpad.net/ubuntu/xenial/+source/krb5/+bug/1648901/comments/9 == [Original Description] Chrome (and other things) crash when Kerberos fails to authenticate: https://bugs.chromium.org/p/chromium/issues/detail?id=554905 This was fixed in MIT krb5 in January: https://github.com/krb5/krb5/pull/385 Thread 22 "Chrome_IOThread" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffdd687700 (LWP 14851)] spnego_gss_inquire_context (minor_status=0x7fffdd68573c, context_handle=0x0, src_name=0x7fffdd685670, targ_name=0x7fffdd685668, lifetime_rec=0x7fffdd685738, mech_type=0x7fffdd685660, ctx_flags=0x7fffdd685734, locally_initiated=0x7fffdd685730, opened=0x7fffdd68572c) at ../../../../src/lib/gssapi/spnego/spnego_mech.c:2315 2315 ../../../../src/lib/gssapi/spnego/spnego_mech.c: No such file or directory. (gdb) bt #0 spnego_gss_inquire_context (minor_status=0x7fffdd68573c, context_handle=0x0, src_name=0x7fffdd685670, targ_name=0x7fffdd685668, lifetime_rec=0x7fffdd685738, mech_type=0x7fffdd685660, ctx_flags=0x7fffdd685734, locally_initiated=0x7fffdd685730, opened=0x7fffdd68572c) at ../../../../src/lib/gssapi/spnego/spnego_mech.c:2315 #1 0x7fffef72be54 in gss_inquire_context (minor_status=0x7fffdd68573c, context_handle=, src_name=0x7fffdd685788, targ_name=0x7fffdd685750, lifetime_rec=0x7fffdd685738, mech_type=0x7fffdd685780, ctx_flags=0x7fffdd685734, locally_initiated=0x7fffdd685730, opened=0x7fffdd68572c) at ../../../../src/lib/gssapi/mechglue/g_inq_context.c:114 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1648901/+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 1654600] Re: unattended-upgrade-shutdown hangs when /var is a separate filesystem
Here is a recap of my work and current status : #1) when a system has a separated /var, the unit will hang since it is looking for /var/run to be present and it has been unmounted. #2) when using Unattended-Upgrade::InstallOnShutdown "true"; the upgrade never completes as the query to the online archive fails since the network is no longer available. #3) it is impossible to enable the unattended-upgrades.service unit. Here is an example : > $ systemctl status unattended-upgrades.service > ● unattended-upgrades.service - Unattended Upgrades Shutdown >Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; enabled; > vendor preset: enabled) >Active: inactive (dead) > Docs: man:unattended-upgrade(8) According to the doc[2], during shutdown, even if Before= or After= is used, the unit being started will only start after the Shutdown of its dependencies. Prior to the recent addition of local-fs.target network.target, the unit ran quickly enough for the /var to be still mounted. But even without these dependencies, InstallOnShutdown would fail with the following : > 2017-03-10 13:40:42,803 INFO Starting unattended upgrades script > 2017-03-10 13:40:42,803 INFO Allowed origins are: ['o=Ubuntu,a=zesty', > 'o=Ubuntu,a=zesty-security'] > 2017-03-10 13:41:40,554 ERROR An error occurred: 'Cannot initiate the > connection to 192.168.200.3:8000 (192.168.200.3). - connect (101: Network is > unreachable)' > 2017-03-10 13:41:40,555 ERROR The URI > 'http://fr.archive.ubuntu.com/ubuntu/pool/main/i/init-system-helpers/init-system-helpers_1.47_all.deb' > failed to download, aborting When trying to switch the unit to an ExecStop=, we find that the Stop never runs. This is caused by the fact that the unit is disabled (#3). Trying to enable the unit leads to : > # systemctl enable unattended-upgrades > Synchronizing state of unattended-upgrades.service with SysV service script > with /lib/systemd/systemd-sysv-install. > Executing: /lib/systemd/systemd-sysv-install enable unattended-upgrades > update-rc.d: error: unattended-upgrades Default-Start contains no runlevels, > aborting. Adding runlevels 2 3 4 5 fixes this then the unit can be enabled. So we get to a unit that looks like this : > [Unit] > Description=Unattended Upgrades Shutdown > DefaultDependencies=no > After=network.target local-fs.target > RequiresMountsFor=/var/run /var/log > Documentation=man:unattended-upgrade(8) > > [Service] > Type=oneshot > RemainAfterExit=yes > ExecStop=/usr/share/unattended-upgrades/unattended-upgrade-shutdown > TimeoutStopSec=900 > > [Install] > WantedBy=multi-user.target Before= is replaced by After= as, during shutdown otherwise the unit does not run. RequiresMountsFor= is added as both /var/log and /var/run are needed in order to run correctly. RemainAfterExit=yes is added so the unit appears as started. There is no longer a requirement to have an ExecStart present. WantedBy is switched to multi-user.target as on the way up, we do nothing and we are no longer depending on anything related to shutdown. Now this only works IF /var is a separate FS. The reason for that is the presence of DefaultDependencies=no. I don't think that it is required but was there in the initial unit. Removing it in the final unit fixes the only remaining issue. The unit is now : > [Unit] > Description=Unattended Upgrades Shutdown > After=network.target local-fs.target > RequiresMountsFor=/var/run /var/log > Documentation=man:unattended-upgrade(8) > > [Service] > Type=oneshot > RemainAfterExit=yes > ExecStop=/usr/share/unattended-upgrades/unattended-upgrade-shutdown > TimeoutStopSec=900 > > [Install] > WantedBy=multi-user.target This works correctly and has been tested on : - Xenial with and without /var as a separate FS - Zesty with and without /var as a separate FS InstallOnShutdown now also works as advertized. I am now getting confirmation on that change since it is a rather sensible modification. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1654600 Title: unattended-upgrade-shutdown hangs when /var is a separate filesystem Status in unattended-upgrades package in Ubuntu: In Progress Status in unattended-upgrades source package in Xenial: Triaged Status in unattended-upgrades source package in Yakkety: Triaged Status in unattended-upgrades package in Debian: New Bug description: [SRU justification] This fix is needed to make sure that the system does not hang on shutdown when /var is a speparate file system [Impact] System can hang up to 10 minutes if not fixed. [Fix] Change the systemd unit's ExecStart to an ExecStop so the unit is correctly sequenced. [Test Case] In a VM with /var separated from the / file system, shutdown the VM. It will hang for 10 minutes [Regression] None to be expected. A ExecStop unit will be sequenced before
[Touch-packages] [Bug 1654600] Re: unattended-upgrade-shutdown hangs when /var is a separate filesystem
Here is a recap of my day of work :
The unattended-upgrades.service unit never runs the ExecStop because it
is not enabled as we see here :
# systemctl status unattended-upgrades.service
● unattended-upgrades.service - Unattended Upgrades Shutdown
Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; enabled;
vendor preset: enabled)
Active: inactive (dead) <<<
Docs: man:unattended-upgrade(8)
This is caused by a missing "Default-Start" header in /etc/init.d
/unattended-upgrades. Trying to enable the unit leads to :
# systemctl enable unattended-upgrades.service
Synchronizing state of unattended-upgrades.service with SysV init with
/lib/systemd/systemd-sysv-install...
Executing /lib/systemd/systemd-sysv-install enable unattended-upgrades
update-rc.d: error: unattended-upgrades Default-Start contains no runlevels,
aborting.
I'm currently working on fixing all this in the packaging so we get a
correctly working unit after the upgrade of the package.
I have also reworked the unit :
[Unit]
Description=Unattended Upgrades Shutdown
DefaultDependencies=no
After=network.target local-fs.target
RequiresMountsFor=/var/log /var/run
Documentation=man:unattended-upgrade(8)
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStop=/usr/share/unattended-upgrades/unattended-upgrade-shutdown
TimeoutStopSec=900
[Install]
WantedBy=multi-user.target
With this configuration, the unit runs the ExecStop as expected. I also
tested using Unattended-Upgrade::InstallOnShutdown "true" and it works
as expected, which is to block the shutdown for upgrade with the network
being available.
I should have that available for testing tomorrow.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
https://bugs.launchpad.net/bugs/1654600
Title:
unattended-upgrade-shutdown hangs when /var is a separate filesystem
Status in unattended-upgrades package in Ubuntu:
In Progress
Status in unattended-upgrades source package in Xenial:
Triaged
Status in unattended-upgrades source package in Yakkety:
Triaged
Status in unattended-upgrades package in Debian:
New
Bug description:
[SRU justification]
This fix is needed to make sure that the system does not hang on shutdown
when /var is a speparate file system
[Impact]
System can hang up to 10 minutes if not fixed.
[Fix]
Change the systemd unit's ExecStart to an ExecStop so the unit is correctly
sequenced.
[Test Case]
In a VM with /var separated from the / file system, shutdown the VM. It will
hang for 10 minutes
[Regression]
None to be expected. A ExecStop unit will be sequenced before the Before=
units which is earlier than previously.
[Original description of the problem]
The systemd unit file unattended-upgrades.service is used to stop a running
unattended-upgrade
process during shutdown. This unit file is running together with all
filesystem
unmount services.
The unattended-upgrades service checks if the lockfile for unattended-upgrade
(in /var/run) exists, and if it does, there is an unattended-upgrade in
progress
and the service will wait until it finishes (and therefore automatically wait
at
shutdown).
However, if /var is a separate filesystem, it will get unmounted even though
/var/run
is a tmpfs that's still mounted on top of the /var/run directory in the /var
filesystem.
The unattended-upgrade script will fail to find lockfile, sleeps for 5
seconds, and
tries to check the lockfile again. After 10 minutes (the default timeout), it
will finally
exit and the system will continue shutdown.
The problem is the error handling in
/usr/share/unattended-upgrades/unattended-upgrade-shutdown
where it tries to lock itself:
while True:
res = apt_pkg.get_lock(options.lock_file)
logging.debug("get_lock returned %i" % res)
# exit here if there is no lock
if res > 0:
logging.debug("lock not taken")
break
lock_was_taken = True
The function apt_pkg.get_lock() either returns a file descriptor, or -1 on an
error.
File descriptors are just C file descriptors, so they are always positive
integers.
The code should check the result to be negative, not positive. I have
attached a patch
to reverse the logic.
Additional information:
1)
Description: Ubuntu 16.04.1 LTS
Release: 16.04
2)
unattended-upgrades:
Installed: 0.90ubuntu0.3
Candidate: 0.90ubuntu0.3
Version table:
*** 0.90ubuntu0.3 500
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64
Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main i386
Packages
100 /var/lib/dpkg/status
0.90 500
500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial/main i386 Packages
3)
[Touch-packages] [Bug 1654600] Re: unattended-upgrade-shutdown hangs when /var is a separate filesystem
** Changed in: unattended-upgrades (Ubuntu)
Status: Fix Released => In Progress
** Changed in: unattended-upgrades (Ubuntu Xenial)
Status: Fix Committed => Triaged
** Changed in: unattended-upgrades (Ubuntu Yakkety)
Status: Fix Committed => Triaged
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
https://bugs.launchpad.net/bugs/1654600
Title:
unattended-upgrade-shutdown hangs when /var is a separate filesystem
Status in unattended-upgrades package in Ubuntu:
In Progress
Status in unattended-upgrades source package in Xenial:
Triaged
Status in unattended-upgrades source package in Yakkety:
Triaged
Status in unattended-upgrades package in Debian:
New
Bug description:
[SRU justification]
This fix is needed to make sure that the system does not hang on shutdown
when /var is a speparate file system
[Impact]
System can hang up to 10 minutes if not fixed.
[Fix]
Change the systemd unit's ExecStart to an ExecStop so the unit is correctly
sequenced.
[Test Case]
In a VM with /var separated from the / file system, shutdown the VM. It will
hang for 10 minutes
[Regression]
None to be expected. A ExecStop unit will be sequenced before the Before=
units which is earlier than previously.
[Original description of the problem]
The systemd unit file unattended-upgrades.service is used to stop a running
unattended-upgrade
process during shutdown. This unit file is running together with all
filesystem
unmount services.
The unattended-upgrades service checks if the lockfile for unattended-upgrade
(in /var/run) exists, and if it does, there is an unattended-upgrade in
progress
and the service will wait until it finishes (and therefore automatically wait
at
shutdown).
However, if /var is a separate filesystem, it will get unmounted even though
/var/run
is a tmpfs that's still mounted on top of the /var/run directory in the /var
filesystem.
The unattended-upgrade script will fail to find lockfile, sleeps for 5
seconds, and
tries to check the lockfile again. After 10 minutes (the default timeout), it
will finally
exit and the system will continue shutdown.
The problem is the error handling in
/usr/share/unattended-upgrades/unattended-upgrade-shutdown
where it tries to lock itself:
while True:
res = apt_pkg.get_lock(options.lock_file)
logging.debug("get_lock returned %i" % res)
# exit here if there is no lock
if res > 0:
logging.debug("lock not taken")
break
lock_was_taken = True
The function apt_pkg.get_lock() either returns a file descriptor, or -1 on an
error.
File descriptors are just C file descriptors, so they are always positive
integers.
The code should check the result to be negative, not positive. I have
attached a patch
to reverse the logic.
Additional information:
1)
Description: Ubuntu 16.04.1 LTS
Release: 16.04
2)
unattended-upgrades:
Installed: 0.90ubuntu0.3
Candidate: 0.90ubuntu0.3
Version table:
*** 0.90ubuntu0.3 500
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64
Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main i386
Packages
100 /var/lib/dpkg/status
0.90 500
500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial/main i386 Packages
3)
Fast reboot
4)
Very slow reboot (after a 10 minutes timeout)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1654600/+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 1654600] Re: unattended-upgrade-shutdown hangs when /var is a separate filesystem
@sergei-franco:
>From what I can tell, it works for you because changing the unit the way
you did simply disable execution of the unit. When running with such a
configuration either on Xenial or Zesty, I do not see any mention of
"Unattended Upgrades Shutdown" in the console output.
When limiting to "After=network.target local-fs.target", I see the unit
being started (which is basically a NOOP) but not stopping which is what
we want.
I'm continuing my tests
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
https://bugs.launchpad.net/bugs/1654600
Title:
unattended-upgrade-shutdown hangs when /var is a separate filesystem
Status in unattended-upgrades package in Ubuntu:
Fix Released
Status in unattended-upgrades source package in Xenial:
Fix Committed
Status in unattended-upgrades source package in Yakkety:
Fix Committed
Status in unattended-upgrades package in Debian:
New
Bug description:
[SRU justification]
This fix is needed to make sure that the system does not hang on shutdown
when /var is a speparate file system
[Impact]
System can hang up to 10 minutes if not fixed.
[Fix]
Change the systemd unit's ExecStart to an ExecStop so the unit is correctly
sequenced.
[Test Case]
In a VM with /var separated from the / file system, shutdown the VM. It will
hang for 10 minutes
[Regression]
None to be expected. A ExecStop unit will be sequenced before the Before=
units which is earlier than previously.
[Original description of the problem]
The systemd unit file unattended-upgrades.service is used to stop a running
unattended-upgrade
process during shutdown. This unit file is running together with all
filesystem
unmount services.
The unattended-upgrades service checks if the lockfile for unattended-upgrade
(in /var/run) exists, and if it does, there is an unattended-upgrade in
progress
and the service will wait until it finishes (and therefore automatically wait
at
shutdown).
However, if /var is a separate filesystem, it will get unmounted even though
/var/run
is a tmpfs that's still mounted on top of the /var/run directory in the /var
filesystem.
The unattended-upgrade script will fail to find lockfile, sleeps for 5
seconds, and
tries to check the lockfile again. After 10 minutes (the default timeout), it
will finally
exit and the system will continue shutdown.
The problem is the error handling in
/usr/share/unattended-upgrades/unattended-upgrade-shutdown
where it tries to lock itself:
while True:
res = apt_pkg.get_lock(options.lock_file)
logging.debug("get_lock returned %i" % res)
# exit here if there is no lock
if res > 0:
logging.debug("lock not taken")
break
lock_was_taken = True
The function apt_pkg.get_lock() either returns a file descriptor, or -1 on an
error.
File descriptors are just C file descriptors, so they are always positive
integers.
The code should check the result to be negative, not positive. I have
attached a patch
to reverse the logic.
Additional information:
1)
Description: Ubuntu 16.04.1 LTS
Release: 16.04
2)
unattended-upgrades:
Installed: 0.90ubuntu0.3
Candidate: 0.90ubuntu0.3
Version table:
*** 0.90ubuntu0.3 500
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64
Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main i386
Packages
100 /var/lib/dpkg/status
0.90 500
500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial/main i386 Packages
3)
Fast reboot
4)
Very slow reboot (after a 10 minutes timeout)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1654600/+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 1654600] Re: unattended-upgrade-shutdown hangs when /var is a separate filesystem
@kay-diam:
I get what you mean. I also use KVM to debug the issue.
I'm going to switch to verification-failed to this one does not get
released and push the investigation further as there is another issue
that side-tracked me :
If Unattended-Upgrade::InstallOnShutdown is set to "true", it will still
fail as the network will no longer be available when it gets to access
the archive so this must also be fixed.
...Louis
** Tags removed: verification-needed
** Tags added: verification-failed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
https://bugs.launchpad.net/bugs/1654600
Title:
unattended-upgrade-shutdown hangs when /var is a separate filesystem
Status in unattended-upgrades package in Ubuntu:
Fix Released
Status in unattended-upgrades source package in Xenial:
Fix Committed
Status in unattended-upgrades source package in Yakkety:
Fix Committed
Status in unattended-upgrades package in Debian:
New
Bug description:
[SRU justification]
This fix is needed to make sure that the system does not hang on shutdown
when /var is a speparate file system
[Impact]
System can hang up to 10 minutes if not fixed.
[Fix]
Change the systemd unit's ExecStart to an ExecStop so the unit is correctly
sequenced.
[Test Case]
In a VM with /var separated from the / file system, shutdown the VM. It will
hang for 10 minutes
[Regression]
None to be expected. A ExecStop unit will be sequenced before the Before=
units which is earlier than previously.
[Original description of the problem]
The systemd unit file unattended-upgrades.service is used to stop a running
unattended-upgrade
process during shutdown. This unit file is running together with all
filesystem
unmount services.
The unattended-upgrades service checks if the lockfile for unattended-upgrade
(in /var/run) exists, and if it does, there is an unattended-upgrade in
progress
and the service will wait until it finishes (and therefore automatically wait
at
shutdown).
However, if /var is a separate filesystem, it will get unmounted even though
/var/run
is a tmpfs that's still mounted on top of the /var/run directory in the /var
filesystem.
The unattended-upgrade script will fail to find lockfile, sleeps for 5
seconds, and
tries to check the lockfile again. After 10 minutes (the default timeout), it
will finally
exit and the system will continue shutdown.
The problem is the error handling in
/usr/share/unattended-upgrades/unattended-upgrade-shutdown
where it tries to lock itself:
while True:
res = apt_pkg.get_lock(options.lock_file)
logging.debug("get_lock returned %i" % res)
# exit here if there is no lock
if res > 0:
logging.debug("lock not taken")
break
lock_was_taken = True
The function apt_pkg.get_lock() either returns a file descriptor, or -1 on an
error.
File descriptors are just C file descriptors, so they are always positive
integers.
The code should check the result to be negative, not positive. I have
attached a patch
to reverse the logic.
Additional information:
1)
Description: Ubuntu 16.04.1 LTS
Release: 16.04
2)
unattended-upgrades:
Installed: 0.90ubuntu0.3
Candidate: 0.90ubuntu0.3
Version table:
*** 0.90ubuntu0.3 500
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64
Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main i386
Packages
100 /var/lib/dpkg/status
0.90 500
500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial/main i386 Packages
3)
Fast reboot
4)
Very slow reboot (after a 10 minutes timeout)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1654600/+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 1654600] Re: unattended-upgrade-shutdown hangs when /var is a separate filesystem
@kay-diam
I don't understand your statement. The unit clearly get started. This is
from your log :
[ OK ] Stopped target Local File Systems.
[ OK ] Started Unattended Upgrades Shutdown. <<<
Unmounting /run/user/1000...
Unmounting /tmp...
[ OK ] Stopped Apply Kernel Variables.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
https://bugs.launchpad.net/bugs/1654600
Title:
unattended-upgrade-shutdown hangs when /var is a separate filesystem
Status in unattended-upgrades package in Ubuntu:
Fix Released
Status in unattended-upgrades source package in Xenial:
Fix Committed
Status in unattended-upgrades source package in Yakkety:
Fix Committed
Status in unattended-upgrades package in Debian:
New
Bug description:
[SRU justification]
This fix is needed to make sure that the system does not hang on shutdown
when /var is a speparate file system
[Impact]
System can hang up to 10 minutes if not fixed.
[Fix]
Change the systemd unit's ExecStart to an ExecStop so the unit is correctly
sequenced.
[Test Case]
In a VM with /var separated from the / file system, shutdown the VM. It will
hang for 10 minutes
[Regression]
None to be expected. A ExecStop unit will be sequenced before the Before=
units which is earlier than previously.
[Original description of the problem]
The systemd unit file unattended-upgrades.service is used to stop a running
unattended-upgrade
process during shutdown. This unit file is running together with all
filesystem
unmount services.
The unattended-upgrades service checks if the lockfile for unattended-upgrade
(in /var/run) exists, and if it does, there is an unattended-upgrade in
progress
and the service will wait until it finishes (and therefore automatically wait
at
shutdown).
However, if /var is a separate filesystem, it will get unmounted even though
/var/run
is a tmpfs that's still mounted on top of the /var/run directory in the /var
filesystem.
The unattended-upgrade script will fail to find lockfile, sleeps for 5
seconds, and
tries to check the lockfile again. After 10 minutes (the default timeout), it
will finally
exit and the system will continue shutdown.
The problem is the error handling in
/usr/share/unattended-upgrades/unattended-upgrade-shutdown
where it tries to lock itself:
while True:
res = apt_pkg.get_lock(options.lock_file)
logging.debug("get_lock returned %i" % res)
# exit here if there is no lock
if res > 0:
logging.debug("lock not taken")
break
lock_was_taken = True
The function apt_pkg.get_lock() either returns a file descriptor, or -1 on an
error.
File descriptors are just C file descriptors, so they are always positive
integers.
The code should check the result to be negative, not positive. I have
attached a patch
to reverse the logic.
Additional information:
1)
Description: Ubuntu 16.04.1 LTS
Release: 16.04
2)
unattended-upgrades:
Installed: 0.90ubuntu0.3
Candidate: 0.90ubuntu0.3
Version table:
*** 0.90ubuntu0.3 500
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64
Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main i386
Packages
100 /var/lib/dpkg/status
0.90 500
500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial/main i386 Packages
3)
Fast reboot
4)
Very slow reboot (after a 10 minutes timeout)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1654600/+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 1654600] Re: unattended-upgrade-shutdown hangs when /var is a separate filesystem
** Description changed:
+ [SRU justification]
+ This fix is needed to make sure that the system does not hang on shutdown
when /var is a speparate file system
+
+ [Impact]
+ System can hang up to 10 minutes if not fixed.
+
+ [Fix]
+ Change the systemd unit's ExecStart to an ExecStop so the unit is correctly
sequenced.
+
+ [Test Case]
+ In a VM with /var separated from the / file system, shutdown the VM. It will
hang for 10 minutes
+
+ [Regression]
+ None to be expected. A ExecStop unit will be sequenced before the Before=
units which is earlier than previously.
+
+ [Original description of the problem]
The systemd unit file unattended-upgrades.service is used to stop a running
unattended-upgrade
process during shutdown. This unit file is running together with all
filesystem
unmount services.
The unattended-upgrades service checks if the lockfile for unattended-upgrade
(in /var/run) exists, and if it does, there is an unattended-upgrade in
progress
and the service will wait until it finishes (and therefore automatically wait
at
shutdown).
However, if /var is a separate filesystem, it will get unmounted even though
/var/run
is a tmpfs that's still mounted on top of the /var/run directory in the /var
filesystem.
The unattended-upgrade script will fail to find lockfile, sleeps for 5
seconds, and
tries to check the lockfile again. After 10 minutes (the default timeout), it
will finally
exit and the system will continue shutdown.
The problem is the error handling in
/usr/share/unattended-upgrades/unattended-upgrade-shutdown
where it tries to lock itself:
- while True:
- res = apt_pkg.get_lock(options.lock_file)
- logging.debug("get_lock returned %i" % res)
- # exit here if there is no lock
- if res > 0:
- logging.debug("lock not taken")
- break
- lock_was_taken = True
+ while True:
+ res = apt_pkg.get_lock(options.lock_file)
+ logging.debug("get_lock returned %i" % res)
+ # exit here if there is no lock
+ if res > 0:
+ logging.debug("lock not taken")
+ break
+ lock_was_taken = True
The function apt_pkg.get_lock() either returns a file descriptor, or -1 on an
error.
File descriptors are just C file descriptors, so they are always positive
integers.
The code should check the result to be negative, not positive. I have
attached a patch
to reverse the logic.
Additional information:
1)
Description: Ubuntu 16.04.1 LTS
Release: 16.04
2)
unattended-upgrades:
- Installed: 0.90ubuntu0.3
- Candidate: 0.90ubuntu0.3
- Version table:
- *** 0.90ubuntu0.3 500
- 500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64
Packages
- 500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main i386
Packages
- 100 /var/lib/dpkg/status
- 0.90 500
- 500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
- 500 http://nl.archive.ubuntu.com/ubuntu xenial/main i386 Packages
+ Installed: 0.90ubuntu0.3
+ Candidate: 0.90ubuntu0.3
+ Version table:
+ *** 0.90ubuntu0.3 500
+ 500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64
Packages
+ 500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main i386
Packages
+ 100 /var/lib/dpkg/status
+ 0.90 500
+ 500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
+ 500 http://nl.archive.ubuntu.com/ubuntu xenial/main i386 Packages
3)
Fast reboot
4)
Very slow reboot (after a 10 minutes timeout)
** Changed in: unattended-upgrades (Ubuntu Xenial)
Status: Confirmed => In Progress
** Changed in: unattended-upgrades (Ubuntu Yakkety)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
https://bugs.launchpad.net/bugs/1654600
Title:
unattended-upgrade-shutdown hangs when /var is a separate filesystem
Status in unattended-upgrades package in Ubuntu:
Fix Released
Status in unattended-upgrades source package in Xenial:
In Progress
Status in unattended-upgrades source package in Yakkety:
In Progress
Status in unattended-upgrades package in Debian:
New
Bug description:
[SRU justification]
This fix is needed to make sure that the system does not hang on shutdown
when /var is a speparate file system
[Impact]
System can hang up to 10 minutes if not fixed.
[Fix]
Change the systemd unit's ExecStart to an ExecStop so the unit is correctly
sequenced.
[Test Case]
In a VM with /var separated from the / file system, shutdown the VM. It will
hang for 10 minutes
[Regression]
None to be expected. A ExecStop unit will be sequenced before the Before=
units which is earlier than previously.
[Original description of the problem]
The systemd unit file
[Touch-packages] [Bug 1654600] Re: unattended-upgrade-shutdown hangs when /var is a separate filesystem
** Changed in: unattended-upgrades (Ubuntu)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
https://bugs.launchpad.net/bugs/1654600
Title:
unattended-upgrade-shutdown hangs when /var is a separate filesystem
Status in unattended-upgrades package in Ubuntu:
In Progress
Status in unattended-upgrades source package in Xenial:
Confirmed
Status in unattended-upgrades source package in Yakkety:
Confirmed
Status in unattended-upgrades package in Debian:
New
Bug description:
The systemd unit file unattended-upgrades.service is used to stop a running
unattended-upgrade
process during shutdown. This unit file is running together with all
filesystem
unmount services.
The unattended-upgrades service checks if the lockfile for unattended-upgrade
(in /var/run) exists, and if it does, there is an unattended-upgrade in
progress
and the service will wait until it finishes (and therefore automatically wait
at
shutdown).
However, if /var is a separate filesystem, it will get unmounted even though
/var/run
is a tmpfs that's still mounted on top of the /var/run directory in the /var
filesystem.
The unattended-upgrade script will fail to find lockfile, sleeps for 5
seconds, and
tries to check the lockfile again. After 10 minutes (the default timeout), it
will finally
exit and the system will continue shutdown.
The problem is the error handling in
/usr/share/unattended-upgrades/unattended-upgrade-shutdown
where it tries to lock itself:
while True:
res = apt_pkg.get_lock(options.lock_file)
logging.debug("get_lock returned %i" % res)
# exit here if there is no lock
if res > 0:
logging.debug("lock not taken")
break
lock_was_taken = True
The function apt_pkg.get_lock() either returns a file descriptor, or -1 on an
error.
File descriptors are just C file descriptors, so they are always positive
integers.
The code should check the result to be negative, not positive. I have
attached a patch
to reverse the logic.
Additional information:
1)
Description: Ubuntu 16.04.1 LTS
Release: 16.04
2)
unattended-upgrades:
Installed: 0.90ubuntu0.3
Candidate: 0.90ubuntu0.3
Version table:
*** 0.90ubuntu0.3 500
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64
Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main i386
Packages
100 /var/lib/dpkg/status
0.90 500
500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial/main i386 Packages
3)
Fast reboot
4)
Very slow reboot (after a 10 minutes timeout)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1654600/+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 1661611] Re: apt/unattended-upgrades stalls shutdown
*** This bug is a duplicate of bug 1654600 *** https://bugs.launchpad.net/bugs/1654600 This is a duplicate of another bug I'm working on and is caused by a systemd ordering issue. ** This bug has been marked a duplicate of bug 1654600 unattended-upgrade-shutdown hangs when /var is a separate filesystem -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1661611 Title: apt/unattended-upgrades stalls shutdown Status in unattended-upgrades package in Ubuntu: Confirmed Bug description: When unattended-upgrades is installed, 9 out of 10 shutdowns/reboots hang while "starting unattended upgrades shutdown". This hang stalls the shutdown process for 5-10 mins. If I disable unnattended-upgrades via the /etc/apt/apt.conf.d/20auto- upgrades and/or 50unattended-upgrades, the problems occurs. If I terminate the service before shutdown/reboot (sudo service unattended-upgrades stop) the problem still occurs. If I remove the package (sudo apt remove unattended-upgrades) the problem no longer occurs. This occurs on a freshly installed version of Ubuntu Server 16.04.1 (both unattended-upgrades installed via install GUI or manual install of unattended-upgrades) Both Kern.log & syslog do not show the shutdown process (I believe because the filesystems have already unmounted) Original report: http://askubuntu.com/questions/878630/apt-unattended- upgrades-stalls-shutdown To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1661611/+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 1668639] Re: Add a trigger to reload rsyslog when a new configuration file is dropped in /etc/rsyslog.d
** Also affects: rsyslog (Ubuntu Trusty) Importance: Undecided Status: New ** Also affects: rsyslog (Ubuntu Yakkety) Importance: Undecided Status: New ** Also affects: rsyslog (Ubuntu Xenial) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1668639 Title: Add a trigger to reload rsyslog when a new configuration file is dropped in /etc/rsyslog.d Status in rsyslog package in Ubuntu: New Status in rsyslog source package in Trusty: New Status in rsyslog source package in Xenial: New Status in rsyslog source package in Yakkety: New Bug description: [Impact] Servers or cloud instances will not log important messages after initial deployment. Manual reboot or restart of services is necessary to get expected behaviour. [Test Case] 1) Install, enable and start haproxy 2) Observe that /etc/rsyslog.d/49-haproxy.conf is installed 3) Observe that /var/lib/haproxy/dev/log and /var/log/haproxy.log is NOT created 4) Restart rsyslog service 5) Observe that /var/lib/haproxy/dev/log and /var/log/haproxy.log IS created 6) Restart haproxy service and observe that log now is filled with entries With the patched deb steps 3,4 and 6 becomes irrelevant and everything works out of the box. [Regression Potential] Minimal. This patch merges a patch from Debian where a trigger is added to the rsyslog package that fires when other debs drop files into /etc/rsyslog.d. [Original Bug Description] rsyslog should reload its configuration when other packages drop configuration in /etc/rsyslog.d https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791337 https://anonscm.debian.org/cgit/collab- maint/rsyslog.git/commit/?id=8d4074003f8fb19dae07c59dd19f0540a639210f To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1668639/+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 1638695] Re: Python 2.7.12 performance regression
Here is the pastebin for better readability : http://paste.ubuntu.com/24078834/ -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python2.7 in Ubuntu. https://bugs.launchpad.net/bugs/1638695 Title: Python 2.7.12 performance regression Status in python2.7 package in Ubuntu: Confirmed Bug description: I work on the OpenStack-Ansible project and we've noticed that testing jobs on 16.04 take quite a bit longer to complete than on 14.04. They complete within an hour on 14.04 but they normally take 90 minutes or more on 16.04. We use the same version of Ansible with both versions of Ubuntu. After more digging, I tested python performance (using the 'performance' module) on 14.04 (2.7.6) and on 16.04 (2.7.12). There is a significant performance difference between each version of python. That is detailed in a spreadsheet[0]. I began using perf to dig into the differences when running the python performance module and when using Ansible playbooks. CPU migrations (as measured by perf) are doubled in Ubuntu 16.04 when running the same python workloads. I tried changing some of the kerne.sched sysctl configurables but they had very little effect on the results. I compiled python 2.7.12 from source on 14.04 and found the performance to be unchanged there. I'm not entirely sure where the problem might be now. We also have a bug open in OpenStack-Ansible[1] that provides additional detail. Thanks in advance for any help you can provide! [0] https://docs.google.com/spreadsheets/d/18MmptS_DAd1YP3OhHWQqLYVA9spC3xLt4PS3STI6tds/edit?usp=sharing [1] https://bugs.launchpad.net/openstack-ansible/+bug/1637494 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1638695/+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 1638695] Re: Python 2.7.12 performance regression
Following the results of the previous comparison, i've used Jorge's profiling example on the 'call_method' bench for trusty stock, no LTO, no PGO and Xenial stock, no PGO and no LTO. Here are the results. Notice the difference between Trusty Stock & Trusty nopgo, as opposed to the execution profiles of the other tests. Trusty Stock callgrind_annotate: Profiled target: /home/ubuntu/venv/cpython2.7-d0d7712d4e1d/bin/python /home/ubuntu/venv/cpython2.7-d0d7712d4e1d/li b/python2.7/site-packages/performance/benchmarks/bm_call_method.py --worker --pipe 4 --worker-task=0 --samples 3 -- warmups 1 --loops 1 --min-time 0.1 (PID 25150, part 1) 4,918,198,605 ???:PyEval_EvalFrameEx'2 [/home/ubuntu/venv/cpython2.7-d0d7712d4e1d/bin/python2.7] 1,180,507,700 ???:0x005368f0 [/home/ubuntu/venv/cpython2.7-d0d7712d4e1d/bin/python2.7] 1,109,707,368 ???:PyObject_GetAttr [/home/ubuntu/venv/cpython2.7-d0d7712d4e1d/bin/python2.7] 823,065,734 ???:PyFrame_New [/home/ubuntu/venv/cpython2.7-d0d7712d4e1d/bin/python2.7] 552,755,137 ???:0x004a5c90 [/home/ubuntu/venv/cpython2.7-d0d7712d4e1d/bin/python2.7] 525,836,692 ???:0x004bedf0 [/home/ubuntu/venv/cpython2.7-d0d7712d4e1d/bin/python2.7] 12,732,711 ???:PyParser_AddToken [/home/ubuntu/venv/cpython2.7-d0d7712d4e1d/bin/python2.7] 6,120,934 ???:PyDict_GetItem [/home/ubuntu/venv/cpython2.7-d0d7712d4e1d/bin/python2.7] 4,700,333 ???:0x004bc0e0 [/home/ubuntu/venv/cpython2.7-d0d7712d4e1d/bin/python2.7] 4,647,564 ???:0x004afe90'2 [/home/ubuntu/venv/cpython2.7-d0d7712d4e1d/bin/python2.7] 3,724,240 ???:PyObject_Free [/home/ubuntu/venv/cpython2.7-d0d7712d4e1d/bin/python2.7] 3,526,112 ???:PyDict_SetItem [/home/ubuntu/venv/cpython2.7-d0d7712d4e1d/bin/python2.7] 3,407,575 ???:0x00571fd0 [/home/ubuntu/venv/cpython2.7-d0d7712d4e1d/bin/python2.7] 3,304,198 ???:PyObject_Hash [/home/ubuntu/venv/cpython2.7-d0d7712d4e1d/bin/python2.7] 3,055,436 ???:0x005495a0 [/home/ubuntu/venv/cpython2.7-d0d7712d4e1d/bin/python2.7] 2,796,306 ???:0x00535070 [/home/ubuntu/venv/cpython2.7-d0d7712d4e1d/bin/python2.7] Trusty nopgo: = Profiled target: /home/ubuntu/venv/cpython2.7-d217262e7ee7/bin/python /home/ubuntu/venv/cpython2.7-d217262e7ee7/li b/python2.7/site-packages/performance/benchmarks/bm_call_method.py --worker --pipe 4 --worker-task=0 --samples 3 -- warmups 1 --loops 1 --min-time 0.1 (PID 28073, part 1) 5,362,602,828 ???:PyEval_EvalFrameEx'2 [/home/ubuntu/venv/cpython2.7-d217262e7ee7/bin/python2.7] 1,250,195,637 ???:0x00585e90 [/home/ubuntu/venv/cpython2.7-d217262e7ee7/bin/python2.7] 890,479,191 ???:PyFrame_New [/home/ubuntu/venv/cpython2.7-d217262e7ee7/bin/python2.7] 836,574,419 ???:PyObject_GenericGetAttr [/home/ubuntu/venv/cpython2.7-d217262e7ee7/bin/python2.7] 552,808,267 ???:0x0049ef00 [/home/ubuntu/venv/cpython2.7-d217262e7ee7/bin/python2.7] 539,318,922 ???:0x00493710 [/home/ubuntu/venv/cpython2.7-d217262e7ee7/bin/python2.7] 488,401,927 ???:_PyType_Lookup [/home/ubuntu/venv/cpython2.7-d217262e7ee7/bin/python2.7] 258,028,053 ???:PyObject_GetAttr [/home/ubuntu/venv/cpython2.7-d217262e7ee7/bin/python2.7] 12,247,026 ???:0x005937f0 [/home/ubuntu/venv/cpython2.7-d217262e7ee7/bin/python2.7] 11,727,983 ???:PyParser_AddToken [/home/ubuntu/venv/cpython2.7-d217262e7ee7/bin/python2.7] 6,409,083 ???:PyDict_GetItem [/home/ubuntu/venv/cpython2.7-d217262e7ee7/bin/python2.7] 4,948,165 ???:PyObject_Malloc [/home/ubuntu/venv/cpython2.7-d217262e7ee7/bin/python2.7] 4,746,403 ???:0x004f7b70'2 [/home/ubuntu/venv/cpython2.7-d217262e7ee7/bin/python2.7] 4,525,638 ???:PyNode_AddChild [/home/ubuntu/venv/cpython2.7-d217262e7ee7/bin/python2.7] 4,429,698 ???:PyObject_Free [/home/ubuntu/venv/cpython2.7-d217262e7ee7/bin/python2.7] 3,582,953 ???:0x0041aff0 [/home/ubuntu/venv/cpython2.7-d217262e7ee7/bin/python2.7] 3,240,230 ???:PyObject_Hash [/home/ubuntu/venv/cpython2.7-d217262e7ee7/bin/python2.7] Trusty nolto: = Profiled target: /home/ubuntu/venv/cpython2.7-d8da6ef977cc/bin/python2.7 /home/ubuntu/venv/cpython2.7-d8da6ef977cc /lib/python2.7/site-packages/performance/benchmarks/bm_call_method.py --worker --pipe 4 --worker-task=0 --samples 3 --warmups 1 --loops 1 --min-time 0.1 (PID 27353, part 1) 4,930,764,066 ???:PyEval_EvalFrameEx'2 [/home/ubuntu/venv/cpython2.7-d8da6ef977cc/bin/python2.7] 1,059,123,292 ???:0x00486370 [/home/ubuntu/venv/cpython2.7-d8da6ef977cc/bin/python2.7] 879,185,389 ???:PyObject_GetAttr [/home/ubuntu/venv/cpython2.7-d8da6ef977cc/bin/python2.7] 823,049,135 ???:PyFrame_New [/home/ubuntu/venv/cpython2.7-d8da6ef977cc/bin/python2.7] 552,712,907 ???:0x00477410 [/home/ubuntu/venv/cpython2.7-d8da6ef977cc/bin/python2.7] 539,326,714 ???:PyMethod_New
[Touch-packages] [Bug 1638695] Re: Python 2.7.12 performance regression
** Changed in: python2.7 (Ubuntu) Assignee: Jorge Niedbalski (niedbalski) => Louis Bouchard (louis-bouchard) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python2.7 in Ubuntu. https://bugs.launchpad.net/bugs/1638695 Title: Python 2.7.12 performance regression Status in python2.7 package in Ubuntu: Confirmed Bug description: I work on the OpenStack-Ansible project and we've noticed that testing jobs on 16.04 take quite a bit longer to complete than on 14.04. They complete within an hour on 14.04 but they normally take 90 minutes or more on 16.04. We use the same version of Ansible with both versions of Ubuntu. After more digging, I tested python performance (using the 'performance' module) on 14.04 (2.7.6) and on 16.04 (2.7.12). There is a significant performance difference between each version of python. That is detailed in a spreadsheet[0]. I began using perf to dig into the differences when running the python performance module and when using Ansible playbooks. CPU migrations (as measured by perf) are doubled in Ubuntu 16.04 when running the same python workloads. I tried changing some of the kerne.sched sysctl configurables but they had very little effect on the results. I compiled python 2.7.12 from source on 14.04 and found the performance to be unchanged there. I'm not entirely sure where the problem might be now. We also have a bug open in OpenStack-Ansible[1] that provides additional detail. Thanks in advance for any help you can provide! [0] https://docs.google.com/spreadsheets/d/18MmptS_DAd1YP3OhHWQqLYVA9spC3xLt4PS3STI6tds/edit?usp=sharing [1] https://bugs.launchpad.net/openstack-ansible/+bug/1637494 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1638695/+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 1638695] Re: Python 2.7.12 performance regression
Hello, Following doko's advice, I ran a set of test with PGO & LTO optimization disabled. Here are the results : https://docs.google.com/spreadsheets/d/1tTlEOvMypwKwi99XHjvuQFE14_jpBBLy0-Mk6bjkvL0/edit#gid=1169944329 This may bring more light to the investigation as it appear that with LTO & PGO optimisation disabled on Trusty, the trusty version becomes slower than the Xenial stock version. Disabling optimisation on Xenial makes little difference though. So maybe the PGO & LTO optimisation on Trusty is more efficient than on Xenial and leads to better results,hence better performance. Just a thought -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python2.7 in Ubuntu. https://bugs.launchpad.net/bugs/1638695 Title: Python 2.7.12 performance regression Status in python2.7 package in Ubuntu: Confirmed Bug description: I work on the OpenStack-Ansible project and we've noticed that testing jobs on 16.04 take quite a bit longer to complete than on 14.04. They complete within an hour on 14.04 but they normally take 90 minutes or more on 16.04. We use the same version of Ansible with both versions of Ubuntu. After more digging, I tested python performance (using the 'performance' module) on 14.04 (2.7.6) and on 16.04 (2.7.12). There is a significant performance difference between each version of python. That is detailed in a spreadsheet[0]. I began using perf to dig into the differences when running the python performance module and when using Ansible playbooks. CPU migrations (as measured by perf) are doubled in Ubuntu 16.04 when running the same python workloads. I tried changing some of the kerne.sched sysctl configurables but they had very little effect on the results. I compiled python 2.7.12 from source on 14.04 and found the performance to be unchanged there. I'm not entirely sure where the problem might be now. We also have a bug open in OpenStack-Ansible[1] that provides additional detail. Thanks in advance for any help you can provide! [0] https://docs.google.com/spreadsheets/d/18MmptS_DAd1YP3OhHWQqLYVA9spC3xLt4PS3STI6tds/edit?usp=sharing [1] https://bugs.launchpad.net/openstack-ansible/+bug/1637494 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1638695/+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 1638695] Re: Python 2.7.12 performance regression
Hello, The tests are run in LXC containers on a bare metal server with two physical CPU, 6 cores, 2 threads per core (Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz). Following's doko's advice, I have built two new versions, one with LTO optimisation disabled and the other one with PGO optimisation disabled. In both cases, it makes things worse. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python2.7 in Ubuntu. https://bugs.launchpad.net/bugs/1638695 Title: Python 2.7.12 performance regression Status in python2.7 package in Ubuntu: Confirmed Bug description: I work on the OpenStack-Ansible project and we've noticed that testing jobs on 16.04 take quite a bit longer to complete than on 14.04. They complete within an hour on 14.04 but they normally take 90 minutes or more on 16.04. We use the same version of Ansible with both versions of Ubuntu. After more digging, I tested python performance (using the 'performance' module) on 14.04 (2.7.6) and on 16.04 (2.7.12). There is a significant performance difference between each version of python. That is detailed in a spreadsheet[0]. I began using perf to dig into the differences when running the python performance module and when using Ansible playbooks. CPU migrations (as measured by perf) are doubled in Ubuntu 16.04 when running the same python workloads. I tried changing some of the kerne.sched sysctl configurables but they had very little effect on the results. I compiled python 2.7.12 from source on 14.04 and found the performance to be unchanged there. I'm not entirely sure where the problem might be now. We also have a bug open in OpenStack-Ansible[1] that provides additional detail. Thanks in advance for any help you can provide! [0] https://docs.google.com/spreadsheets/d/18MmptS_DAd1YP3OhHWQqLYVA9spC3xLt4PS3STI6tds/edit?usp=sharing [1] https://bugs.launchpad.net/openstack-ansible/+bug/1637494 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1638695/+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 1550983] Re: Fails to start with "Couldn't open libGL.so.1" (missing dependency?)
** Tags removed: sts-sponsor -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gtk+3.0 in Ubuntu. https://bugs.launchpad.net/bugs/1550983 Title: Fails to start with "Couldn't open libGL.so.1" (missing dependency?) Status in One Hundred Papercuts: Confirmed Status in gtk+3.0 package in Ubuntu: Fix Released Status in gtk+3.0 source package in Xenial: Fix Committed Status in gtk+3.0 source package in Yakkety: Fix Committed Status in gtk+3.0 package in Debian: Fix Released Bug description: [Impact] There are some unlinked calls to libGL.so.1 undetected in the build process because of using libepoxy. Running an application that does not depend on libgl1 (directly or indirectly) may lead to aborting the process with an undefined reference to libGL.so.1. [Test Case] 1. Deploy a server / cloud image of Xenial or Yakkety. 2. Use a Windows or a Mac client with Cygwin/X and ssh -XY to Ubuntu machine. 3. sudo apt install firefox; firefox Expected result: firefox is launched on the client machine. Actual result: "Couldn't open libGL.so.1" message is printed. [Regression Potential] Minimal, it is an upstream change already released to zesty. It performs a runtime check for GL support and disables GLX function calls in case they're not available. [Other Info] Original bug description: virt-manager fails to start: $ virt-manager --debug --no-fork [Sun, 28 Feb 2016 19:18:22 virt-manager 7592] DEBUG (cli:256) Launched with command line: /usr/share/virt-manager/virt-manager --debug --no-fork [Sun, 28 Feb 2016 19:18:22 virt-manager 7592] DEBUG (virt-manager:143) virt-manager version: 1.3.2 [Sun, 28 Feb 2016 19:18:22 virt-manager 7592] DEBUG (virt-manager:144) virtManager import: Couldn't open libGL.so.1: libGL.so.1: cannot open shared object file: No such file or directory $ Installing the 'libgl1-mesa-glx' package resolves the issue. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: virt-manager 1:1.3.2-0ubuntu1 ProcVersionSignature: Ubuntu 4.4.0-8.23-generic 4.4.2 Uname: Linux 4.4.0-8-generic x86_64 ApportVersion: 2.20-0ubuntu3 Architecture: amd64 Date: Sun Feb 28 19:19:27 2016 InstallationDate: Installed on 2016-02-27 (0 days ago) InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160206) PackageArchitecture: all SourcePackage: virt-manager UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/hundredpapercuts/+bug/1550983/+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 1647485] Re: NVMe symlinks broken by devices with spaces in model or serial strings
** Tags removed: sts-sponsor
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1647485
Title:
NVMe symlinks broken by devices with spaces in model or serial strings
Status in maas-images:
Fix Released
Status in systemd:
New
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Trusty:
Fix Released
Status in systemd source package in Xenial:
Fix Released
Status in systemd source package in Yakkety:
Fix Committed
Status in systemd source package in Zesty:
Fix Released
Status in systemd package in Debian:
Fix Released
Bug description:
[Impact]
After including the patch from bug 1642903, NVMe devices that include spaces
in their model or serial strings result in incorrect symlinks, e.g. if the
model string is "XYZ Corp NVMe drive" then instead of creating:
/dev/disk/by-id/nvme-XYZ Corp NVMe drive_SERIAL -> ../../nvme0n1
it creates:
/dev/disk/by-id/nvme-XYZ -> ../../nvme0n1
/dev/Corp -> nvme0n1
/dev/NVMe -> nvme0n1
/dev/drive_SERIAL -> nvme0n1
This is because of the way udev handles the SYMLINK value strings; by
default, it does not do any whitespace replacement. To enable
whitespace replacement of a symlink value, the rule must also include
OPTIONS+="string_escape=replace". This is done for 'md' and 'dm'
devices in their rules. However, there are no rules that actually
want to specify multiple symlinks, and defaulting to not replacing
whitespace makes no sense; instead, the default should be to replace
all whitespace in each symlink value, unless the rule explicitly
specifies OPTIONS+="string_escape=none".
[Test Case]
This assumes using udev with the patch from bug 1642903.
Without this patch, when using a NVMe drive that contains spaces in
its model and/or serial strings, check the /dev/disk/by-id/ directory.
It should contain a partially-correct symlink to the NVMe drive, with
the name up to the first space. All following space-separated parts
of the mode/serial string should have symlinks in the /dev/ directory.
This is the incorrect behavior.
With this patch, check the /dev/disk/by-id/ directory. It should
contain a fully-correct symlink to the NVMe drive, and no part of the
drive's model/serial number string should be a link in the /dev
directory.
An example of the correct/incorrect naming is in the Impact section.
There should be no other changes to any of the symlinks under /dev
before and after this patch. Typical locations for symlinks are
/dev/, /dev/disk/by-name/, /dev/disk/by-id/, /dev/disk/by-uuid/,
/dev/disk/by-label/
[Regression Potential]
Errors in udev rules can lead to an unbootable or otherwise completely
broken system if they unintentionally break or clobber existing
/dev/disks/ symlinks.
[Other Info]
This is also tracked with upstream systemd (udev) bug 4833:
https://github.com/systemd/systemd/issues/4833
Also note, this can be worked around in individual rules ONLY (i.e.
not fixed for all rules) by appending OPTIONS+="string_escape=replace"
to each of the NVMe rules with SYMLINK+="..." assignment, e.g.:
KERNEL=="nvme*[0-9]n*[0-9]", ENV{DEVTYPE}=="disk", ATTRS{model}=="?*",
ENV{ID_SERIAL_SHORT}=="?*",
ENV{ID_SERIAL}="$attr{model}_$env{ID_SERIAL_SHORT}", SYMLINK+="disk
/by-id/nvme-$env{ID_SERIAL}", OPTIONS+="string_escape=replace"
Related bugs:
* bug 1642903: introduce disk/by-id (model_serial) symlinks for NVMe drives
* bug 1651602: NVMe driver regression for non-smp/1-cpu systems
* bug 1649635: export nvme drive model/serial strings via sysfs (trusty)
To manage notifications about this bug go to:
https://bugs.launchpad.net/maas-images/+bug/1647485/+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 1666207] Re: Unable to create VPN connection on Zesty
This is not a bug, but seems to happen when some required fields are not yet filled. While the 'remote' field can be obvious,it is much less evident when the interface refuses to allow the configuration to be saved, because the certificate provided requires a password and the password field has been left blank. The UI should be more explicit on why it does not allow the configuration to be saved. Marking the bug as invalid ** Changed in: network-manager (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1666207 Title: Unable to create VPN connection on Zesty Status in network-manager package in Ubuntu: Invalid Bug description: When trying to create a new VPN connection with nm-connection-editor, the new connection cannot be saved and the editor issues the following error : LC_ALL="C" nm-connection-editor Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged. ** Message: Cannot save connection due to error: Editor initializing... ** Message: Cannot save connection due to error: Invalid setting VPN: remote dpkg -l | grep network-manager-gnome network-manager-gnome 1.4.2-1ubuntu2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1666207/+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 1666207] [NEW] Unable to create VPN connection on Zesty
Public bug reported: When trying to create a new VPN connection with nm-connection-editor, the new connection cannot be saved and the editor issues the following error : LC_ALL="C" nm-connection-editor Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged. ** Message: Cannot save connection due to error: Editor initializing... ** Message: Cannot save connection due to error: Invalid setting VPN: remote dpkg -l | grep network-manager-gnome network-manager-gnome 1.4.2-1ubuntu2 ** Affects: network-manager (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1666207 Title: Unable to create VPN connection on Zesty Status in network-manager package in Ubuntu: New Bug description: When trying to create a new VPN connection with nm-connection-editor, the new connection cannot be saved and the editor issues the following error : LC_ALL="C" nm-connection-editor Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged. ** Message: Cannot save connection due to error: Editor initializing... ** Message: Cannot save connection due to error: Invalid setting VPN: remote dpkg -l | grep network-manager-gnome network-manager-gnome 1.4.2-1ubuntu2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1666207/+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 1665018] Re: client tools ignore -h option without port number
** Also affects: cups (Ubuntu Trusty) Importance: Undecided Status: New ** Tags added: sts-sru -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1665018 Title: client tools ignore -h option without port number Status in cups package in Ubuntu: New Status in cups source package in Trusty: New Bug description: [Impact] Prevents user from overriding default print server on cmdline if he's not aware of the fact that this bug may be overriden by giving a port number. [Test Case] 1. Setup 2 cups servers with a shared printer set as default destination: server1, server2. 2. On a trusty client try: export CUPS_SERVER=server1 lpstat -h server2 -H 3. Expected result: server2:631 4. Actual result: server1:631 (server given by CUPS_SERVER is used instead of the one given by -h option). [Regression Potential] Minimal. ipp_port is initialized to default value if not given explicitly. Fix is a backport from Xenial version and already present in upstream release. [Other Info] * Original bug description: Some commandline tools (e.g. lp, lpstat) ignore -h option if no port number is given. This version affects Trusty with cups-client 1.7.2-0ubuntu1.7. Xenial works fine. Test to reproduce: 1. Setup 2 cups servers with a shared printer set as default destination: server1, server2. 2. On a trusty client try: export CUPS_SERVER=server1 lpstat -h server2 -H 3. Expected result: server2:631 4. Actual result: server1:631 (server given by CUPS_SERVER is used instead of the one given by -h option). If a port number is given (e.g. server2:631) the commands work as expected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1665018/+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 1550983] Re: Fails to start with "Couldn't open libGL.so.1" (missing dependency?)
** Changed in: gtk+3.0 (Ubuntu Xenial) Status: New => In Progress ** Changed in: gtk+3.0 (Ubuntu Yakkety) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gtk+3.0 in Ubuntu. https://bugs.launchpad.net/bugs/1550983 Title: Fails to start with "Couldn't open libGL.so.1" (missing dependency?) Status in One Hundred Papercuts: Confirmed Status in gtk+3.0 package in Ubuntu: Fix Released Status in gtk+3.0 source package in Xenial: In Progress Status in gtk+3.0 source package in Yakkety: In Progress Status in gtk+3.0 package in Debian: Fix Released Bug description: [Impact] There are some unlinked calls to libGL.so.1 undetected in the build process because of using libepoxy. Running an application that does not depend on libgl1 (directly or indirectly) may lead to aborting the process with an undefined reference to libGL.so.1. [Test Case] 1. Deploy a server / cloud image of Xenial or Yakkety. 2. Use a Windows or a Mac client with Cygwin/X and ssh -XY to Ubuntu machine. 3. sudo apt install firefox; firefox Expected result: firefox is launched on the client machine. Actual result: "Couldn't open libGL.so.1" message is printed. [Regression Potential] Minimal, it is an upstream change already released to zesty. It performs a runtime check for GL support and disables GLX function calls in case they're not available. [Other Info] Original bug description: virt-manager fails to start: $ virt-manager --debug --no-fork [Sun, 28 Feb 2016 19:18:22 virt-manager 7592] DEBUG (cli:256) Launched with command line: /usr/share/virt-manager/virt-manager --debug --no-fork [Sun, 28 Feb 2016 19:18:22 virt-manager 7592] DEBUG (virt-manager:143) virt-manager version: 1.3.2 [Sun, 28 Feb 2016 19:18:22 virt-manager 7592] DEBUG (virt-manager:144) virtManager import: Couldn't open libGL.so.1: libGL.so.1: cannot open shared object file: No such file or directory $ Installing the 'libgl1-mesa-glx' package resolves the issue. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: virt-manager 1:1.3.2-0ubuntu1 ProcVersionSignature: Ubuntu 4.4.0-8.23-generic 4.4.2 Uname: Linux 4.4.0-8-generic x86_64 ApportVersion: 2.20-0ubuntu3 Architecture: amd64 Date: Sun Feb 28 19:19:27 2016 InstallationDate: Installed on 2016-02-27 (0 days ago) InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160206) PackageArchitecture: all SourcePackage: virt-manager UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/hundredpapercuts/+bug/1550983/+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 1638695] Re: Python 2.7.12 performance regression
Here are the results of the comparative tests I ran : https://docs.google.com/spreadsheets/d/1MyNBPVZlBeic1OLqVKe_bcPk2deO_pQs9trIfOFefM0/edit#gid=2034603487 It confirms the assumptions but unfortunately, rebuilding 2.7.12 without the -fstack-protector-strong leads to worse performances than the stock 2.7.12 build. I'm continuing my investigations. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python2.7 in Ubuntu. https://bugs.launchpad.net/bugs/1638695 Title: Python 2.7.12 performance regression Status in python2.7 package in Ubuntu: Confirmed Bug description: I work on the OpenStack-Ansible project and we've noticed that testing jobs on 16.04 take quite a bit longer to complete than on 14.04. They complete within an hour on 14.04 but they normally take 90 minutes or more on 16.04. We use the same version of Ansible with both versions of Ubuntu. After more digging, I tested python performance (using the 'performance' module) on 14.04 (2.7.6) and on 16.04 (2.7.12). There is a significant performance difference between each version of python. That is detailed in a spreadsheet[0]. I began using perf to dig into the differences when running the python performance module and when using Ansible playbooks. CPU migrations (as measured by perf) are doubled in Ubuntu 16.04 when running the same python workloads. I tried changing some of the kerne.sched sysctl configurables but they had very little effect on the results. I compiled python 2.7.12 from source on 14.04 and found the performance to be unchanged there. I'm not entirely sure where the problem might be now. We also have a bug open in OpenStack-Ansible[1] that provides additional detail. Thanks in advance for any help you can provide! [0] https://docs.google.com/spreadsheets/d/18MmptS_DAd1YP3OhHWQqLYVA9spC3xLt4PS3STI6tds/edit?usp=sharing [1] https://bugs.launchpad.net/openstack-ansible/+bug/1637494 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1638695/+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 1638695] Re: Python 2.7.12 performance regression
Hello,
Just to clarify something that I have just realized using :
$ pyperformance run -p={some python} means that {some python} will be
used to run PYPERFORMANCE, not to run the benchmarks !!! So changing -p
to use different builds of python will not run proper comparaison of the
different builds.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python2.7 in Ubuntu.
https://bugs.launchpad.net/bugs/1638695
Title:
Python 2.7.12 performance regression
Status in python2.7 package in Ubuntu:
Confirmed
Bug description:
I work on the OpenStack-Ansible project and we've noticed that testing
jobs on 16.04 take quite a bit longer to complete than on 14.04. They
complete within an hour on 14.04 but they normally take 90 minutes or
more on 16.04. We use the same version of Ansible with both versions
of Ubuntu.
After more digging, I tested python performance (using the
'performance' module) on 14.04 (2.7.6) and on 16.04 (2.7.12). There
is a significant performance difference between each version of
python. That is detailed in a spreadsheet[0].
I began using perf to dig into the differences when running the python
performance module and when using Ansible playbooks. CPU migrations
(as measured by perf) are doubled in Ubuntu 16.04 when running the
same python workloads.
I tried changing some of the kerne.sched sysctl configurables but they
had very little effect on the results.
I compiled python 2.7.12 from source on 14.04 and found the
performance to be unchanged there. I'm not entirely sure where the
problem might be now.
We also have a bug open in OpenStack-Ansible[1] that provides
additional detail. Thanks in advance for any help you can provide!
[0]
https://docs.google.com/spreadsheets/d/18MmptS_DAd1YP3OhHWQqLYVA9spC3xLt4PS3STI6tds/edit?usp=sharing
[1] https://bugs.launchpad.net/openstack-ansible/+bug/1637494
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1638695/+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 1654600] Re: unattended-upgrade-shutdown hangs when /var is a separate filesystem
Ok, here is how I understand the situation.
According to the systemd documentation about [Unit] Before= :
"Given two units with any ordering dependency between them, if one unit
is shut down and the other is started up, the shutdown is ordered before
the start-up. It doesn't matter if the ordering dependency is After= or
Before=."
To me this means that network.service & local-fs.service will be
shutdown _BEFORE_ unattended-upgrades-shutdown runs, hence /var var will
be unmounted when it runs.
My current solution is to turn the unattended-upgrades.service
ExecStart= into an ExecStop= so the unit will run as a shutdown instead
of a start when the system shuts down :
[Unit]
Description=Unattended Upgrades Shutdown
DefaultDependencies=no
Before=shutdown.target reboot.target halt.target network.target local-fs.target
Documentation=man:unattended-upgrade(8)
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStop=/usr/share/unattended-upgrades/unattended-upgrade-shutdown --debug
TimeoutStopSec=900
[Install]
WantedBy=shutdown.target
Preliminary tests seem to run fine but I want to get confirmation on
such a change by someone more expert with systemd that I am.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
https://bugs.launchpad.net/bugs/1654600
Title:
unattended-upgrade-shutdown hangs when /var is a separate filesystem
Status in unattended-upgrades package in Ubuntu:
Confirmed
Status in unattended-upgrades source package in Xenial:
Confirmed
Status in unattended-upgrades source package in Yakkety:
New
Bug description:
The systemd unit file unattended-upgrades.service is used to stop a running
unattended-upgrade
process during shutdown. This unit file is running together with all
filesystem
unmount services.
The unattended-upgrades service checks if the lockfile for unattended-upgrade
(in /var/run) exists, and if it does, there is an unattended-upgrade in
progress
and the service will wait until it finishes (and therefore automatically wait
at
shutdown).
However, if /var is a separate filesystem, it will get unmounted even though
/var/run
is a tmpfs that's still mounted on top of the /var/run directory in the /var
filesystem.
The unattended-upgrade script will fail to find lockfile, sleeps for 5
seconds, and
tries to check the lockfile again. After 10 minutes (the default timeout), it
will finally
exit and the system will continue shutdown.
The problem is the error handling in
/usr/share/unattended-upgrades/unattended-upgrade-shutdown
where it tries to lock itself:
while True:
res = apt_pkg.get_lock(options.lock_file)
logging.debug("get_lock returned %i" % res)
# exit here if there is no lock
if res > 0:
logging.debug("lock not taken")
break
lock_was_taken = True
The function apt_pkg.get_lock() either returns a file descriptor, or -1 on an
error.
File descriptors are just C file descriptors, so they are always positive
integers.
The code should check the result to be negative, not positive. I have
attached a patch
to reverse the logic.
Additional information:
1)
Description: Ubuntu 16.04.1 LTS
Release: 16.04
2)
unattended-upgrades:
Installed: 0.90ubuntu0.3
Candidate: 0.90ubuntu0.3
Version table:
*** 0.90ubuntu0.3 500
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64
Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main i386
Packages
100 /var/lib/dpkg/status
0.90 500
500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial/main i386 Packages
3)
Fast reboot
4)
Very slow reboot (after a 10 minutes timeout)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1654600/+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 1654600] Re: unattended-upgrade-shutdown hangs when /var is a separate filesystem
Hello,
This logic is correct. apt_pkg.get_lock(options.lock_file) is trying to
acquire a lockfile (/var/run/unattended-upgrades.lock) which is only
possible if no unattended-upgrade is already running. If it can acquire
the lock, it means that NO unattended-upgrade is running, hence shutdown
may proceed.
while True:
res = apt_pkg.get_lock(options.lock_file)
logging.debug("get_lock returned %i" % res)
# exit here if there is no lock
if res > 0:
logging.debug("lock not taken")
break
lock_was_taken = True
The problem is that apt_pkg.get_lock(options.lock_file) will also return
-1 if the path to the lock file doesn't exist, which is the case when
/var is unmounted, hence /var/run is no longer present (/var/run is a
symlink to /run).
I'm working on identifying the proper systemd order to make sure that
/var/run is still accessible.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
https://bugs.launchpad.net/bugs/1654600
Title:
unattended-upgrade-shutdown hangs when /var is a separate filesystem
Status in unattended-upgrades package in Ubuntu:
Confirmed
Status in unattended-upgrades source package in Xenial:
Confirmed
Status in unattended-upgrades source package in Yakkety:
New
Bug description:
The systemd unit file unattended-upgrades.service is used to stop a running
unattended-upgrade
process during shutdown. This unit file is running together with all
filesystem
unmount services.
The unattended-upgrades service checks if the lockfile for unattended-upgrade
(in /var/run) exists, and if it does, there is an unattended-upgrade in
progress
and the service will wait until it finishes (and therefore automatically wait
at
shutdown).
However, if /var is a separate filesystem, it will get unmounted even though
/var/run
is a tmpfs that's still mounted on top of the /var/run directory in the /var
filesystem.
The unattended-upgrade script will fail to find lockfile, sleeps for 5
seconds, and
tries to check the lockfile again. After 10 minutes (the default timeout), it
will finally
exit and the system will continue shutdown.
The problem is the error handling in
/usr/share/unattended-upgrades/unattended-upgrade-shutdown
where it tries to lock itself:
while True:
res = apt_pkg.get_lock(options.lock_file)
logging.debug("get_lock returned %i" % res)
# exit here if there is no lock
if res > 0:
logging.debug("lock not taken")
break
lock_was_taken = True
The function apt_pkg.get_lock() either returns a file descriptor, or -1 on an
error.
File descriptors are just C file descriptors, so they are always positive
integers.
The code should check the result to be negative, not positive. I have
attached a patch
to reverse the logic.
Additional information:
1)
Description: Ubuntu 16.04.1 LTS
Release: 16.04
2)
unattended-upgrades:
Installed: 0.90ubuntu0.3
Candidate: 0.90ubuntu0.3
Version table:
*** 0.90ubuntu0.3 500
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64
Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main i386
Packages
100 /var/lib/dpkg/status
0.90 500
500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial/main i386 Packages
3)
Fast reboot
4)
Very slow reboot (after a 10 minutes timeout)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1654600/+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 1654600] Re: unattended-upgrade-shutdown hangs when /var is a separate filesystem
** Also affects: unattended-upgrades (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: unattended-upgrades (Ubuntu Yakkety)
Importance: Undecided
Status: New
** Changed in: unattended-upgrades (Ubuntu)
Assignee: (unassigned) => Louis Bouchard (louis-bouchard)
** Changed in: unattended-upgrades (Ubuntu Xenial)
Assignee: (unassigned) => Louis Bouchard (louis-bouchard)
** Changed in: unattended-upgrades (Ubuntu Yakkety)
Assignee: (unassigned) => Louis Bouchard (louis-bouchard)
** Changed in: unattended-upgrades (Ubuntu Xenial)
Importance: Undecided => High
** Changed in: unattended-upgrades (Ubuntu Yakkety)
Importance: Undecided => High
** Changed in: unattended-upgrades (Ubuntu Xenial)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unattended-upgrades in
Ubuntu.
https://bugs.launchpad.net/bugs/1654600
Title:
unattended-upgrade-shutdown hangs when /var is a separate filesystem
Status in unattended-upgrades package in Ubuntu:
Confirmed
Status in unattended-upgrades source package in Xenial:
Confirmed
Status in unattended-upgrades source package in Yakkety:
New
Bug description:
The systemd unit file unattended-upgrades.service is used to stop a running
unattended-upgrade
process during shutdown. This unit file is running together with all
filesystem
unmount services.
The unattended-upgrades service checks if the lockfile for unattended-upgrade
(in /var/run) exists, and if it does, there is an unattended-upgrade in
progress
and the service will wait until it finishes (and therefore automatically wait
at
shutdown).
However, if /var is a separate filesystem, it will get unmounted even though
/var/run
is a tmpfs that's still mounted on top of the /var/run directory in the /var
filesystem.
The unattended-upgrade script will fail to find lockfile, sleeps for 5
seconds, and
tries to check the lockfile again. After 10 minutes (the default timeout), it
will finally
exit and the system will continue shutdown.
The problem is the error handling in
/usr/share/unattended-upgrades/unattended-upgrade-shutdown
where it tries to lock itself:
while True:
res = apt_pkg.get_lock(options.lock_file)
logging.debug("get_lock returned %i" % res)
# exit here if there is no lock
if res > 0:
logging.debug("lock not taken")
break
lock_was_taken = True
The function apt_pkg.get_lock() either returns a file descriptor, or -1 on an
error.
File descriptors are just C file descriptors, so they are always positive
integers.
The code should check the result to be negative, not positive. I have
attached a patch
to reverse the logic.
Additional information:
1)
Description: Ubuntu 16.04.1 LTS
Release: 16.04
2)
unattended-upgrades:
Installed: 0.90ubuntu0.3
Candidate: 0.90ubuntu0.3
Version table:
*** 0.90ubuntu0.3 500
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64
Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main i386
Packages
100 /var/lib/dpkg/status
0.90 500
500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
500 http://nl.archive.ubuntu.com/ubuntu xenial/main i386 Packages
3)
Fast reboot
4)
Very slow reboot (after a 10 minutes timeout)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1654600/+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 1550983] Re: Fails to start with "Couldn't open libGL.so.1" (missing dependency?)
** Also affects: gtk+3.0 (Ubuntu Yakkety) Importance: Undecided Status: New ** Also affects: gtk+3.0 (Ubuntu Xenial) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gtk+3.0 in Ubuntu. https://bugs.launchpad.net/bugs/1550983 Title: Fails to start with "Couldn't open libGL.so.1" (missing dependency?) Status in One Hundred Papercuts: Confirmed Status in gtk+3.0 package in Ubuntu: Fix Released Status in gtk+3.0 source package in Xenial: New Status in gtk+3.0 source package in Yakkety: New Status in gtk+3.0 package in Debian: Fix Released Bug description: [Impact] There are some unlinked calls to libGL.so.1 undetected in the build process because of using libepoxy. Running an application that does not depend on libgl1 (directly or indirectly) may lead to aborting the process with an undefined reference to libGL.so.1. [Test Case] 1. Deploy a server / cloud image of Xenial or Yakkety. 2. Use a Windows or a Mac client with Cygwin/X and ssh -XY to Ubuntu machine. 3. sudo apt install firefox; firefox Expected result: firefox is launched on the client machine. Actual result: "Couldn't open libGL.so.1" message is printed. [Regression Potential] Minimal [Other Info] Original bug description: virt-manager fails to start: $ virt-manager --debug --no-fork [Sun, 28 Feb 2016 19:18:22 virt-manager 7592] DEBUG (cli:256) Launched with command line: /usr/share/virt-manager/virt-manager --debug --no-fork [Sun, 28 Feb 2016 19:18:22 virt-manager 7592] DEBUG (virt-manager:143) virt-manager version: 1.3.2 [Sun, 28 Feb 2016 19:18:22 virt-manager 7592] DEBUG (virt-manager:144) virtManager import: Couldn't open libGL.so.1: libGL.so.1: cannot open shared object file: No such file or directory $ Installing the 'libgl1-mesa-glx' package resolves the issue. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: virt-manager 1:1.3.2-0ubuntu1 ProcVersionSignature: Ubuntu 4.4.0-8.23-generic 4.4.2 Uname: Linux 4.4.0-8-generic x86_64 ApportVersion: 2.20-0ubuntu3 Architecture: amd64 Date: Sun Feb 28 19:19:27 2016 InstallationDate: Installed on 2016-02-27 (0 days ago) InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160206) PackageArchitecture: all SourcePackage: virt-manager UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/hundredpapercuts/+bug/1550983/+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 1176046] Re: isc-dhcp dhclient listens on extra random ports
Notes from online discussion : == src:isc-dhcp Trusty: 4.2.4-7ubuntu12.8 -> (isc-dhcp-client) Proposal A: 4.2.4-7ubuntu12.9 -> (isc-dhcp-client, isc-dhcp-client-ddns), isc-dhcp-client Recommends: isc-dhcp-client-ddns Proposal B: 4.2.4-7ubuntu12.9 -> (isc-dhcp-client), patched to disable ddns if DISABLE_DDNS_LP_1176046 is set in the environment Xenial: 4.3.3-5ubuntu12.6 -> (isc-dhcp-client, isc-dhcp-client-ddns) Proposal A: 4.3.3-5ubuntu12.7 -> (isc-dhcp-client, isc-dhcp-client-ddns), isc-dhcp-client Breaks/Replaces: isc-dhcp-ddns (<< 4.3.3-5ubuntu12~) Proposal B: no change Use case 1: Trusty user has isc-dhcp-client 4.2.4-7ubuntu12.8 installed, and SRUs to end up with 4.2.4-7ubuntu12.9 of both isc-dhcp-client and isc-dhcp-client-ddns. User upgrades to Xenial. Expected results: user ends up with isc-dhcp-client installed but not isc-dhcp-client-ddns Actual results in proposal A: apt resolves this by updating isc-dhcp-client-ddns first to 4.3.3-5ubuntu12.7 and then isc-dhcp-client to 4.3.3-5ubuntu12.7. Actual results in proposal B: correct. Use case 2: Trusty user has isc-dhcp-client 4.2.4-7ubuntu12.8 installed, relies on ddns, and SRUs. Expected result: ddns support still works. Actual results in proposal A: correct. Actual results in proposal B: correct. Use case 3: Trusty user has isc-dhcp-client 4.2.4-7ubuntu12.8 installed, ddns is enabled, but this breaks listening on a static UDP port as dhclient sometimes undesirably listens on it first. Since this is already released, mandatory user intervention is acceptable Expected result: ddns support is disabled. Actual results in proposal A: correct with user intervention by manually removing the isc-dhcp-client-ddns package after the SRU. Actual results in proposal B: correct, with user intervention by adding the environment setting in service startup as a conffile User then upgrades to Xenial. Expected results: the lack of DDNS support is still maintained. Actual results in proposal B: correct: the environment variable is ignored. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1176046 Title: isc-dhcp dhclient listens on extra random ports Status in isc-dhcp package in Ubuntu: Fix Released Status in isc-dhcp source package in Trusty: In Progress Status in isc-dhcp source package in Xenial: Fix Released Status in isc-dhcp source package in Yakkety: Fix Released Bug description: [Impact] In trusty, there is only 1 version of dhclient, including #define NSUPDATE, which introduce DDNS functionnality. The DDNS functionnality, generate 2 random extra ports between 1024-65535. Impact reported by users : "One impact of these random ports is that security hardening becomes more difficult. The purpose of these random ports and security implications are unknown." "We have software that was using one of the lower udp ports but it happened to collide with dhclient which seems to allocate 2 random ports." There is a randomization mechanism in libdns that prevent dhclient to take the sysctl values into account (net.ipv4.ip_local_port_range & net.ipv4.ip_local_reserved_ports) to workaround this, and after discussion isc-dhcp upstream doesn't want to rely on kernel for randomization. There is no realtime configuration to disable the feature or workaround this. The only possible way is at compile time. I also talk with upstream maintainers, and there is no way they will accept to reduce the range (1024-65535) for security reason. Reducing the port range may facilitate the spoofing. Xenial has separated dhclient in two packages : isc-dhcp-client pkg : dhclient with DDNS functionality disabled (no random extra ports) isc-dhcp-client-ddns : dhclient with DDNS functionality enabled (with random extra ports) The goal here is to reproduce the same situation in Trusty, for this bug to be less painful for at least users that doesn't require DDNS functionnality. [Test Case] Run a Trusty image with following package : isc-dhcp-client isc-dhcp-common ``` dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc dhclient 1110 root 20u IPv4 11516 0t0 UDP *:64589 # <--- extra random port dhclient 1110 root 21u IPv6 11517 0t0 UDP *:7749 # <--- extra random port ``` [Regression Potential] * none expected I did the split such that users will automatically get isc-dhcp-client-ddns installed but users bothered by this bug then will have the option to switch to the one without it by uninstalling (isc-dhcp-client-ddns), so existing Trusty users can continue to use this DDNS functionality after the SRU without any necessary intervention. With isc-dhcp-client-ddns : dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc dhclient
[Touch-packages] [Bug 1176046] Re: isc-dhcp dhclient listens on extra random ports
** Also affects: isc-dhcp (Ubuntu Yakkety) Importance: Undecided Status: New ** Also affects: isc-dhcp (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: isc-dhcp (Ubuntu) Status: In Progress => Fix Released ** Changed in: isc-dhcp (Ubuntu Xenial) Status: New => Fix Released ** Changed in: isc-dhcp (Ubuntu Yakkety) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1176046 Title: isc-dhcp dhclient listens on extra random ports Status in isc-dhcp package in Ubuntu: Fix Released Status in isc-dhcp source package in Trusty: In Progress Status in isc-dhcp source package in Xenial: Fix Released Status in isc-dhcp source package in Yakkety: Fix Released Bug description: [Impact] In trusty, there is only 1 version of dhclient, including #define NSUPDATE, which introduce DDNS functionnality. The DDNS functionnality, generate 2 random extra ports between 1024-65535. Impact reported by users : "One impact of these random ports is that security hardening becomes more difficult. The purpose of these random ports and security implications are unknown." "We have software that was using one of the lower udp ports but it happened to collide with dhclient which seems to allocate 2 random ports." There is a randomization mechanism in libdns that prevent dhclient to take the sysctl values into account (net.ipv4.ip_local_port_range & net.ipv4.ip_local_reserved_ports) to workaround this, and after discussion isc-dhcp upstream doesn't want to rely on kernel for randomization. There is no realtime configuration to disable the feature or workaround this. The only possible way is at compile time. I also talk with upstream maintainers, and there is no way they will accept to reduce the range (1024-65535) for security reason. Reducing the port range may facilitate the spoofing. Xenial has separated dhclient in two packages : isc-dhcp-client pkg : dhclient with DDNS functionality disabled (no random extra ports) isc-dhcp-client-ddns : dhclient with DDNS functionality enabled (with random extra ports) The goal here is to reproduce the same situation in Trusty, for this bug to be less painful for at least users that doesn't require DDNS functionnality. [Test Case] Run a Trusty image with following package : isc-dhcp-client isc-dhcp-common ``` dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc dhclient 1110 root 20u IPv4 11516 0t0 UDP *:64589 # <--- extra random port dhclient 1110 root 21u IPv6 11517 0t0 UDP *:7749 # <--- extra random port ``` [Regression Potential] * none expected I did the split such that users will automatically get isc-dhcp-client-ddns installed but users bothered by this bug then will have the option to switch to the one without it by uninstalling (isc-dhcp-client-ddns), so existing Trusty users can continue to use this DDNS functionality after the SRU without any necessary intervention. With isc-dhcp-client-ddns : dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc dhclient 1110 root 20u IPv4 11516 0t0 UDP *:64589 # <--- extra random port dhclient 1110 root 21u IPv6 11517 0t0 UDP *:7749 # <--- extra random port Without isc-dhcp-client-ddns : dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc Note that this is how Xenial does it. [Other Info] * See : https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1176046/comments/19 to look at my discussion with rbasak on if that approach would be acceptable for SRU. [Original Description] Ubuntu 13.04 Server 64-bit. Fresh install. Only one network adapter. dhclient process is listening on two randomly chosen udp ports in addition to the usual port 68. This appears to be a bug in the discovery code for probing information on interfaces in the system. Initial research of the code also suggested omapi, but adding omapi port to /etc/dhcp/dhclient.conf only opened a forth port with the two random udp ports still enabled. Version of included distro dhclient was 4.2.4. I also tested with the latest isc-dhclient-4.2.5-P1 and got the same results. Debian has the same bug: http://forums.debian.net/viewtopic.php?f=10=95273=495605#p495605 One impact of these random ports is that security hardening becomes more difficult. The purpose of these random ports and security implications are unknown. Example netstat -lnp output: udp0 0 0.0.0.0:21117 0.0.0.0:* 2659/dhclient udp0 0 0.0.0.0:68 0.0.0.0:* 2659/dhclient udp6 0 0 :::45664:::* 2659/dhclient To manage notifications about this bug go to:
[Touch-packages] [Bug 1176046] Re: isc-dhcp dhclient listens on extra random ports
Here is how I understand it : In Trusty, the isc-dhcp client provides the Dynamic DNS (ddns) functionality and this one can be disabled. From Xenial onward, two separate packages provide each of the possibilities. AFAIU, the Trusty isc-dhcp package should become isc-dhcp which doesn't provide the two extra port bindings, and would also install the isc- dhcp-ddns to provide the extra functionality in order to remain at iso- functionality. So if isc-dhcp-ddns Breaks/Replaces isc-dhcp and Recommends isc-dhcp- ddns, we should keep the same functionality for existing users. It then becomes possible, by removing isc-dhcp to revoke the use of the two extra port bindings, which is the existing situation on Xenial. The upgrade path then becomes alligned with the Xenial packaging which has both isc-dhcp & isc-dhcp-ddns. Am I reading this correctly ? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1176046 Title: isc-dhcp dhclient listens on extra random ports Status in isc-dhcp package in Ubuntu: In Progress Status in isc-dhcp source package in Trusty: In Progress Bug description: [Impact] In trusty, there is only 1 version of dhclient, including #define NSUPDATE, which introduce DDNS functionnality. The DDNS functionnality, generate 2 random extra ports between 1024-65535. Impact reported by users : "One impact of these random ports is that security hardening becomes more difficult. The purpose of these random ports and security implications are unknown." "We have software that was using one of the lower udp ports but it happened to collide with dhclient which seems to allocate 2 random ports." There is a randomization mechanism in libdns that prevent dhclient to take the sysctl values into account (net.ipv4.ip_local_port_range & net.ipv4.ip_local_reserved_ports) to workaround this, and after discussion isc-dhcp upstream doesn't want to rely on kernel for randomization. There is no realtime configuration to disable the feature or workaround this. The only possible way is at compile time. I also talk with upstream maintainers, and there is no way they will accept to reduce the range (1024-65535) for security reason. Reducing the port range may facilitate the spoofing. Xenial has separated dhclient in two packages : isc-dhcp-client pkg : dhclient with DDNS functionality disabled (no random extra ports) isc-dhcp-client-ddns : dhclient with DDNS functionality enabled (with random extra ports) The goal here is to reproduce the same situation in Trusty, for this bug to be less painful for at least users that doesn't require DDNS functionnality. [Test Case] Run a Trusty image with following package : isc-dhcp-client isc-dhcp-common ``` dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc dhclient 1110 root 20u IPv4 11516 0t0 UDP *:64589 # <--- extra random port dhclient 1110 root 21u IPv6 11517 0t0 UDP *:7749 # <--- extra random port ``` [Regression Potential] * none expected I did the split such that users will automatically get isc-dhcp-client-ddns installed but users bothered by this bug then will have the option to switch to the one without it by uninstalling (isc-dhcp-client-ddns), so existing Trusty users can continue to use this DDNS functionality after the SRU without any necessary intervention. With isc-dhcp-client-ddns : dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc dhclient 1110 root 20u IPv4 11516 0t0 UDP *:64589 # <--- extra random port dhclient 1110 root 21u IPv6 11517 0t0 UDP *:7749 # <--- extra random port Without isc-dhcp-client-ddns : dhclient 1110 root 6u IPv4 11535 0t0 UDP *:bootpc Note that this is how Xenial does it. [Other Info] * See : https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1176046/comments/19 to look at my discussion with rbasak on if that approach would be acceptable for SRU. [Original Description] Ubuntu 13.04 Server 64-bit. Fresh install. Only one network adapter. dhclient process is listening on two randomly chosen udp ports in addition to the usual port 68. This appears to be a bug in the discovery code for probing information on interfaces in the system. Initial research of the code also suggested omapi, but adding omapi port to /etc/dhcp/dhclient.conf only opened a forth port with the two random udp ports still enabled. Version of included distro dhclient was 4.2.4. I also tested with the latest isc-dhclient-4.2.5-P1 and got the same results. Debian has the same bug: http://forums.debian.net/viewtopic.php?f=10=95273=495605#p495605 One impact of these random ports is that security hardening becomes more difficult. The purpose of these random ports and security implications are unknown. Example netstat -lnp output: udp
[Touch-packages] [Bug 1647178] Re: systemd-resolved unable to resolve certain subdomains
** This bug is no longer a duplicate of bug 1647031 systemd-resolved’s 127.0.0.53 server does not follow CNAME records -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1647178 Title: systemd-resolved unable to resolve certain subdomains Status in systemd package in Ubuntu: Incomplete Bug description: After upgrade to systemd-resolved, certain very well known subdomains are no longer resolved. Their TLD do resolve correctly. Example given with mail.google.com and google.com On xenial : $ nslookup mail.google.com Server: 192.168.1.1 Address:192.168.1.1#53 Non-authoritative answer: mail.google.com canonical name = googlemail.l.google.com. Name: googlemail.l.google.com Address: 216.58.198.197 $ dig mail.google.com ; <<>> DiG 9.10.3-P4-Ubuntu <<>> mail.google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57929 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;mail.google.com. IN A ;; ANSWER SECTION: mail.google.com.441512 IN CNAME googlemail.l.google.com. googlemail.l.google.com. 274IN A 216.58.198.197 ;; Query time: 14 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Sun Dec 04 18:12:43 CET 2016 ;; MSG SIZE rcvd: 87 On Zesty using systemd-resolved : # nslookup mail.google.com Server: 10.0.3.1 Address:10.0.3.1#53 Non-authoritative answer: mail.google.com canonical name = googlemail.l.google.com. # nslookup google.com Server: 10.0.3.1 Address:10.0.3.1#53 Non-authoritative answer: Name: google.com Address: 216.58.198.206 # dig mail.google.com ; <<>> DiG 9.10.3-P4-Ubuntu <<>> mail.google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10775 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;mail.google.com. IN A ;; ANSWER SECTION: mail.google.com.441414 IN CNAME googlemail.l.google.com. ;; Query time: 0 msec ;; SERVER: 10.0.3.1#53(10.0.3.1) ;; WHEN: Sun Dec 04 17:14:21 UTC 2016 ;; MSG SIZE rcvd: 81 # dig google.com ; <<>> DiG 9.10.3-P4-Ubuntu <<>> google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25303 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;google.com.IN A ;; ANSWER SECTION: google.com. 160 IN A 216.58.198.206 ;; Query time: 0 msec ;; SERVER: 10.0.3.1#53(10.0.3.1) ;; WHEN: Sun Dec 04 17:14:37 UTC 2016 ;; MSG SIZE rcvd: 55 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1647178/+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 1647031] Re: systemd-resolved’s 127.0.0.53 server does not follow CNAME records
I have libnss-resolve installed and still cannot connect to
gmail.google.com with 127.0.0.53.
Happy to help diagnose the issue though.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1647031
Title:
systemd-resolved’s 127.0.0.53 server does not follow CNAME records
Status in systemd:
New
Status in systemd package in Ubuntu:
Triaged
Bug description:
$ systemd-resolve www.freedesktop.org
www.freedesktop.org: 131.252.210.176
2610:10:20:722:a800:ff:feda:470f
(annarchy.freedesktop.org)
-- Information acquired via protocol DNS in 673.6ms.
-- Data is authenticated: no
$ ping www.freedesktop.org
ping: www.freedesktop.org: Name or service not known
$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 127.0.0.53
$ dig +no{cmd,comments,stats} www.freedesktop.org @127.0.0.53
;www.freedesktop.org. IN A
www.freedesktop.org. 7146IN CNAME annarchy.freedesktop.org.
$ dig +no{cmd,comments,stats} www.freedesktop.org @8.8.8.8
;www.freedesktop.org. IN A
www.freedesktop.org. 14399 IN CNAME annarchy.freedesktop.org.
annarchy.freedesktop.org. 14399 IN A 131.252.210.176
I trust it needn’t be explained why this makes the internet almost
completely useless in zesty.
To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1647031/+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 1647178] Re: systemd-resolved unable to resolve certain subdomains
*** This bug is a duplicate of bug 1647031 *** https://bugs.launchpad.net/bugs/1647031 It definitively is. Thanks for spotting this ** This bug has been marked a duplicate of bug 1647031 systemd-resolved’s 127.0.0.53 server does not follow CNAME records -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1647178 Title: systemd-resolved unable to resolve certain subdomains Status in systemd package in Ubuntu: Incomplete Bug description: After upgrade to systemd-resolved, certain very well known subdomains are no longer resolved. Their TLD do resolve correctly. Example given with mail.google.com and google.com On xenial : $ nslookup mail.google.com Server: 192.168.1.1 Address:192.168.1.1#53 Non-authoritative answer: mail.google.com canonical name = googlemail.l.google.com. Name: googlemail.l.google.com Address: 216.58.198.197 $ dig mail.google.com ; <<>> DiG 9.10.3-P4-Ubuntu <<>> mail.google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57929 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;mail.google.com. IN A ;; ANSWER SECTION: mail.google.com.441512 IN CNAME googlemail.l.google.com. googlemail.l.google.com. 274IN A 216.58.198.197 ;; Query time: 14 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Sun Dec 04 18:12:43 CET 2016 ;; MSG SIZE rcvd: 87 On Zesty using systemd-resolved : # nslookup mail.google.com Server: 10.0.3.1 Address:10.0.3.1#53 Non-authoritative answer: mail.google.com canonical name = googlemail.l.google.com. # nslookup google.com Server: 10.0.3.1 Address:10.0.3.1#53 Non-authoritative answer: Name: google.com Address: 216.58.198.206 # dig mail.google.com ; <<>> DiG 9.10.3-P4-Ubuntu <<>> mail.google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10775 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;mail.google.com. IN A ;; ANSWER SECTION: mail.google.com.441414 IN CNAME googlemail.l.google.com. ;; Query time: 0 msec ;; SERVER: 10.0.3.1#53(10.0.3.1) ;; WHEN: Sun Dec 04 17:14:21 UTC 2016 ;; MSG SIZE rcvd: 81 # dig google.com ; <<>> DiG 9.10.3-P4-Ubuntu <<>> google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25303 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;google.com.IN A ;; ANSWER SECTION: google.com. 160 IN A 216.58.198.206 ;; Query time: 0 msec ;; SERVER: 10.0.3.1#53(10.0.3.1) ;; WHEN: Sun Dec 04 17:14:37 UTC 2016 ;; MSG SIZE rcvd: 55 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1647178/+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 1647178] [NEW] systemd-resolved unable to resolve certain subdomains
Public bug reported: After upgrade to systemd-resolved, certain very well known subdomains are no longer resolved. Their TLD do resolve correctly. Example given with mail.google.com and google.com On xenial : $ nslookup mail.google.com Server: 192.168.1.1 Address:192.168.1.1#53 Non-authoritative answer: mail.google.com canonical name = googlemail.l.google.com. Name: googlemail.l.google.com Address: 216.58.198.197 $ dig mail.google.com ; <<>> DiG 9.10.3-P4-Ubuntu <<>> mail.google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57929 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;mail.google.com. IN A ;; ANSWER SECTION: mail.google.com.441512 IN CNAME googlemail.l.google.com. googlemail.l.google.com. 274IN A 216.58.198.197 ;; Query time: 14 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Sun Dec 04 18:12:43 CET 2016 ;; MSG SIZE rcvd: 87 On Zesty using systemd-resolved : # nslookup mail.google.com Server: 10.0.3.1 Address:10.0.3.1#53 Non-authoritative answer: mail.google.com canonical name = googlemail.l.google.com. # nslookup google.com Server: 10.0.3.1 Address:10.0.3.1#53 Non-authoritative answer: Name: google.com Address: 216.58.198.206 # dig mail.google.com ; <<>> DiG 9.10.3-P4-Ubuntu <<>> mail.google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10775 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;mail.google.com. IN A ;; ANSWER SECTION: mail.google.com.441414 IN CNAME googlemail.l.google.com. ;; Query time: 0 msec ;; SERVER: 10.0.3.1#53(10.0.3.1) ;; WHEN: Sun Dec 04 17:14:21 UTC 2016 ;; MSG SIZE rcvd: 81 # dig google.com ; <<>> DiG 9.10.3-P4-Ubuntu <<>> google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25303 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;google.com.IN A ;; ANSWER SECTION: google.com. 160 IN A 216.58.198.206 ;; Query time: 0 msec ;; SERVER: 10.0.3.1#53(10.0.3.1) ;; WHEN: Sun Dec 04 17:14:37 UTC 2016 ;; MSG SIZE rcvd: 55 ** Affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1647178 Title: systemd-resolved unable to resolve certain subdomains Status in systemd package in Ubuntu: New Bug description: After upgrade to systemd-resolved, certain very well known subdomains are no longer resolved. Their TLD do resolve correctly. Example given with mail.google.com and google.com On xenial : $ nslookup mail.google.com Server: 192.168.1.1 Address:192.168.1.1#53 Non-authoritative answer: mail.google.com canonical name = googlemail.l.google.com. Name: googlemail.l.google.com Address: 216.58.198.197 $ dig mail.google.com ; <<>> DiG 9.10.3-P4-Ubuntu <<>> mail.google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57929 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;mail.google.com. IN A ;; ANSWER SECTION: mail.google.com.441512 IN CNAME googlemail.l.google.com. googlemail.l.google.com. 274IN A 216.58.198.197 ;; Query time: 14 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Sun Dec 04 18:12:43 CET 2016 ;; MSG SIZE rcvd: 87 On Zesty using systemd-resolved : # nslookup mail.google.com Server: 10.0.3.1 Address:10.0.3.1#53 Non-authoritative answer: mail.google.com canonical name = googlemail.l.google.com. # nslookup google.com Server: 10.0.3.1 Address:10.0.3.1#53 Non-authoritative answer: Name: google.com Address: 216.58.198.206 # dig mail.google.com ; <<>> DiG 9.10.3-P4-Ubuntu <<>> mail.google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10775 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;mail.google.com. IN A ;; ANSWER SECTION: mail.google.com.441414 IN CNAME googlemail.l.google.com. ;; Query time: 0 msec ;; SERVER: 10.0.3.1#53(10.0.3.1) ;; WHEN: Sun Dec 04 17:14:21 UTC
[Touch-packages] [Bug 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working
** Tags removed: sts-sru -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1529815 Title: InfiniBand DHCP flow with PRA and DHCP relay not working Status in isc-dhcp package in Ubuntu: Fix Released Status in isc-dhcp source package in Trusty: Fix Released Status in isc-dhcp source package in Wily: Won't Fix Status in isc-dhcp source package in Xenial: Fix Released Bug description: [Impact] * Infiniband users relying on DHCP can't use DHCP relay. [Test Case] * Comment #13 * Mellanox has tested themselves. * Clear way of knowing if fix worked (tcpdump). [Regression Potential] * Only related to Infiniband. * Infiniband support could stop working (unlikely, already tested). [Other Info] DHCP client is sending discover with Unicast type request for the offer, in this configuration of IB to ETH through a relay we need the type to be broadcast. The issue is that when using dhclient from the client on Ubuntu (and only on Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in unicast instead of broadcast. It seems there is no way to correct this from the client side using dhclient configuration file. this issue exist even when we use always-broadcast statement in configuration file. in other vendors we see that discover request type is broadcast. attached pcap files from working (other vendor) and not working (Ubuntu) clients. DHCP CLIENT (IPoIB) Ubuntu 14.04 kernel 3.13.0-74 Mellanox OFED 3.1-1.0.3 or inbox driver isc-dhcp-client 4.2.4-7ubuntu12.3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+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 1593378] Re: crash in slap_bv2ad using repeated tags
** Tags removed: sts-sru -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1593378 Title: crash in slap_bv2ad using repeated tags Status in openldap package in Ubuntu: Fix Released Status in openldap source package in Trusty: Fix Released Bug description: [SRU JUSTIFICATION] [Impact] The effect of the bug on users is that the program (slapd) terminated with signal SIGSEGV, Segmentation fault when ldapsearch tries to query using multiple language tags. GDB output: ... Core was generated by `/usr/sbin/slapd -h ldap://:389 ldap://:389/ ldapi:/// -g o'. Program terminated with signal SIGSEGV, Segmentation fault. ... (gdb) bt #0 __strncasecmp_l_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:210 #1 0x7f674ae8cab2 in slap_bv2ad (bv=bv@entry=0x7f6741e0e830, ad=ad@entry=0x7f6741e0e848, text=text@entry=0x7f6741e0f980) at ../../../../servers/slapd/ad.c:268 ... In frame #1 the 'tags' struct is corrupt. Line #272 checks for duplication and jumps to the done label (line #294) when a duplicate is found. The code increases 'ntags' without filling in the tags struct with values. In later iterations this could lead to copying and using uninitialised memory. [Test Case] One way to reproduce the issue : $ ldapsearch -D "cn=,dc=,dc=,dc=" -x -W -b "dc=,dc=,dc=" "cn;lang-de;lang-encn;lang-de;lang-encn;lang-de;lang-encn;lang-de ;lang-encn;lang-de;lang-encn;lang-de;lang-encn;lang-de;lang-encn;lang- de;lang-encn;lang-de;lang-encn;lang-de;lang-encn;lang-de;;lang-de ;lang-encn;lang-de;lang-encn;lang-de;lang-encn;lang-de;lang-encn;lang- de;lang-encn;lang-de;lang-encn;lang-de;lang-encn;lang-de;lang-encn ;lang-de;lang-encn;lang-de;lang-encn;lang-de;;lang-de;lang-encn;lang- de;lang-encn;lang-de;lang-encn;lang-de;lang-encn;lang-de;lang-encn ;lang-de;lang-encn;lang-de;lang-encn;lang-de;lang-encn;lang-de;lang- encn;lang-de;lang-encn;lang-de;;lang-de;lang-encn;lang-de;lang-encn ;lang-de;lang-encn;lang-de;lang-encn;lang-de;lang-encn;lang-de;lang- encn;lang-de;lang-encn;lang-de;lang-encn;lang-de;lang-encn;lang-de ;lang-encn;lang-de" Explanation : Reference: http://manpages.ubuntu.com/cgi-bin/search.py?q=ldapsearch -D binddn Use the Distinguished Name binddn to bind to the LDAP directory. For SASL binds, the server is expected to ignore this value. -x Use simple authentication instead of SASL. -W Prompt for simple authentication. This is used instead of specifying the password on the command line. -b searchbase Use searchbase as the starting point for the search instead of the default. [Regression Potential] The patch is already in place in Debian & Wily and late Ubuntu release version. A hotfix has been tested by the user that originally reported the issue. The hotfix solves the issue. [Other Info] Upstream OpenLDAP Bug : http://www.openldap.org/its/index.cgi/Software%20Bugs?id=7941;page=9 Upstream OpenLDAP Commit : af8f1e0 ITS#7941 fix for repeated tags Upstream OpenLDAP Commit Web : http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=af8f1e0 (The commit has been introduced first in upstream branch : OPENLDAP_REL_ENG_2_4_40~6) [Original Description] Core was generated by `/usr/sbin/slapd -h ldap://:389 ldap://:389/ ldapi:/// -g o'. Program terminated with signal SIGSEGV, Segmentation fault. #0 __strncasecmp_l_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:210 210 ../sysdeps/x86_64/multiarch/../strcmp.S: No such file or directory. (gdb) bt #0 __strncasecmp_l_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:210 #1 0x7f674ae8cab2 in slap_bv2ad (bv=bv@entry=0x7f6741e0e830, ad=ad@entry=0x7f6741e0e848, text=text@entry=0x7f6741e0f980) at ../../../../servers/slapd/ad.c:268 #2 0x7f674ae4d235 in get_filter (op=op@entry=0x7f672c000a80, ber=, filt=filt@entry=0x7f672c000af0, text=text@entry=0x7f6741e0f980) at ../../../../servers/slapd/filter.c:190 #3 0x7f674ae4b985 in do_search (op=0x7f672c000a80, rs=0x7f6741e0f960) at ../../../../servers/slapd/search.c:127 #4 0x7f674ae496dc in connection_operation (ctx=ctx@entry=0x7f6741e0fb90, arg_v=arg_v@entry=0x7f672c000a80) at ../../../../servers/slapd/connection.c:1150 #5 0x7f674ae49a40 in connection_read_thread (ctx=0x7f6741e0fb90, argv=0x19) at ../../../../servers/slapd/connection.c:1286 #6 0x7f674a9a7aba in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 #7 0x7f67498dc182 in start_thread (arg=0x7f6741e10700) at pthread_create.c:312 #8 0x7f674960947d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1593378/+subscriptions -- Mailing list:
[Touch-packages] [Bug 1567578] Re: libnl should be updated to support up to 63 VFs per single PF
** Tags removed: sts-sru
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libnl3 in Ubuntu.
https://bugs.launchpad.net/bugs/1567578
Title:
libnl should be updated to support up to 63 VFs per single PF
Status in libnl3 package in Ubuntu:
Fix Released
Status in libnl3 source package in Trusty:
Fix Released
Bug description:
[Impact]
libnl can only enable up to 30 VFs even if the PF supports up to 63
VFs in an Openstack SRIOV configuration.
As already documented in https://bugs.launchpad.net/mos/+bug/1501738
there is a bug in the default libnl library release installed on
Ubuntu 14.04.4.
When trying to enable a guest with more than 30 VFs attached, the
following error is returned:
error: Failed to start domain guest1
error: internal error: missing IFLA_VF_INFO in netlink response
[Test Case]
1) Edit /etc/default/grub.
GRUB_CMDLINE_LINUX="intel_iommu=on ixgbe.max_vfs=63"
2) Update grub and reboot the machine.
$ sudo update-grub
3) Check that the virtual functions are available.
$ sudo lspci|grep -i eth | grep -i virtual | wc -l
126
4) Create a KVM guest.
$ sudo uvt-kvm create guest1 release=trusty
5) List the VF devices.
$ sudo lspci|grep -i eth | grep -i virtual | awk '{print $1}' | sed
's/\:/\_/g' | sed 's/\./\_/g' > devices.txt
6) Get the libvirt node device.
$ sudo for device in $(cat ./devices.txt); do virsh nodedev-list |
grep $device; done > pci_devices.txt
7) Generate the XML config for each device.
$ sudo mkdir devices && for d in $(cat pci_devices.txt); do virsh
nodedev-dumpxml $d > devices/$d.xml; done
8) Save and Run the following script.
(http://pastebin.ubuntu.com/23374186/)
$ sudo python generate-interfaces.py |grep address | wc -l
9) Finally attach the devices to the guest.
$ sudo for i in $(seq 0 63); do virsh attach-device guest1
./interfaces/$i.xml --config; done
Device attached successfully
[...]
Device attached successfully
Device attached successfully
10) Then destroy/start the guest again, at this point the error is
reproduced.
$ sudo virsh destroy guest1
Domain guest1 destroyed
$ sudo virsh start guest1
error: Failed to start domain guest1
error: internal error: missing IFLA_VF_INFO in netlink response
[Regression Potential]
* None identified.
[Other Info]
* Redhat Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1040626
* A workaround is to install a newer library release.
$ wget
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-3-200_3.2.24-2_amd64.deb
$ wget
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-genl-3-200_3.2.24-2_amd64.deb
$ wget
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-route-3-200_3.2.24-2_amd64.deb
$ dpkg -i libnl-3-200_3.2.24-2_amd64.deb
$ dpkg -i libnl-genl-3-200_3.2.24-2_amd64.deb
$ dpkg -i libnl-route-3-200_3.2.24-2_amd64.deb
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1567578/+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 1607920] Re: zfs services fail on firstboot if zfs-utils is integrated into the deployment image
** Tags removed: sts-sru -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sysvinit in Ubuntu. https://bugs.launchpad.net/bugs/1607920 Title: zfs services fail on firstboot if zfs-utils is integrated into the deployment image Status in sysvinit package in Ubuntu: Won't Fix Status in zfs-linux package in Ubuntu: Fix Released Status in sysvinit source package in Xenial: Won't Fix Status in zfs-linux source package in Xenial: Fix Released Bug description: [Impact] * zfs services fail on firstboot if zfs-utils is integrated into the deployment image. * Output from systemd - sudo systemctl --failed UNIT LOAD ACTIVE SUB DESCRIPTION ● zfs-import-scan.service loaded failed failed Import ZFS pools by device scanning ● zfs-mount.service loaded failed failed Mount ZFS filesystems * This is particularly frustrating for users who use automated monitoring as it means virtual machines must always be restarted before showing as clean. * This failure is due to zfs services starting up before /etc/mtab has a chance to be symlinked to /proc/mounts. [Test Case] 1. Grab a stock xenial image, and unpack it and add zfs-utils to it. Repack it. 2. Boot machine 3. Check systemctl --failed. [Regression Potential] * none expected, patch has been intensively tested by the upsteam zfs test script suite. * This is a upstream commit merge in 0.7.0. * A ubuntu package has been tested (including the upstream commit) by a user of the community facing this bug, and confirmed it addresses the problem (see comment #7). [Other Info] * The "reading" is redirected to /proc/self/mounts. The writing to /etc/mtab. Some distros still need that. The current hope is to replace the writing (and maybe reading) with libmount, in a second phase. * Upstream commit : https://github.com/zfsonlinux/zfs/commit/792517389fad5c495a2738b61c2e9c65dedaaa9a * Upstream bug: https://github.com/zfsonlinux/zfs/issues/4680 * Debian bug : https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=839071 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1607920/+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 1089013] Re: clvm startup script requires cman
** Tags removed: sts-sru -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lvm2 in Ubuntu. https://bugs.launchpad.net/bugs/1089013 Title: clvm startup script requires cman Status in lvm2 package in Ubuntu: Fix Released Status in lvm2 source package in Precise: Triaged Status in lvm2 source package in Trusty: Fix Committed Status in lvm2 source package in Wily: Won't Fix Status in lvm2 source package in Xenial: Fix Released Bug description: while clvm in precise can support corosync, init script won't start because issues a cman status command ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: clvm 2.02.66-4ubuntu7.1 ProcVersionSignature: Ubuntu 3.2.0-23.36-generic 3.2.14 Uname: Linux 3.2.0-23-generic x86_64 ApportVersion: 2.0.1-0ubuntu5 Architecture: amd64 Date: Tue Dec 11 18:09:36 2012 InstallationMedia: Ubuntu-Server 12.04 LTS "Precise Pangolin" - Release amd64 (20120424.1) ProcEnviron: TERM=screen LANG=it_IT.UTF-8 SHELL=/bin/bash SourcePackage: lvm2 UpgradeStatus: No upgrade log present (probably fresh install) modified.conffile..etc.default.clvm: [modified] mtime.conffile..etc.default.clvm: 2012-12-11T16:45:40.149014 [Impact] * clvm daemon cannot start using provided init scripts [Test Case] * Install clvm package * Configure corosync * service clvm start - Fails to start due to cman dependency [Regression Potential] * None, already broken, though there is risk of other bugs being uncovered since this hasn't worked in quite awhile. [Other Info] * This is a change to the debian provided init script for clvm. Upstream debian still has the redhat-cluster package which contains the cman tool, as such this change is applicable to Ubuntu only since the redhat clustering suite is not available. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1089013/+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 1567578] Re: libnl should be updated to support up to 63 VFs per single PF
** Tags added: sts-sru
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libnl3 in Ubuntu.
https://bugs.launchpad.net/bugs/1567578
Title:
libnl should be updated to support up to 63 VFs per single PF
Status in libnl3 package in Ubuntu:
Fix Released
Status in libnl3 source package in Precise:
New
Status in libnl3 source package in Trusty:
In Progress
Bug description:
[Description]
Ubuntu 14.04.4 and SRIOV settings.
As already documented in https://bugs.launchpad.net/mos/+bug/1501738
there is a bug in the default libnl library release installed on
Ubuntu 14.04.4
When trying to enable a guest with more than 30 VFs attached, the
following error is returned:
error: Failed to start domain guest1
error: internal error: missing IFLA_VF_INFO in netlink response
[Impact]
The library release is the 3.2.21-1 the bug is impacting on the
maximum VFs number that can be enabled (up to 30) even if the PF
supports up to 63 VFs in an Openstack SRIOV configuration
[Test Case]
The sequence to reproduce this bug is:
1) Edit /etc/default/grub
GRUB_CMDLINE_LINUX="intel_iommu=on ixgbe.max_vfs=63"
2) $ sudo update-grub
### Reboot the machine.
3) Check that the virtual functions are available:
$ sudo lspci|grep -i eth | grep -i virtual | wc -l
126
4) Create a KVM guest
$ sudo uvt-kvm create guest1 release=trusty
5) List the VF devices :
$ sudo lspci|grep -i eth | grep -i virtual | awk '{print $1}' | sed
's/\:/\_/g' | sed 's/\./\_/g' > devices.txt
6) Get the libvirt node device:
$ sudo for device in $(cat ./devices.txt); do virsh nodedev-list |
grep $device; done > pci_devices.txt
7) Generate the XML config for each device:
$ sudo mkdir devices && for d in $(cat pci_devices.txt); do virsh
nodedev-dumpxml $d > devices/$d.xml; done
8) Save and Run the following script
(http://pastebin.ubuntu.com/23374186/)
$ sudo python generate-interfaces.py |grep address | wc -l
9) Finally attach the devices to the guest.
$ sudo for i in $(seq 0 63); do virsh attach-device guest1
./interfaces/$i.xml --config; done
Device attached successfully
[...]
Device attached successfully
Device attached successfully
10) Then destroy/start the guest again, at this point the error is
reproduced.
$ sudo virsh destroy guest1
Domain guest1 destroyed
$ sudo virsh start guest1
error: Failed to start domain guest1
error: internal error: missing IFLA_VF_INFO in netlink response
* detailed instructions how to reproduce the bug
* these should allow someone who is not familiar with the affected
package to reproduce the bug and verify that the updated package fixes
the problem.
[Regression Potential]
** None identified.
[Other Info]
- Redhat Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1040626
[Workaround]
The workaround is to install a newer library release, the 3.2.24-2:
wget
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-3-200_3.2.24-2_amd64.deb
wget
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-genl-3-200_3.2.24-2_amd64.deb
wget
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-route-3-200_3.2.24-2_amd64.deb
dpkg -i libnl-3-200_3.2.24-2_amd64.deb
dpkg -i libnl-genl-3-200_3.2.24-2_amd64.deb
dpkg -i libnl-route-3-200_3.2.24-2_amd64.deb
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1567578/+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 1567578] Re: libnl should be updated to support up to 63 VFs per single PF
** Also affects: libnl3 (Ubuntu Precise) Importance: Undecided Status: New ** Also affects: libnl3 (Ubuntu Trusty) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libnl3 in Ubuntu. https://bugs.launchpad.net/bugs/1567578 Title: libnl should be updated to support up to 63 VFs per single PF Status in libnl3 package in Ubuntu: Fix Released Status in libnl3 source package in Precise: New Status in libnl3 source package in Trusty: New Bug description: Ubuntu 14.04.4 and SRIOV settings. As already documented in https://bugs.launchpad.net/mos/+bug/1501738 there is a bug in the default libnl library release installed on Ubuntu 14.04.4 The library release is the 3.2.21-1 and the bug is impacting on the maximum VFs number that can be enabled (up to 30) even if the PF supports up to 63 VFs in an Openstack SRIOV configuration The workaround is to install a newer library release, the 3.2.24-2: wget https://launchpad.net/ubuntu/+archive/primary/+files/libnl-3-200_3.2.24-2_amd64.deb wget https://launchpad.net/ubuntu/+archive/primary/+files/libnl-genl-3-200_3.2.24-2_amd64.deb wget https://launchpad.net/ubuntu/+archive/primary/+files/libnl-route-3-200_3.2.24-2_amd64.deb dpkg -i libnl-3-200_3.2.24-2_amd64.deb dpkg -i libnl-genl-3-200_3.2.24-2_amd64.deb dpkg -i libnl-route-3-200_3.2.24-2_amd64.deb To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1567578/+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 1607920] Re: zfs services fail on firstboot if zfs-utils is integrated into the deployment image
** Tags removed: sts-sponsor -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sysvinit in Ubuntu. https://bugs.launchpad.net/bugs/1607920 Title: zfs services fail on firstboot if zfs-utils is integrated into the deployment image Status in sysvinit package in Ubuntu: Won't Fix Status in zfs-linux package in Ubuntu: Fix Released Status in sysvinit source package in Xenial: Won't Fix Status in zfs-linux source package in Xenial: Fix Released Bug description: [Impact] * zfs services fail on firstboot if zfs-utils is integrated into the deployment image. * Output from systemd - sudo systemctl --failed UNIT LOAD ACTIVE SUB DESCRIPTION ● zfs-import-scan.service loaded failed failed Import ZFS pools by device scanning ● zfs-mount.service loaded failed failed Mount ZFS filesystems * This is particularly frustrating for users who use automated monitoring as it means virtual machines must always be restarted before showing as clean. * This failure is due to zfs services starting up before /etc/mtab has a chance to be symlinked to /proc/mounts. [Test Case] 1. Grab a stock xenial image, and unpack it and add zfs-utils to it. Repack it. 2. Boot machine 3. Check systemctl --failed. [Regression Potential] * none expected, patch has been intensively tested by the upsteam zfs test script suite. * This is a upstream commit merge in 0.7.0. * A ubuntu package has been tested (including the upstream commit) by a user of the community facing this bug, and confirmed it addresses the problem (see comment #7). [Other Info] * The "reading" is redirected to /proc/self/mounts. The writing to /etc/mtab. Some distros still need that. The current hope is to replace the writing (and maybe reading) with libmount, in a second phase. * Upstream commit : https://github.com/zfsonlinux/zfs/commit/792517389fad5c495a2738b61c2e9c65dedaaa9a * Upstream bug: https://github.com/zfsonlinux/zfs/issues/4680 * Debian bug : https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=839071 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1607920/+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 1625667] Re: Trusty: apt does not try next mirror if index file download fails with mirror:// source
** Tags removed: verification-needed ** Tags added: verification-done -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1625667 Title: Trusty: apt does not try next mirror if index file download fails with mirror:// source Status in apt package in Ubuntu: Fix Released Status in apt source package in Trusty: Fix Committed Bug description: [SRU justification] This fix is needed to allow correct archive mirroring functionality. [Impact] Without this fix, apt-get update and other apt commands requiring Package file access may fail when there are remote transient errors due to archive availability. [Fix] Use std::npos instead of 0 to test presence of "Translation" in ShortDesc. [Test Case] 1) Setup three containers (archive1, archive2, archive3) with a reprepro configuration mirroring the ubuntu restricted archive (to save on space and time to replicate). 2) Add an apache webserver serving the reprepro archive over http on each container 3) Add the following mirrors.txt file to one of the webserver (archive1): $ cat /var/www/html/mirrors.txt http://archive1/ubuntu/ http://archive2/ubuntu/ http://archive3/ubuntu/ 4) Add a client container. Add the IP adresses of the archive[1-3] containers to /etc/hosts. Alias the archive1 address to archive.ubuntu.com similar to the following : $ cat /etc/hosts 127.0.0.1 localhost 10.0.4.182 archive1mirrors.ubuntu.com 10.0.4.127 archive2 10.0.4.193 archive3 5) Add the following line to the /etc/apt/sources.list, commenting all other entries : $ cat /etc/apt/sources.list #deb http://archive.ubuntu.com/ubuntu trusty main #deb http://archive.ubuntu.com/ubuntu trusty-updates main #deb http://archive.ubuntu.com/ubuntu trusty universe #deb http://archive.ubuntu.com/ubuntu trusty-updates universe deb mirror://mirrors.ubuntu.com/mirrors.txt trusty restricted 6) Run $ apt-get -oDebug::Acquire::mirror=true update The log should display for the Packages file : MirrorMethod::Fetch() Failure to get http://10.0.4.193/ubuntu//dists/trusty/restricted/binary-amd64/Packages Err http://10.0.4.193/ubuntu/ trusty/restricted amd64 Packages With the fix you will see : MirrorMethod::Fetch() Failure to get http://10.0.4.193/ubuntu//dists/trusty/restricted/binary-amd64/Packages.gz TryNextMirror: http://10.0.4.127/ubuntu//dists/trusty/restricted/binary-amd64/Packages.gz [Regression] None expected. Worse that can happen is a retry when none was done previously. [Original description of the problem] When using the mirror://mirrors.ubuntu.com/mirrors.txt functionality on Trusty, if the download of the index file fails, apt will not retry on another archive listed in mirrors.txt and will fail. Running the following on Trusty leads to the following result : sudo apt-get update -qq W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-security/universe/binary-amd64/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-security/main/binary-i386/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-security/restricted/binary-i386/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-security/universe/binary-i386/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-updates/main/binary-amd64/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-updates/restricted/binary-amd64/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-updates/universe/binary-amd64/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-updates/main/binary-i386/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-updates/restricted/binary-i386/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-updates/universe/binary-i386/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] E: Some index files failed to download. They have been ignored, or old ones used instead. The same configuration works correctly on Xenial To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1625667/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to
[Touch-packages] [Bug 1625667] Re: Trusty: apt does not try next mirror if index file download fails with mirror:// source
** Description changed: - When using the mirror://mirrors.ubuntu.com/mirrors.txt functionality on - Trusty, if the download of the index file fails, apt will not retry on - another archive listed in mirrors.txt and will fail. + [SRU justification] + This fix is needed to allow correct archive mirroring functionality. + + [Impact] + Without this fix, apt-get update and other apt commands requiring Package file access may fail when there are remote transient errors due to archive availability. + + [Fix] + Use std::npos instead of 0 to test presence of "Translation" in ShortDesc. + + [Test Case] + + 1) Setup three containers (archive1, archive2, archive3) with a reprepro configuration mirroring the ubuntu restricted archive (to save on space and time to replicate). + 2) Add an apache webserver serving the reprepro archive over http on each container + 3) Add the following mirrors.txt file to one of the webserver (archive1): + $ cat /var/www/html/mirrors.txt + http://archive1/ubuntu/ + http://archive2/ubuntu/ + http://archive3/ubuntu/ + 4) Add a client container. Add the IP adresses of the archive[1-3] containers to /etc/hosts. Alias the archive1 address to archive.ubuntu.com similar to the following : + $ cat /etc/hosts + 127.0.0.1 localhost + 10.0.4.182 archive1mirrors.ubuntu.com + 10.0.4.127 archive2 + 10.0.4.193 archive3 + 5) Add the following line to the /etc/apt/sources.list, commenting all other entries : + $ cat /etc/apt/sources.list + #deb http://archive.ubuntu.com/ubuntu trusty main + #deb http://archive.ubuntu.com/ubuntu trusty-updates main + #deb http://archive.ubuntu.com/ubuntu trusty universe + #deb http://archive.ubuntu.com/ubuntu trusty-updates universe + + deb mirror://mirrors.ubuntu.com/mirrors.txt trusty restricted + 6) Run + $ apt-get -oDebug::Acquire::mirror=true update + + The log should display for the Packages file : + + MirrorMethod::Fetch() + Failure to get http://10.0.4.193/ubuntu//dists/trusty/restricted/binary-amd64/Packages + Err http://10.0.4.193/ubuntu/ trusty/restricted amd64 Packages + + With the fix you will see : + + MirrorMethod::Fetch() + Failure to get http://10.0.4.193/ubuntu//dists/trusty/restricted/binary-amd64/Packages.gz + TryNextMirror: http://10.0.4.127/ubuntu//dists/trusty/restricted/binary-amd64/Packages.gz + + [Regression] + None expected. Worse that can happen is a retry when none was done previously. + + [Original description of the problem] + When using the mirror://mirrors.ubuntu.com/mirrors.txt functionality on Trusty, if the download of the index file fails, apt will not retry on another archive listed in mirrors.txt and will fail. Running the following on Trusty leads to the following result : - sudo apt-get update -qq - W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-security/universe/binary-amd64/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] - W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-security/main/binary-i386/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] - W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-security/restricted/binary-i386/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] - W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-security/universe/binary-i386/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] - W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-updates/main/binary-amd64/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] - W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-updates/restricted/binary-amd64/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] - W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-updates/universe/binary-amd64/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] - W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-updates/main/binary-i386/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] - W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-updates/restricted/binary-i386/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] - W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-updates/universe/binary-i386/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] - E: Some index files failed to download. They have been ignored, or old ones used instead. + sudo apt-get update -qq + W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-security/universe/binary-amd64/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] + W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-security/main/binary-i386/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] + W: Failed to fetch
[Touch-packages] [Bug 1625667] [NEW] Trusty: apt does not try next mirror if index file download fails with mirror:// source
Public bug reported: When using the mirror://mirrors.ubuntu.com/mirrors.txt functionality on Trusty, if the download of the index file fails, apt will not retry on another archive listed in mirrors.txt and will fail. Running the following on Trusty leads to the following result : sudo apt-get update -qq W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-security/universe/binary-amd64/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-security/main/binary-i386/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-security/restricted/binary-i386/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-security/universe/binary-i386/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-updates/main/binary-amd64/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-updates/restricted/binary-amd64/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-updates/universe/binary-amd64/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-updates/main/binary-i386/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-updates/restricted/binary-i386/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-updates/universe/binary-i386/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] E: Some index files failed to download. They have been ignored, or old ones used instead. The same configuration works correctly on Xenial ** Affects: apt (Ubuntu) Importance: Undecided Status: Invalid ** Affects: apt (Ubuntu Trusty) Importance: Undecided Status: Invalid ** Affects: apt (Ubuntu Xenial) Importance: Medium Assignee: Louis Bouchard (louis-bouchard) Status: In Progress ** Also affects: apt (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: apt (Ubuntu Trusty) Importance: Undecided Status: New ** Changed in: apt (Ubuntu) Status: New => Invalid ** Changed in: apt (Ubuntu Trusty) Status: New => Invalid ** Changed in: apt (Ubuntu Xenial) Status: New => In Progress ** Changed in: apt (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: apt (Ubuntu Xenial) Assignee: (unassigned) => Louis Bouchard (louis-bouchard) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1625667 Title: Trusty: apt does not try next mirror if index file download fails with mirror:// source Status in apt package in Ubuntu: Invalid Status in apt source package in Trusty: Invalid Status in apt source package in Xenial: In Progress Bug description: When using the mirror://mirrors.ubuntu.com/mirrors.txt functionality on Trusty, if the download of the index file fails, apt will not retry on another archive listed in mirrors.txt and will fail. Running the following on Trusty leads to the following result : sudo apt-get update -qq W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-security/universe/binary-amd64/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-security/main/binary-i386/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-security/restricted/binary-i386/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-security/universe/binary-i386/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-updates/main/binary-amd64/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-updates/restricted/binary-amd64/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-updates/universe/binary-amd64/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-updates/main/binary-i386/Packages 404 Not Foun
[Touch-packages] [Bug 1625667] Re: Trusty: apt does not try next mirror if index file download fails with mirror:// source
Marking dev + xenial as Invalid since it works from Xenial onward -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1625667 Title: Trusty: apt does not try next mirror if index file download fails with mirror:// source Status in apt package in Ubuntu: Invalid Status in apt source package in Trusty: Invalid Status in apt source package in Xenial: In Progress Bug description: When using the mirror://mirrors.ubuntu.com/mirrors.txt functionality on Trusty, if the download of the index file fails, apt will not retry on another archive listed in mirrors.txt and will fail. Running the following on Trusty leads to the following result : sudo apt-get update -qq W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-security/universe/binary-amd64/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-security/main/binary-i386/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-security/restricted/binary-i386/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-security/universe/binary-i386/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-updates/main/binary-amd64/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-updates/restricted/binary-amd64/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-updates/universe/binary-amd64/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-updates/main/binary-i386/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-updates/restricted/binary-i386/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] W: Failed to fetch mirror://mirrors.ubuntu.com/mirrors.txt/dists/trusty-updates/universe/binary-i386/Packages 404 Not Found [Mirror: http://ftp.availo.se/ubuntu/] E: Some index files failed to download. They have been ignored, or old ones used instead. The same configuration works correctly on Xenial To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1625667/+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 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working
Hello, Looking at the history for this case, the SRU got rejected by pitti (Comment #29) because of a v-failed on the fix for LP: #1568485 which is also included in this SRU. Since then, LP: #1568485 has been verified and is now fix-released. There is no longer any reason to hold on the trusty SRU for this bug. The delta between this SRU and trusty-updates is now only the patch that resolves this issue. There should no longer be any roadblock for this SRU so I am re- uploading the 12.6 package. I am also unsubscribing ubuntu-sponsors -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1529815 Title: InfiniBand DHCP flow with PRA and DHCP relay not working Status in isc-dhcp package in Ubuntu: Fix Released Status in isc-dhcp source package in Trusty: In Progress Status in isc-dhcp source package in Wily: Fix Committed Status in isc-dhcp source package in Xenial: Fix Released Bug description: [Impact] * Infiniband users relying on DHCP can't use DHCP relay. [Test Case] * Comment #13 * Mellanox has tested themselves. * Clear way of knowing if fix worked (tcpdump). [Regression Potential] * Only related to Infiniband. * Infiniband support could stop working (unlikely, already tested). [Other Info] DHCP client is sending discover with Unicast type request for the offer, in this configuration of IB to ETH through a relay we need the type to be broadcast. The issue is that when using dhclient from the client on Ubuntu (and only on Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in unicast instead of broadcast. It seems there is no way to correct this from the client side using dhclient configuration file. this issue exist even when we use always-broadcast statement in configuration file. in other vendors we see that discover request type is broadcast. attached pcap files from working (other vendor) and not working (Ubuntu) clients. DHCP CLIENT (IPoIB) Ubuntu 14.04 kernel 3.13.0-74 Mellanox OFED 3.1-1.0.3 or inbox driver isc-dhcp-client 4.2.4-7ubuntu12.3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+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 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working
** Tags removed: sts-sponsor -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1529815 Title: InfiniBand DHCP flow with PRA and DHCP relay not working Status in isc-dhcp package in Ubuntu: Fix Released Status in isc-dhcp source package in Trusty: In Progress Status in isc-dhcp source package in Wily: Fix Committed Status in isc-dhcp source package in Xenial: Fix Committed Bug description: [Impact] * Infiniband users relying on DHCP can't use DHCP relay. [Test Case] * Comment #13 * Mellanox has tested themselves. * Clear way of knowing if fix worked (tcpdump). [Regression Potential] * Only related to Infiniband. * Infiniband support could stop working (unlikely, already tested). [Other Info] None [ Original Description ] * Anything else you think is useful to include * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board * and address these questions in advance DHCP client is sending discover with Unicast type request for the offer, in this configuration of IB to ETH through a relay we need the type to be broadcast. The issue is that when using dhclient from the client on Ubuntu (and only on Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in unicast instead of broadcast. It seems there is no way to correct this from the client side using dhclient configuration file. this issue exist even when we use always-broadcast statement in configuration file. in other vendors we see that discover request type is broadcast. attached pcap files from working (other vendor) and not working (Ubuntu) clients. DHCP CLIENT (IPoIB) Ubuntu 14.04 kernel 3.13.0-74 Mellanox OFED 3.1-1.0.3 or inbox driver isc-dhcp-client 4.2.4-7ubuntu12.3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+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 1438510] Re: [REGRESSION] bluetooth headset no longer supports a2dp
Testing with a JBL SB400 BT on a Lenovo Thinkpad T450S with the intel ibt driver on F/W version 37081001103110e23 works correctly. Doing a parallel test on my laptop (HP evo 850) that has : [12383.666088] Bluetooth: hci0: read Intel version: 370710018002030d00 [12383.666095] Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq Fails according to the bug report. So it may be firmware related -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1438510 Title: [REGRESSION] bluetooth headset no longer supports a2dp Status in bluez package in Ubuntu: Confirmed Status in pulseaudio package in Ubuntu: Confirmed Status in bluez source package in Vivid: Confirmed Status in pulseaudio source package in Vivid: Confirmed Bug description: Just installed 15.04 fresh from the latest ISO (beta2). I'm bummed to see my bluetooth headset (Bose Soundlink overear) seems to have regressed in functionality. In 14.10, I was able to set the output profile either to a2dp or hsp/hfp (telephony duplex). In 15.04, it only works in telephony duplex mode. I can't get high fidelity sound playback to work at all. This thread seems to be related, though the workaround within did not solve the problem for me: https://bbs.archlinux.org/viewtopic.php?id=194006 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1438510/+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 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working
** Tags added: sts-sru -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1529815 Title: InfiniBand DHCP flow with PRA and DHCP relay not working Status in isc-dhcp package in Ubuntu: In Progress Status in isc-dhcp source package in Trusty: In Progress Status in isc-dhcp source package in Wily: In Progress Status in isc-dhcp source package in Xenial: In Progress Bug description: [Impact] * Infiniband users relying on DHCP can't use DHCP relay. [Test Case] * Comment #13 * Mellanox has tested themselves. * Clear way of knowing if fix worked (tcpdump). [Regression Potential] * Only related to Infiniband. * Infiniband support could stop working (unlikely, already tested). [Other Info] None [ Original Description ] * Anything else you think is useful to include * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board * and address these questions in advance DHCP client is sending discover with Unicast type request for the offer, in this configuration of IB to ETH through a relay we need the type to be broadcast. The issue is that when using dhclient from the client on Ubuntu (and only on Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in unicast instead of broadcast. It seems there is no way to correct this from the client side using dhclient configuration file. this issue exist even when we use always-broadcast statement in configuration file. in other vendors we see that discover request type is broadcast. attached pcap files from working (other vendor) and not working (Ubuntu) clients. DHCP CLIENT (IPoIB) Ubuntu 14.04 kernel 3.13.0-74 Mellanox OFED 3.1-1.0.3 or inbox driver isc-dhcp-client 4.2.4-7ubuntu12.3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+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 1569292] Re: Can't join to AD domain
** Also affects: packagekit (Ubuntu Xenial) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to packagekit in Ubuntu. https://bugs.launchpad.net/bugs/1569292 Title: Can't join to AD domain Status in realmd: New Status in packagekit package in Ubuntu: In Progress Status in packagekit source package in Xenial: In Progress Bug description: [Impact] When trying to join AD domain via realm command, it hangs. after researching, packagekit got segfault. [Testcase] realm -v join int.domainname.com --user login * Resolving: _ldap._tcp.int.domanname.com * Performing LDAP DSE lookup on: 192.168.xx.xx * Performing LDAP DSE lookup on: 192.168.xx.xx * Successfully discovered: int.domainname.com Password for login: * Unconditionally checking packages * Resolving required packages From here nothing happens. It doesn't go any further. journalctl -b realmd shows: [...] Apr 12 13:02:49 ls-mysql57 realmd[946]: Sending TCP Netlogon request Apr 12 13:02:49 ls-mysql57 realmd[946]: Searching for (objectClass=*) Apr 12 13:02:49 ls-mysql57 realmd[946]: Received TCP Netlogon response Apr 12 13:02:49 ls-mysql57 realmd[946]: * Successfully discovered: int.domainname.com Apr 12 13:02:49 ls-mysql57 realmd[946]: * Successfully discovered: int.domainame.com Apr 12 13:02:53 ls-mysql57 realmd[946]: Using 'r209.955' operation for method 'Join' invocation on 'org.freedesktop.realmd.KerberosMembership' interface Apr 12 13:02:53 ls-mysql57 realmd[946]: Registered cancellable for operation 'r209.955' Apr 12 13:02:53 ls-mysql57 realmd[946]: holding daemon: current-invocation Apr 12 13:02:53 ls-mysql57 realmd[946]: ** (realmd:946): CRITICAL **: realm_invocation_get_cancellable: assertion 'invocation != NULL' failed Apr 12 13:02:53 ls-mysql57 realmd[946]: (realmd:946): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Apr 12 13:02:53 ls-mysql57 realmd[946]: * Unconditionally checking packages Apr 12 13:02:53 ls-mysql57 realmd[946]: * Unconditionally checking packages Apr 12 13:02:53 ls-mysql57 realmd[946]: * Resolving required packages Apr 12 13:02:53 ls-mysql57 realmd[946]: * Resolving required packages Apr 12 13:02:53 ls-mysql57 realmd[946]: realm_invocation_get_cancellable: assertion 'invocation != NULL' failed Apr 12 13:02:53 ls-mysql57 realmd[946]: packages: CreateTransaction call Apr 12 13:02:53 ls-mysql57 realmd[946]: GLib-GObject: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Apr 12 13:02:53 ls-mysql57 realmd[946]: packages: SetHints call Apr 12 13:02:53 ls-mysql57 realmd[946]: packages: call Resolve (262144, ['sssd-tools', 'sssd', 'libnss-sss', 'libpam-sss', 'adcli']) Apr 12 13:02:53 ls-mysql57 realmd[946]: packages: signal: Changed () Apr 12 13:02:53 ls-mysql57 realmd[946]: packages: call Resolve completed Apr 12 13:02:53 ls-mysql57 realmd[946]: packages: signal: Changed () Apr 12 13:02:53 ls-mysql57 realmd[946]: packages: signal: Changed () Apr 12 13:02:53 ls-mysql57 realmd[946]: packages: signal: Changed () It works in 14.04. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: realmd 0.16.2-2 ProcVersionSignature: Ubuntu 4.4.0-18.34-generic 4.4.6 Uname: Linux 4.4.0-18-generic x86_64 ApportVersion: 2.20.1-0ubuntu1 Architecture: amd64 Date: Tue Apr 12 13:08:33 2016 SourcePackage: realmd UpgradeStatus: No upgrade log present (probably fresh install) [Regression Potential] [Other Info] Upstream Patch https://github.com/hughsie/PackageKit/commit/97161e231b2ab406e77977a2a693d7935e33df0f https://github.com/hughsie/PackageKit/commit/06fae067c909db93bb5b1e1d04aa7a987208eda2 https://github.com/hughsie/PackageKit/commit/c64c16c2d1ad9142ec8e74473044874bb6398728 https://github.com/hughsie/PackageKit/commit/e94b80f90179db18221b2eff93b4561b5418fbfb To manage notifications about this bug go to: https://bugs.launchpad.net/realmd/+bug/1569292/+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 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working
** Also affects: isc-dhcp (Ubuntu Xenial) Importance: Undecided Assignee: Rafael David Tinoco (inaddy) Status: In Progress ** Also affects: isc-dhcp (Ubuntu Wily) Importance: Undecided Status: New ** Also affects: isc-dhcp (Ubuntu Trusty) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1529815 Title: InfiniBand DHCP flow with PRA and DHCP relay not working Status in isc-dhcp package in Ubuntu: In Progress Status in isc-dhcp source package in Trusty: In Progress Status in isc-dhcp source package in Wily: In Progress Status in isc-dhcp source package in Xenial: In Progress Bug description: DHCP client is sending discover with Unicast type request for the offer, in this configuration of IB to ETH through a relay we need the type to be broadcast. The issue is that when using dhclient from the client on Ubuntu (and only on Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in unicast instead of broadcast. It seems there is no way to correct this from the client side using dhclient configuration file. this issue exist even when we use always-broadcast statement in configuration file. in other vendors we see that discover request type is broadcast. attached pcap files from working (other vendor) and not working (Ubuntu) clients. DHCP CLIENT (IPoIB) Ubuntu 14.04 kernel 3.13.0-74 Mellanox OFED 3.1-1.0.3 or inbox driver isc-dhcp-client 4.2.4-7ubuntu12.3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+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 1534106] Re: rsyslogd crashed with SIGSEGV with juju-local configuration
This bug has been fixed by the latest upload of rsyslog : https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1539483. Marking it fix released ** Changed in: juju-core (Ubuntu) Status: Confirmed => Invalid ** Changed in: rsyslog (Ubuntu) Status: Triaged => Fix Released ** Changed in: rsyslog (Ubuntu) Assignee: Louis Bouchard (louis-bouchard) => (unassigned) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1534106 Title: rsyslogd crashed with SIGSEGV with juju-local configuration Status in juju-core package in Ubuntu: Invalid Status in rsyslog package in Ubuntu: Fix Released Bug description: installing juju-local pulls in rsyslog (at least on current xenial). When doing - juju init - edit ~/.juju/environments.yaml to set "local" as default - juju boostrap this creates a file /etc/rsyslog.d/25-juju-USERNAME-local.conf and restarts rsyslog. rsyslog then crashes like this with this configuration. ProblemType: Crash DistroRelease: Ubuntu 16.04 Package: rsyslog 8.14.0-2ubuntu2 ProcVersionSignature: Ubuntu 4.3.0-5.16-generic 4.3.3 Uname: Linux 4.3.0-5-generic x86_64 ApportVersion: 2.19.3-0ubuntu3 Architecture: amd64 CrashCounter: 1 Date: Thu Jan 14 12:18:18 2016 EcryptfsInUse: Yes ExecutablePath: /usr/sbin/rsyslogd ProcCmdline: /usr/sbin/rsyslogd -n ProcEnviron: LANG=de_DE.UTF-8 PATH=(custom, no user) SegvAnalysis: Segfault happened at: 0x7efcf17d196e:mov0x58(%rax),%rax PC (0x7efcf17d196e) ok source "0x58(%rax)" (0x0058) not located in a known VMA region (needed readable region)! destination "%rax" ok Stack memory exhausted (SP below stack segment) SegvReason: reading NULL VMA Signal: 11 SourcePackage: rsyslog StacktraceTop: ?? () from /usr/lib/rsyslog/lmnsd_gtls.so ?? () from /usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28 ?? () from /usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28 ?? () from /usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28 ?? () from /usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28 Title: rsyslogd crashed with SIGSEGV UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1534106/+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 1539483] Re: Please merge rsyslog 8.16.0-1 (main) from Debian unstable (main)
Debian current to new merge debdiff ** Patch added: "debian_8.16.0-1-ubuntu-8.16.0-1ubuntu1.debdiff" https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1539483/+attachment/4562866/+files/debian_8.16.0-1-ubuntu-8.16.0-1ubuntu1.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1539483 Title: Please merge rsyslog 8.16.0-1 (main) from Debian unstable (main) Status in rsyslog package in Ubuntu: Confirmed Bug description: merge bug To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1539483/+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 1539483] Re: Please merge rsyslog 8.16.0-1 (main) from Debian unstable (main)
** Patch removed: "debian_8.16.0-1-ubuntu-8.16.0-1ubuntu1_v2.debdiff" https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1539483/+attachment/4562891/+files/debian_8.16.0-1-ubuntu-8.16.0-1ubuntu1_v2.debdiff ** Patch removed: "ubuntu-8.14.0-2ubuntu2-8.16.0-1ubuntu1_v2.debdiff" https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1539483/+attachment/4562892/+files/ubuntu-8.14.0-2ubuntu2-8.16.0-1ubuntu1_v2.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1539483 Title: Please merge rsyslog 8.16.0-1 (main) from Debian unstable (main) Status in rsyslog package in Ubuntu: Confirmed Bug description: merge bug To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1539483/+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 1539483] Re: Please merge rsyslog 8.16.0-1 (main) from Debian unstable (main)
Updated d-u debdiff ** Patch added: "debian_8.16.0-1-ubuntu-8.16.0-1ubuntu1_v2.debdiff" https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1539483/+attachment/4562891/+files/debian_8.16.0-1-ubuntu-8.16.0-1ubuntu1_v2.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1539483 Title: Please merge rsyslog 8.16.0-1 (main) from Debian unstable (main) Status in rsyslog package in Ubuntu: Confirmed Bug description: merge bug To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1539483/+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 1539483] Re: Please merge rsyslog 8.16.0-1 (main) from Debian unstable (main)
updated u-u debdiff ** Patch added: "ubuntu-8.14.0-2ubuntu2-8.16.0-1ubuntu1_v2.debdiff" https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1539483/+attachment/4562892/+files/ubuntu-8.14.0-2ubuntu2-8.16.0-1ubuntu1_v2.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1539483 Title: Please merge rsyslog 8.16.0-1 (main) from Debian unstable (main) Status in rsyslog package in Ubuntu: Confirmed Bug description: merge bug To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1539483/+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 1539483] Re: Please merge rsyslog 8.16.0-1 (main) from Debian unstable (main)
** Patch added: "debian_8.16.0-1-ubuntu-8.16.0-1ubuntu1_v2.debdiff" https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1539483/+attachment/4562903/+files/debian_8.16.0-1-ubuntu-8.16.0-1ubuntu1_v2.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1539483 Title: Please merge rsyslog 8.16.0-1 (main) from Debian unstable (main) Status in rsyslog package in Ubuntu: Confirmed Bug description: merge bug To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1539483/+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 1539483] Re: Please merge rsyslog 8.16.0-1 (main) from Debian unstable (main)
** Patch added: "ubuntu-8.14.0-2ubuntu2-8.16.0-1ubuntu1_v2.debdiff" https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1539483/+attachment/4562904/+files/ubuntu-8.14.0-2ubuntu2-8.16.0-1ubuntu1_v2.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1539483 Title: Please merge rsyslog 8.16.0-1 (main) from Debian unstable (main) Status in rsyslog package in Ubuntu: Confirmed Bug description: merge bug To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1539483/+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 1539483] Re: Please merge rsyslog 8.16.0-1 (main) from Debian unstable (main)
debdiff : previous merge to current ** Patch added: "ubuntu-8.14.0-2ubuntu2-8.16.0-1ubuntu1.debdiff" https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1539483/+attachment/4562865/+files/ubuntu-8.14.0-2ubuntu2-8.16.0-1ubuntu1.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsyslog in Ubuntu. https://bugs.launchpad.net/bugs/1539483 Title: Please merge rsyslog 8.16.0-1 (main) from Debian unstable (main) Status in rsyslog package in Ubuntu: Confirmed Bug description: merge bug To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1539483/+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
