[Group.of.nepali.translators] [Bug 1927547] Re: seabios missing NMI disable in rtc_mask()
** Also affects: cloud-archive Importance: Undecided Status: New ** Also affects: cloud-archive/mitaka Importance: Undecided Status: New ** Changed in: cloud-archive Status: New => Fix Released ** Changed in: cloud-archive Importance: Undecided => High ** Changed in: cloud-archive/mitaka Importance: Undecided => High ** Changed in: cloud-archive/mitaka Status: New => Confirmed ** Changed in: cloud-archive/mitaka Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: cloud-archive Assignee: (unassigned) => Heitor Alves de Siqueira (halves) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1927547 Title: seabios missing NMI disable in rtc_mask() Status in Ubuntu Cloud Archive: Fix Released Status in Ubuntu Cloud Archive mitaka series: Confirmed Status in seabios package in Ubuntu: Fix Released Status in seabios source package in Trusty: Fix Released Status in seabios source package in Xenial: Fix Released Bug description: [Impact] On seabios before rel-1.9.0~47, there's a bug in rtc_mask() that can cause VMs to miss interrupts and get stuck in a 'PAUSED' state due to KVM emulation errors. While reading PORT_CMOS_DATA, an NMI can "steal" execution before the inb() call returns, which effectively leaves the guest waiting on the port read forever. This can then trigger watchdogs, and usually results in an KVM emulation error leaving the VM in the 'PAUSED' state. Since the guest VM is broken due to the missed interrupts, the only way to recover is restarting it. [Test Plan] Due to the somewhat small race window involved between the inb() call and an NMI coming in, this issue has been hard to reproduce consistently. Our test plan involves running the fixes in a heavily overcommited Openstack compute host where this issue has been reported multiple times, to also validate that no new regressions have been introduced. [Where problems could occur] The patch disables NMIs in rtc_mask(), so that it stays consistent with the other rtc_*() functions in seabios/srs/hw/rtc.c. After the CMOS port access finishes and the guest resumes execution, we could see regressions with missed interrupts or NMIs not being handled if they are not re-enabled. Since the patch is already present in all Ubuntu releases starting with Bionic and there have been no 'fixes:' tags for this patch upstream, the chance for new regressions should be fairly limited. [Other Info] This has been fixed by the following upstream patch: - 3156b71a535e (rtc: Disable NMI in rtc_mask()) [0] $ git describe --contains 3156b71a535e661 rel-1.9.0~47 $ rmadison seabios -s trusty-updates,xenial,bionic seabios | 1.7.4-4ubuntu1 | trusty-updates | source, all seabios | 1.8.2-1ubuntu1 | xenial | source, all seabios | 1.10.2-1ubuntu1 | bionic | source, all Releases starting with Bionic already have this fix. [0] https://review.coreboot.org/plugins/gitiles/seabios/+/3156b71a535e661%5E%21/#F0 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1927547/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1927547] Re: seabios missing NMI disable in rtc_mask()
Fixes are now available under the "ESM Infrastructure Security" PPA for Trusty and Xenial, according to the versions below: Trusty -- 1.7.4-4ubuntu1+esm1 Xenial -- 1.8.2-1ubuntu1+esm1 ** Changed in: seabios (Ubuntu Trusty) Status: In Progress => Fix Released ** Changed in: seabios (Ubuntu Xenial) Status: In Progress => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1927547 Title: seabios missing NMI disable in rtc_mask() Status in seabios package in Ubuntu: Fix Released Status in seabios source package in Trusty: Fix Released Status in seabios source package in Xenial: Fix Released Bug description: [Impact] On seabios before rel-1.9.0~47, there's a bug in rtc_mask() that can cause VMs to miss interrupts and get stuck in a 'PAUSED' state due to KVM emulation errors. While reading PORT_CMOS_DATA, an NMI can "steal" execution before the inb() call returns, which effectively leaves the guest waiting on the port read forever. This can then trigger watchdogs, and usually results in an KVM emulation error leaving the VM in the 'PAUSED' state. Since the guest VM is broken due to the missed interrupts, the only way to recover is restarting it. [Test Plan] Due to the somewhat small race window involved between the inb() call and an NMI coming in, this issue has been hard to reproduce consistently. Our test plan involves running the fixes in a heavily overcommited Openstack compute host where this issue has been reported multiple times, to also validate that no new regressions have been introduced. [Where problems could occur] The patch disables NMIs in rtc_mask(), so that it stays consistent with the other rtc_*() functions in seabios/srs/hw/rtc.c. After the CMOS port access finishes and the guest resumes execution, we could see regressions with missed interrupts or NMIs not being handled if they are not re-enabled. Since the patch is already present in all Ubuntu releases starting with Bionic and there have been no 'fixes:' tags for this patch upstream, the chance for new regressions should be fairly limited. [Other Info] This has been fixed by the following upstream patch: - 3156b71a535e (rtc: Disable NMI in rtc_mask()) [0] $ git describe --contains 3156b71a535e661 rel-1.9.0~47 $ rmadison seabios -s trusty-updates,xenial,bionic seabios | 1.7.4-4ubuntu1 | trusty-updates | source, all seabios | 1.8.2-1ubuntu1 | xenial | source, all seabios | 1.10.2-1ubuntu1 | bionic | source, all Releases starting with Bionic already have this fix. [0] https://review.coreboot.org/plugins/gitiles/seabios/+/3156b71a535e661%5E%21/#F0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/seabios/+bug/1927547/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1927547] [NEW] seabios missing NMI disable in rtc_mask()
Public bug reported: [Impact] On seabios before rel-1.9.0~47, there's a bug in rtc_mask() that can cause VMs to miss interrupts and get stuck in a 'PAUSED' state due to KVM emulation errors. While reading PORT_CMOS_DATA, an NMI can "steal" execution before the inb() call returns, which effectively leaves the guest waiting on the port read forever. This can then trigger watchdogs, and usually results in an KVM emulation error leaving the VM in the 'PAUSED' state. Since the guest VM is broken due to the missed interrupts, the only way to recover is restarting it. [Test Plan] Due to the somewhat small race window involved between the inb() call and an NMI coming in, this issue has been hard to reproduce consistently. Our test plan involves running the fixes in a heavily overcommited Openstack compute host where this issue has been reported multiple times, to also validate that no new regressions have been introduced. [Where problems could occur] The patch disables NMIs in rtc_mask(), so that it stays consistent with the other rtc_*() functions in seabios/srs/hw/rtc.c. After the CMOS port access finishes and the guest resumes execution, we could see regressions with missed interrupts or NMIs not being handled if they are not re-enabled. Since the patch is already present in all Ubuntu releases starting with Bionic and there have been no 'fixes:' tags for this patch upstream, the chance for new regressions should be fairly limited. [Other Info] This has been fixed by the following upstream patch: - 3156b71a535e (rtc: Disable NMI in rtc_mask()) [0] $ git describe --contains 3156b71a535e661 rel-1.9.0~47 $ rmadison seabios -s trusty-updates,xenial,bionic seabios | 1.7.4-4ubuntu1 | trusty-updates | source, all seabios | 1.8.2-1ubuntu1 | xenial | source, all seabios | 1.10.2-1ubuntu1 | bionic | source, all Releases starting with Bionic already have this fix. [0] https://review.coreboot.org/plugins/gitiles/seabios/+/3156b71a535e661%5E%21/#F0 ** Affects: seabios (Ubuntu) Importance: High Assignee: Heitor Alves de Siqueira (halves) Status: Fix Released ** Affects: seabios (Ubuntu Trusty) Importance: High Assignee: Heitor Alves de Siqueira (halves) Status: Confirmed ** Affects: seabios (Ubuntu Xenial) Importance: High Assignee: Heitor Alves de Siqueira (halves) Status: Confirmed ** Tags: sts ** Changed in: seabios (Ubuntu) Status: Confirmed => Fix Released ** Also affects: seabios (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: seabios (Ubuntu Trusty) Importance: Undecided Status: New ** Changed in: seabios (Ubuntu Trusty) Status: New => In Progress ** Changed in: seabios (Ubuntu Xenial) Status: New => Confirmed ** Changed in: seabios (Ubuntu Trusty) Status: In Progress => Confirmed ** Changed in: seabios (Ubuntu Trusty) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: seabios (Ubuntu Xenial) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: seabios (Ubuntu Trusty) Importance: Undecided => High ** Changed in: seabios (Ubuntu Xenial) Importance: Undecided => High -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1927547 Title: seabios missing NMI disable in rtc_mask() Status in seabios package in Ubuntu: Fix Released Status in seabios source package in Trusty: Confirmed Status in seabios source package in Xenial: Confirmed Bug description: [Impact] On seabios before rel-1.9.0~47, there's a bug in rtc_mask() that can cause VMs to miss interrupts and get stuck in a 'PAUSED' state due to KVM emulation errors. While reading PORT_CMOS_DATA, an NMI can "steal" execution before the inb() call returns, which effectively leaves the guest waiting on the port read forever. This can then trigger watchdogs, and usually results in an KVM emulation error leaving the VM in the 'PAUSED' state. Since the guest VM is broken due to the missed interrupts, the only way to recover is restarting it. [Test Plan] Due to the somewhat small race window involved between the inb() call and an NMI coming in, this issue has been hard to reproduce consistently. Our test plan involves running the fixes in a heavily overcommited Openstack compute host where this issue has been reported multiple times, to also validate that no new regressions have been introduced. [Where problems could occur] The patch disables NMIs in rtc_mask(), so that it stays consistent with the other rtc_*() functions in seabios/srs/hw/rtc.c. After the CMOS port access finishes and the guest resumes execution, we could see regressions with missed interrupts or NMIs not being handled if they are not re-enabled. Sinc
[Group.of.nepali.translators] [Bug 1916486] Re: zfs_zrele_async can cause txg sync deadlocks
** Changed in: zfs-linux (Ubuntu Hirsute) Status: In Progress => Fix Released ** Changed in: zfs-linux (Ubuntu Hirsute) Assignee: Heitor Alves de Siqueira (halves) => (unassigned) ** Description changed: [Impact] TXG sync stalls, causing ZFS workloads to hang indefinitely [Description] For certain ZFS workloads, we can see hung task timeouts in the kernel logs due to a transaction group deadlock. Userspace process will hang and display stack traces similar to the one below: [49181.619711] clnt_server D0 21699 28868 0x0320 [49181.619715] Call Trace: [49181.619725] __schedule+0x24e/0x880 [49181.619730] schedule+0x2c/0x80 [49181.619750] cv_wait_common+0x11e/0x140 [spl] [49181.619763] ? wait_woken+0x80/0x80 [49181.619775] __cv_wait+0x15/0x20 [spl] [49181.619872] zil_commit.part.14+0x80/0x8c0 [zfs] [49181.619884] ? _cond_resched+0x19/0x40 [49181.619887] ? mutex_lock+0x12/0x40 [49181.619959] zil_commit+0x17/0x20 [zfs] [49181.620026] zfs_fsync+0x77/0xe0 [zfs] [49181.620093] zpl_fsync+0x68/0xa0 [zfs] [49181.620100] vfs_fsync_range+0x51/0xb0 [49181.620105] do_fsync+0x3d/0x70 [49181.620109] SyS_fsync+0x10/0x20 [49181.620114] do_syscall_64+0x73/0x130 [49181.620119] entry_SYSCALL_64_after_hwframe+0x41/0xa6 We also might see a kworker thread blocking in the zfs writeback/evict path: [49181.881570] kworker/u17:3 D0 4915 2 0x8000 [49181.881576] Workqueue: writeback wb_workfn (flush-zfs-10) [49181.881577] Call Trace: [49181.881580] __schedule+0x24e/0x880 [49181.881582] ? atomic_t_wait+0x60/0x60 [49181.881584] schedule+0x2c/0x80 [49181.881588] bit_wait+0x11/0x60 [49181.881592] __wait_on_bit+0x4c/0x90 [49181.881596] ? atomic_t_wait+0x60/0x60 [49181.881599] __inode_wait_for_writeback+0xb9/0xf0 [49181.881601] ? bit_waitqueue+0x40/0x40 [49181.881605] inode_wait_for_writeback+0x26/0x40 [49181.881609] evict+0xb5/0x1a0 [49181.881611] iput+0x19c/0x230 [49181.881648] zfs_iput_async+0x1d/0x80 [zfs] [49181.881682] zfs_get_data+0x1d4/0x2a0 [zfs] [49181.881718] zil_commit.part.14+0x640/0x8c0 [zfs] [49181.881752] zil_commit+0x17/0x20 [zfs] [49181.881784] zpl_writepages+0xd5/0x160 [zfs] [49181.881787] do_writepages+0x4b/0xe0 [49181.881790] __writeback_single_inode+0x45/0x350 [49181.881792] ? __writeback_single_inode+0x45/0x350 [49181.881794] writeback_sb_inodes+0x1d7/0x530 [49181.881796] wb_writeback+0xfb/0x300 [49181.881799] wb_workfn+0xad/0x400 [49181.881800] ? wb_workfn+0xad/0x400 [49181.881803] ? __switch_to_asm+0x35/0x70 [49181.881809] process_one_work+0x1de/0x420 [49181.881811] worker_thread+0x32/0x410 [49181.881813] kthread+0x121/0x140 [49181.881815] ? process_one_work+0x420/0x420 [49181.881817] ? kthread_create_worker_on_cpu+0x70/0x70 [49181.881819] ret_from_fork+0x35/0x40 This is caused by a race between ZFS writeback and evict threads, usually during a transaction group sync operation. It's possible to have two iput() threads racing for the same inode: one of them scheduled async and the other executed synchronously as part of the writeback path. If the writeback thread tries to evict the inode while the async thread is running, it might re-enter the block layer for the same inode due to ZFS counters being in an inconsistent state. This then causes the kworker thread to stall the writeback, which in turn prevents the transaction group sync to complete and locks other ZFS threads. This is fixed by the upstream commit: - - Fix zrele race in zrele_async that can cause hang (2921ad6cba54) [0] + - Fix zrele race in zrele_async that can cause hang (43eaef6de817) [0] [Test Case] Being a race condition, this issue has been hard to reproduce consistently. This has been reported on heavy I/O workloads, mixing file creation and deletion. We have some reports both from upstream and from Ubuntu users that this is usually reproducible on e.g. heavy SQL workloads or on complex ccache-enabled builds [1]. [0] https://github.com/openzfs/zfs/pull/11530 [1] https://github.com/openzfs/zfs/issues/11527 [Regression Potential] The patch has been tested in the ZFS test suite and in production environments, so the potential for further regressions should be fairly controlled. Potential regressions might arise in the ZFS writeback path, so we should monitor heavy I/O workloads that put a lot of stress in the sync and evict paths. -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1916486 Title: zfs_zrele_async can cause txg sync deadlocks Status in zfs-linux package in Ubuntu: Fix Released Status in zfs-linux source package in Xenial: In Progress Status in zfs-linux source package in Bionic: In Progress Status in zfs-linux
[Group.of.nepali.translators] [Bug 1916486] Re: zfs_zrele_async can cause txg sync deadlocks
** Changed in: zfs-linux (Ubuntu Bionic) Status: New => In Progress ** Changed in: zfs-linux (Ubuntu Xenial) Status: New => In Progress ** Changed in: zfs-linux (Ubuntu Focal) Status: New => In Progress ** Changed in: zfs-linux (Ubuntu Groovy) Status: New => In Progress ** Changed in: zfs-linux (Ubuntu Hirsute) Status: Confirmed => In Progress ** Bug watch added: Debian Bug tracker #983331 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983331 ** Also affects: zfs-linux (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983331 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1916486 Title: zfs_zrele_async can cause txg sync deadlocks Status in zfs-linux package in Ubuntu: In Progress Status in zfs-linux source package in Xenial: In Progress Status in zfs-linux source package in Bionic: In Progress Status in zfs-linux source package in Focal: In Progress Status in zfs-linux source package in Groovy: In Progress Status in zfs-linux source package in Hirsute: In Progress Status in zfs-linux package in Debian: Unknown Bug description: [Impact] TXG sync stalls, causing ZFS workloads to hang indefinitely [Description] For certain ZFS workloads, we can see hung task timeouts in the kernel logs due to a transaction group deadlock. Userspace process will hang and display stack traces similar to the one below: [49181.619711] clnt_server D0 21699 28868 0x0320 [49181.619715] Call Trace: [49181.619725] __schedule+0x24e/0x880 [49181.619730] schedule+0x2c/0x80 [49181.619750] cv_wait_common+0x11e/0x140 [spl] [49181.619763] ? wait_woken+0x80/0x80 [49181.619775] __cv_wait+0x15/0x20 [spl] [49181.619872] zil_commit.part.14+0x80/0x8c0 [zfs] [49181.619884] ? _cond_resched+0x19/0x40 [49181.619887] ? mutex_lock+0x12/0x40 [49181.619959] zil_commit+0x17/0x20 [zfs] [49181.620026] zfs_fsync+0x77/0xe0 [zfs] [49181.620093] zpl_fsync+0x68/0xa0 [zfs] [49181.620100] vfs_fsync_range+0x51/0xb0 [49181.620105] do_fsync+0x3d/0x70 [49181.620109] SyS_fsync+0x10/0x20 [49181.620114] do_syscall_64+0x73/0x130 [49181.620119] entry_SYSCALL_64_after_hwframe+0x41/0xa6 We also might see a kworker thread blocking in the zfs writeback/evict path: [49181.881570] kworker/u17:3 D0 4915 2 0x8000 [49181.881576] Workqueue: writeback wb_workfn (flush-zfs-10) [49181.881577] Call Trace: [49181.881580] __schedule+0x24e/0x880 [49181.881582] ? atomic_t_wait+0x60/0x60 [49181.881584] schedule+0x2c/0x80 [49181.881588] bit_wait+0x11/0x60 [49181.881592] __wait_on_bit+0x4c/0x90 [49181.881596] ? atomic_t_wait+0x60/0x60 [49181.881599] __inode_wait_for_writeback+0xb9/0xf0 [49181.881601] ? bit_waitqueue+0x40/0x40 [49181.881605] inode_wait_for_writeback+0x26/0x40 [49181.881609] evict+0xb5/0x1a0 [49181.881611] iput+0x19c/0x230 [49181.881648] zfs_iput_async+0x1d/0x80 [zfs] [49181.881682] zfs_get_data+0x1d4/0x2a0 [zfs] [49181.881718] zil_commit.part.14+0x640/0x8c0 [zfs] [49181.881752] zil_commit+0x17/0x20 [zfs] [49181.881784] zpl_writepages+0xd5/0x160 [zfs] [49181.881787] do_writepages+0x4b/0xe0 [49181.881790] __writeback_single_inode+0x45/0x350 [49181.881792] ? __writeback_single_inode+0x45/0x350 [49181.881794] writeback_sb_inodes+0x1d7/0x530 [49181.881796] wb_writeback+0xfb/0x300 [49181.881799] wb_workfn+0xad/0x400 [49181.881800] ? wb_workfn+0xad/0x400 [49181.881803] ? __switch_to_asm+0x35/0x70 [49181.881809] process_one_work+0x1de/0x420 [49181.881811] worker_thread+0x32/0x410 [49181.881813] kthread+0x121/0x140 [49181.881815] ? process_one_work+0x420/0x420 [49181.881817] ? kthread_create_worker_on_cpu+0x70/0x70 [49181.881819] ret_from_fork+0x35/0x40 This is caused by a race between ZFS writeback and evict threads, usually during a transaction group sync operation. It's possible to have two iput() threads racing for the same inode: one of them scheduled async and the other executed synchronously as part of the writeback path. If the writeback thread tries to evict the inode while the async thread is running, it might re-enter the block layer for the same inode due to ZFS counters being in an inconsistent state. This then causes the kworker thread to stall the writeback, which in turn prevents the transaction group sync to complete and locks other ZFS threads. This is fixed by the upstream commit: - Fix zrele race in zrele_async that can cause hang (2921ad6cba54) [0] [Test Case] Being a race condition, this issue has been hard to reproduce consistently. This has been reported on heavy I/O workloads, mixing file creation and deletion. We have some reports both from upstream and from
[Group.of.nepali.translators] [Bug 1772675] Re: Intel i40e PF reset due to incorrect MDD detection (continues...again...)
The patch [0] is present in Ubuntu releases starting with Focal, so it should be fixed for that and later releases (including current bionic- hwe). I'll look into backporting and testing this for Xenial and Bionic GA. $ git log --oneline -1 a1df906c5be7 a1df906c5be7 i40e: change behavior on PF in response to MDD event $ git describe --contains a1df906c5be7 v5.2-rc1~133^2~57^2~9 [0] https://git.kernel.org/linus/a1df906c5be7 ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: linux (Ubuntu Xenial) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: linux (Ubuntu Cosmic) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: linux (Ubuntu Bionic) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: linux (Ubuntu) Status: Expired => Fix Released ** Changed in: linux (Ubuntu Xenial) Status: Expired => In Progress ** Changed in: linux (Ubuntu Bionic) Status: Expired => In Progress ** Changed in: linux (Ubuntu Cosmic) Status: Expired => In Progress ** Tags added: sts ** Changed in: linux (Ubuntu Cosmic) Status: In Progress => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1772675 Title: Intel i40e PF reset due to incorrect MDD detection (continues...again...) Status in linux package in Ubuntu: Fix Released Status in linux source package in Xenial: In Progress Status in linux source package in Bionic: In Progress Status in linux source package in Cosmic: Won't Fix Bug description: [impact] The i40e driver sometimes causes a "malicious device" event that the firmware detects, which causes the firmware to reset the nic, causing an interruption in the network connection - which can cause further problems, e.g. if the interface is in a bond; the reset will at least cause a temporary interruption in network traffic. [fix] The fix for this is currently unknown. As the "MDD event" is generated by the i40e firmware, and is completely undocumented, there is no way to tell what the i40e driver did to cause the MDD event. [test case] the bug is unfortunately very difficult to reproduce, but as shown in this (and previous) bug comments, some users of the i40e have traffic that can consistently reproduce the problem (although usually on the order of days, or longer, to reproduce). Reproducing is easily detected, as the nw traffic will be interrupted and the system logs will contain a message like: i40e :02:00.1: TX driver issue detected, PF reset issued [regression potential] unknown since the specific fix is unknown. [original description] This is a continuation from bug 1713553 and then bug 1723127; a patch was added in the first bug and then the second bug, to attempt to fix this, and it may have helped reduce the issue but appears not to have fixed it, based on more reports. See bug 1713553 and bug 1723127 for more details. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1772675/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1876600] Re: cookie overruns cause org.freedesktop.systemd1 dbus to hang
** Also affects: systemd (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu) Status: New => Fix Released ** Changed in: systemd (Ubuntu Xenial) Status: New => Confirmed ** Changed in: systemd (Ubuntu Bionic) Status: New => Confirmed ** Changed in: systemd (Ubuntu Xenial) Importance: Undecided => High ** Changed in: systemd (Ubuntu Bionic) Importance: Undecided => High ** Changed in: systemd (Ubuntu Bionic) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: systemd (Ubuntu Xenial) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1876600 Title: cookie overruns cause org.freedesktop.systemd1 dbus to hang Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Status in systemd source package in Bionic: Confirmed Bug description: [Impact] Long-running services overflow the sd_bus->cookie counter, causing further communication with org.freedesktop.systemd1 to stall. [Description] Systemd dbus messages usually include a "cookie" value to uniquely identify them in their bus context. For services that run for longer periods of time and keep communicating through dbus, it's possible to overflow the cookie value, causing further messages to the org.freedesktop.systemd1 dbus to hang. This has been fixed upstream by the commit below: - sd-bus: deal with cookie overruns (1f82f5bb4237) $ git describe --contains 1f82f5bb4237 v242-rc1~228 $ rmadison systemd systemd | 229-4ubuntu4 | xenial | source, ... systemd | 229-4ubuntu21.27 | xenial-security | source, ... systemd | 229-4ubuntu21.27 | xenial-updates | source, ... systemd | 229-4ubuntu21.28 | xenial-proposed | source, ... systemd | 237-3ubuntu10| bionic | source, ... systemd | 237-3ubuntu10.38 | bionic-security | source, ... systemd | 237-3ubuntu10.39 | bionic-updates | source, ... systemd | 237-3ubuntu10.40 | bionic-proposed | source, ... < systemd | 242-7ubuntu3 | eoan| source, ... Releases starting with Eoan already have this fix. [Test Case] There doesn't seem to be an easy test case for this, as the cookie values start at zero and won't overflow until (1<<32). There have been reports from users hitting this on Kubernetes clusters continuously running for longer periods (~5 months). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1876600/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1869229] [NEW] Mounting LVM snapshots with xfs can hit kernel BUG in nvme driver
Public bug reported:
[Impact]
When mounting LVM snapshots using xfs, it's possible to hit a BUG_ON() in nvme
driver.
Upstream commit 729204ef49ec ("block: relax check on sg gap") introduced
a way to merge bios if they are physically contiguous. This can lead to
issues if one rq starts with a non-aligned buffer, as it can cause the
merged segment to end in an unaligned virtual boundary. In some AWS
instances, it's possible to craft such a request when attempting to
mount LVM snapshots using xfs. This will then cause a kernel spew due to
a BUG_ON in nvme_setup_prps(), which checks if dma_len is aligned to the
page size.
[Fix]
Upstream commit 5a8d75a1b8c9 ("block: fix bio_will_gap() for first bvec with
offset") disallows requests that begin with an unaligned buffer from being
merged.
[Test Case]
This has been verified on AWS with c5d.large instances:
1) Prepare the LVM device + snapshot
$ sudo vgcreate vg0 /dev/nvme1n1
$ sudo lvcreate -L5G -n data0 vg0
$ sudo mkfs.xfs /dev/vg0/data0
$ sudo mount /dev/vg0/data0 /mnt
$ sudo touch /mnt/test
$ sudo touch /mnt/test2
$ sudo ls /mnt
$ sudo umount /mnt
$ sudo lvcreate -l100%FREE -s /dev/vg0/data0 -n data0_snap
2) Attempting to mount the previously created snapshot results in the Oops:
$ sudo mount /dev/vg0/data0_snap /mnt
Segmentation fault (core dumped)
[Regression Potential]
The fix prevents some bios from being merged, so it can have a performance
impact in certain scenarios. The patch only targets misaligned segments, so the
impact should be less noticeable in the general case.
The commit is also present in mainline kernels since 4.13, and hasn't been
changed significantly, so potential for other regressions should be low.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: Fix Released
** Affects: linux (Ubuntu Xenial)
Importance: Undecided
Status: New
** Tags: sts
** Changed in: linux (Ubuntu)
Assignee: Heitor Alves de Siqueira (halves) => (unassigned)
** Also affects: linux (Ubuntu Xenial)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu)
Status: New => Fix Released
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1869229
Title:
Mounting LVM snapshots with xfs can hit kernel BUG in nvme driver
Status in linux package in Ubuntu:
Fix Released
Status in linux source package in Xenial:
New
Bug description:
[Impact]
When mounting LVM snapshots using xfs, it's possible to hit a BUG_ON() in
nvme driver.
Upstream commit 729204ef49ec ("block: relax check on sg gap")
introduced a way to merge bios if they are physically contiguous. This
can lead to issues if one rq starts with a non-aligned buffer, as it
can cause the merged segment to end in an unaligned virtual boundary.
In some AWS instances, it's possible to craft such a request when
attempting to mount LVM snapshots using xfs. This will then cause a
kernel spew due to a BUG_ON in nvme_setup_prps(), which checks if
dma_len is aligned to the page size.
[Fix]
Upstream commit 5a8d75a1b8c9 ("block: fix bio_will_gap() for first bvec with
offset") disallows requests that begin with an unaligned buffer from being
merged.
[Test Case]
This has been verified on AWS with c5d.large instances:
1) Prepare the LVM device + snapshot
$ sudo vgcreate vg0 /dev/nvme1n1
$ sudo lvcreate -L5G -n data0 vg0
$ sudo mkfs.xfs /dev/vg0/data0
$ sudo mount /dev/vg0/data0 /mnt
$ sudo touch /mnt/test
$ sudo touch /mnt/test2
$ sudo ls /mnt
$ sudo umount /mnt
$ sudo lvcreate -l100%FREE -s /dev/vg0/data0 -n data0_snap
2) Attempting to mount the previously created snapshot results in the Oops:
$ sudo mount /dev/vg0/data0_snap /mnt
Segmentation fault (core dumped)
[Regression Potential]
The fix prevents some bios from being merged, so it can have a performance
impact in certain scenarios. The patch only targets misaligned segments, so the
impact should be less noticeable in the general case.
The commit is also present in mainline kernels since 4.13, and hasn't been
changed significantly, so potential for other regressions should be low.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869229/+subscriptions
___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1410558] Re: PS_FORMAT=thcount does not work anymore
** Tags added: sts ** Description changed: - In Ubuntu 12.04.5 LTS (procps 1:3.2.8-11ubuntu6.3), the following worked - fine: + [Impact] + ps -o thcount doesn't print out an error (error: unknown user-defined format specifier "thcount") + + [Description] + The Xenial version of procps has a bug in the thcount format specifier. ps doesn't recognize it, and complains about an unknown user-defined format. + This is due to the format specifier table in ps/output.c, which is queried with a binary search. Since the "thcount" entry appears out of order in Xenial, it can't be looked up and the program fails with the "unknown user-defined format specifier" error. + + This has been fixed upstream by the commit below: + - Fix for Bug:1174313 (3a52dfa34027) + + $ git describe --contains 3a52dfa34027 + v3.3.12~58^2 + + $ rmadison procps + procps | 2:3.3.10-4ubuntu2 | xenial | source, ... + procps | 2:3.3.10-4ubuntu2.4 | xenial-security | source, ... + procps | 2:3.3.10-4ubuntu2.4 | xenial-updates | source, ... < + procps | 2:3.3.12-3ubuntu1 | bionic | source, ... + procps | 2:3.3.12-3ubuntu1.1 | bionic-security | source, ... + procps | 2:3.3.12-3ubuntu1.2 | bionic-updates | source, ... + + Releases starting with Bionic already have this fix, so it's only needed + for Xenial. + + [Test case] + 1. Boot up a Xenial environment with e.g. an lxd container: + # lxc launch images:ubuntu/xenial xenial + + 2. Execute ps with the '-o thcount' options: + # lxc exec xenial -- ps -o thcount + error: unknown user-defined format specifier "thcount" + + Usage: + ps [options] + + Try 'ps --help ' + or 'ps --help ' + for additional help text. + + For more details see ps(1). + + [Regression Potential] + The fix just fixes the order of two entries in the format specifier array, so the regression potential is very low. Furthermore, the patch has been present and tested in up-to-date versions of procps since Bionic. Any new regressions introduced in Xenial will be checked with autopkgtest. + + [Original Description] + In Ubuntu 12.04.5 LTS (procps 1:3.2.8-11ubuntu6.3), the following worked fine: $ export PS_FORMAT=thcount $ ps THCNT - 1 - 1 + 1 + 1 In Ubuntu 14.04.1 LTS (procps 1:3.3.9-1ubuntu2), it does not work anymore: $ export PS_FORMAT=thcount $ ps warning: $PS_FORMAT ignored. (unknown user-defined format specifier "thcount") - PID TTY TIME CMD - 6593 pts/100:00:00 ps + PID TTY TIME CMD + 6593 pts/100:00:00 ps 16633 pts/100:00:00 bash Other PS_FORMAT specifiers still work fine (I have tried many, but not all). In real-life usage, a more complex PS_FORMAT would of course be used, such as PS_FORMAT=pid,s,thcount,nice,euser,egroup,etime,cputime,%mem,rssize:6,size:7,vsize:7,command Workaround: use nlwp instead of thcount (they are alias to the same data, and nlwp works fine in both versions). ** Also affects: procps (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: procps (Ubuntu) Status: Confirmed => Fix Released ** Changed in: procps (Ubuntu Xenial) Status: New => In Progress ** Changed in: procps (Ubuntu Xenial) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Summary changed: - PS_FORMAT=thcount does not work anymore + ps doesn't support "thcount" format specifier on Xenial -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1410558 Title: ps doesn't support "thcount" format specifier on Xenial Status in procps package in Ubuntu: Fix Released Status in procps source package in Xenial: In Progress Bug description: [Impact] ps -o thcount doesn't print out an error (error: unknown user-defined format specifier "thcount") [Description] The Xenial version of procps has a bug in the thcount format specifier. ps doesn't recognize it, and complains about an unknown user-defined format. This is due to the format specifier table in ps/output.c, which is queried with a binary search. Since the "thcount" entry appears out of order in Xenial, it can't be looked up and the program fails with the "unknown user-defined format specifier" error. This has been fixed upstream by the commit below: - Fix for Bug:1174313 (3a52dfa34027) $ git describe --contains 3a52dfa34027 v3.3.12~58^2 $ rmadison procps procps | 2:3.3.10-4ubuntu2 | xenial | source, ... procps | 2:3.3.10-4ubuntu2.4 | xenial-security | source, ... procps | 2:3.3.10-4ubuntu2.4 | xenial-updates | source, ... < procps | 2:3.3.12-3ubuntu1 | bionic | source, ... procps | 2:3.3.12-3ubuntu1.1 | bionic-security | source
[Group.of.nepali.translators] [Bug 1852432] Re: i40e: Setting VF MAC address causes General Protection Fault
** No longer affects: linux (Ubuntu Xenial) ** Description changed: [Impact] - * Creating SR-IOV enabled VMs in Openstack can sometimes trigger the GPF and leave system unusable + * Creating SR-IOV enabled VMs in Openstack can sometimes trigger the GPF and leave system unusable [Test Case] - * Continuously spin up VFs and set MAC address with e.g. ifconfig + * Continuously spin up VFs and set MAC address with e.g. ifconfig [Fix] - * The fix updates the VSI pointer passed down to i40e_set_vf_mac function() if the adapter is still in reset, preventing the GPF. + * The fix updates the VSI pointer passed down to i40e_set_vf_mac function() if the adapter is still in reset, preventing the GPF. [Regression Potential] - * Regression potential should be low, as we're now updating the VSI using the ID stored in the VF pointer - * Regressions could arise from issues in VF creation or reset, as that would corrupt the new VSI pointer - * Patch was validated and tested in a production environment - - [Other] - * Fix was introduced in v5.4-rc1, so all previous kernels are affected + * Regression potential should be low, as we're now updating the VSI using the ID stored in the VF pointer + * Regressions could arise from issues in VF creation or reset, as that would corrupt the new VSI pointer + * Patch was validated and tested in a production environment -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1852432 Title: i40e: Setting VF MAC address causes General Protection Fault Status in linux package in Ubuntu: Confirmed Status in linux source package in Bionic: Confirmed Status in linux source package in Disco: Confirmed Status in linux source package in Eoan: Confirmed Status in linux source package in Focal: Confirmed Bug description: [Impact] * Creating SR-IOV enabled VMs in Openstack can sometimes trigger the GPF and leave system unusable [Test Case] * Continuously spin up VFs and set MAC address with e.g. ifconfig [Fix] * The fix updates the VSI pointer passed down to i40e_set_vf_mac function() if the adapter is still in reset, preventing the GPF. [Regression Potential] * Regression potential should be low, as we're now updating the VSI using the ID stored in the VF pointer * Regressions could arise from issues in VF creation or reset, as that would corrupt the new VSI pointer * Patch was validated and tested in a production environment To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1852432/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1852432] [NEW] i40e: Setting VF MAC address causes General Protection Fault
Public bug reported: [Impact] * Creating SR-IOV enabled VMs in Openstack can sometimes trigger the GPF and leave system unusable [Test Case] * Continuously spin up VFs and set MAC address with e.g. ifconfig [Fix] * The fix updates the VSI pointer passed down to i40e_set_vf_mac function() if the adapter is still in reset, preventing the GPF. [Regression Potential] * Regression potential should be low, as we're now updating the VSI using the ID stored in the VF pointer * Regressions could arise from issues in VF creation or reset, as that would corrupt the new VSI pointer * Patch was validated and tested in a production environment [Other] * Fix was introduced in v5.4-rc1, so all previous kernels are affected ** Affects: linux (Ubuntu) Importance: High Assignee: Heitor Alves de Siqueira (halves) Status: Confirmed ** Affects: linux (Ubuntu Xenial) Importance: High Assignee: Heitor Alves de Siqueira (halves) Status: Confirmed ** Affects: linux (Ubuntu Bionic) Importance: High Assignee: Heitor Alves de Siqueira (halves) Status: Confirmed ** Affects: linux (Ubuntu Disco) Importance: High Assignee: Heitor Alves de Siqueira (halves) Status: Confirmed ** Affects: linux (Ubuntu Eoan) Importance: High Assignee: Heitor Alves de Siqueira (halves) Status: Confirmed ** Affects: linux (Ubuntu Focal) Importance: High Assignee: Heitor Alves de Siqueira (halves) Status: Confirmed ** Tags: sts ** Description changed: [Impact] - * Creating SR-IOV enabled VMs in Openstack can sometimes trigger the GPF and -leave system unusable + * Creating SR-IOV enabled VMs in Openstack can sometimes trigger the GPF and leave system unusable [Test Case] * Continuously spin up VFs and set MAC address with e.g. ifconfig [Fix] - * The fix updates the VSI pointer passed down to i40e_set_vf_mac function() if -the adapter is still in reset, preventing the GPF. + * The fix updates the VSI pointer passed down to i40e_set_vf_mac function() if the adapter is still in reset, preventing the GPF. [Regression Potential] - * Regression potential should be low, as we're now updating the VSI using the -ID stored in the VF pointer - * Regressions could arise from issues in VF creation or reset, as that would -corrupt the new VSI pointer - * Patch was validated and tested in a production environment with Openstack + * Regression potential should be low, as we're now updating the VSI using the ID stored in the VF pointer + * Regressions could arise from issues in VF creation or reset, as that would corrupt the new VSI pointer + * Patch was validated and tested in a production environment [Other] * Fix was introduced in v5.4-rc1, so all previous kernels are affected ** Also affects: linux (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Focal) Importance: High Assignee: Heitor Alves de Siqueira (halves) Status: Confirmed ** Also affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Disco) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Eoan) Status: New => Confirmed ** Changed in: linux (Ubuntu Disco) Status: New => Confirmed ** Changed in: linux (Ubuntu Bionic) Status: New => Confirmed ** Changed in: linux (Ubuntu Xenial) Status: New => Confirmed ** Changed in: linux (Ubuntu Eoan) Importance: Undecided => High ** Changed in: linux (Ubuntu Disco) Importance: Undecided => High ** Changed in: linux (Ubuntu Xenial) Importance: Undecided => High ** Changed in: linux (Ubuntu Bionic) Importance: Undecided => High ** Changed in: linux (Ubuntu Eoan) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: linux (Ubuntu Disco) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: linux (Ubuntu Bionic) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: linux (Ubuntu Xenial) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1852432 Title: i40e: Setting VF MAC address causes General Protection Fault Status in linux package in Ubuntu: Confirmed Status in linux source package in Xenial: Confirmed Status in linux source package in Bionic: Confirmed Status in linux source package in Disco: Confirmed Status in linux source package in Eoan: Confirmed Status in linux source package in Focal: Confirmed Bug description: [Impact] * Creating SR-IOV enabled VMs in Ope
[Group.of.nepali.translators] [Bug 1846787] [NEW] systemd-logind leaves leftover sessions and scope files
Public bug reported:
[Impact]
Scope file leakage can cause SSH delays and reduce performance in systemd
[Description]
The current systemd-logind version present in Xenial can leave abandoned SSH
sessions and scope files in cases where the host sees a lot of concurrent SSH
connections. These leftover sessions can slow down systemd performance
greatly, and can have an impact on sshd handling a great number of concurrent
connections.
To fix this issue, patches are needed in both dbus and systemd. These improve
the
performance of the communication between dbus and systemd, so that they can
handle a better volume of events (e.g. SSH logins). All of those patches are
already present from Bionic onwards, so we only need those fixes for Xenial.
== Systemd ==
Upstream patches:
- core: use an AF_UNIX/SOCK_DGRAM socket for cgroup agent notification
(d8fdc62037b5)
- tree-wide: introduce new SOCKADDR_UN_LEN() macro, and use it everywhere
(fc2fffe7706e)
- journald: stack allocation cannot fail (23be5709e10b)
$ git describe --contains d8fdc62037b5 fc2fffe7706e 23be5709e10b
v230~71^2~2
v230~71^2~1
v230~71^2
$ rmadison systemd
systemd | 229-4ubuntu4 | xenial | source, ...
systemd | 229-4ubuntu21.21 | xenial-security | source, ...
systemd | 229-4ubuntu21.22 | xenial-updates | source, ... <
systemd | 237-3ubuntu10| bionic | source, ...
systemd | 237-3ubuntu10.29 | bionic-security | source, ...
systemd | 237-3ubuntu10.29 | bionic-updates | source, ...
systemd | 237-3ubuntu10.31 | bionic-proposed | source, ...
== DBus ==
Upstream patches:
- Only read one message at a time if there are fds pending (892f084eeda0)
- bus: Fix timeout restarts (529600397bca)
- DBusMainLoop: ensure all required timeouts are restarted (446b0d9ac75a)
$ git describe --contains 892f084eeda0 529600397bca 446b0d9ac75a
dbus-1.11.10~44
dbus-1.11.10~45
dbus-1.11.16~2
$ rmadison dbus
dbus | 1.10.6-1ubuntu3| xenial | source, ...
dbus | 1.10.6-1ubuntu3.4 | xenial-security | source, ...
dbus | 1.10.6-1ubuntu3.4 | xenial-updates | source, ... <
dbus | 1.12.2-1ubuntu1| bionic | source, ...
dbus | 1.12.2-1ubuntu1.1 | bionic-security | source, ...
dbus | 1.12.2-1ubuntu1.1 | bionic-updates | source, ...
[Test Case]
1) Simulate a lot of concurrent SSH connections with e.g. a for loop:
multipass@xenial-logind:~$ for i in {1..1000}; do sleep 0.1; ssh localhost
sleep 1 > /dev/null & done
2) Check for leaked sessions in /run/systemd/system/:
multipass@xenial-logind:~$ ls -ld /run/systemd/system/session-*.scope*
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-103.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-104.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-105.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-106.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-110.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-111.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-112.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-113.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-114.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-115.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-116.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-117.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-118.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-119.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-120.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-121.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-122.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-123.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-126.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-131.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-134.scope.d
...
[Regression Potential]
The regression potential is low, as these patches have seen extensive testing
both upstream and in more recent releases of Ubuntu. Nonetheless, these new
packages will be rigorously tested through autopkgtest to avoid any possible
Xenial-specific regressions.
** Affects: dbus (Ubuntu)
Importance: Undecided
Status: Fix Released
** Affects: systemd (Ubuntu)
Importance: Undecided
Status: Fix Released
** Affects: dbus (Ubuntu Xenial)
Importance: Undecided
Assignee: Heitor Alves de Siqueira (halves)
Status: New
** Affects: systemd (Ubuntu Xenial)
Importance: Undecided
Assignee: Heitor Alves de Siqueira (halves)
Status: New
[Group.of.nepali.translators] [Bug 1818527] Re: Stub resolver cache is corrupted
** Description changed: + [Impact] + systemd-resolved fails to resolve A records + + [Description] + When systemd-resolve caches a non-existent CNAME record for a specific domain, further attempts at resolving A records for that same domain fail. This has been fixed upstream in v240. + + Upstream commit: https://github.com/systemd/systemd/commit/3740146a4cbd + + $ git describe --contains 3740146a4cbd + v240~839 + + $ rmadison systemd --arch amd64 + systemd | 229-4ubuntu4 | xenial | source, ... + systemd | 229-4ubuntu21.21 | xenial-security | source, ... + systemd | 229-4ubuntu21.21 | xenial-updates | source, ... + systemd | 237-3ubuntu10| bionic | source, ... + systemd | 237-3ubuntu10.19 | bionic-security | source, ... + systemd | 237-3ubuntu10.21 | bionic-updates | source, ... + systemd | 237-3ubuntu10.22 | bionic-proposed | source, ... + systemd | 239-7ubuntu10| cosmic | source, ... + systemd | 239-7ubuntu10.12 | cosmic-security | source, ... + systemd | 239-7ubuntu10.13 | cosmic-updates | source, ... + systemd | 239-7ubuntu10.14 | cosmic-proposed | source, ... + systemd | 240-6ubuntu5 | disco | source, ... + systemd | 240-6ubuntu5.1 | disco-proposed | source, ... + systemd | 240-6ubuntu9 | eoan| source, ... + + Despite the package versions above, only Bionic is affected. Cosmic + already includes a backported fix, and Xenial doesn't seem affected due + to resolvconf handling DNS resolution. + + [Test Case] + Flush resolved's caches and try resolving a non-existent CNAME record. Further resolution attempts for the corresponding A record will fail: + + $ systemd-resolve --flush-caches + $ dig github.com CNAME + $ dig github.com A + + [Regression Potential] + The regression potential for this fix should be very low, as it's a direct cherry-pick from upstream systemd. It has seen extensive testing in both upstream and other Ubuntu releases, and was verified for Bionic through autopkgtests. + + + + [Original Description] + It seems that when systemd-resolve cache an non-existent CNAME record for a domain, any attempt to resolve A record for the same domain fail. systemd version the issue has been seen with Installed: 237-3ubuntu10.13 Used distribution Distributor ID: Ubuntu Description: Ubuntu 18.04.2 LTS Release: 18.04 Codename: bionic Expected behaviour you didn't see Return A record for a domain when it exists. Unexpected behaviour you saw Resolution failed. Steps to reproduce the problem Whait for 1 minutes (github.com TTL for A record) Try to resolv github.com CNAME record dig CNAME github.com This will return an empty result. Then try to resolve github.com A record dig A github.com. This will now return empty result unless you restart systemd-resolved or wait for cache expiration. At the same time using another DNS will resolve correctly dig A github.com @8.8.8.8. Exemple : Wait for 1 minutes to let cache expire, then run dig CNAME github.com dig A github.com # no result dig A github.com @8.8.8.8 # ;; ANSWER SECTION: # github.com. 59 IN A 192.30.253.113 # github.com. 59 IN A 192.30.253.112 PS: Don't forget to restart systemd-resolve, before trying to post an answer. This bug was first reported in github https://github.com/systemd/systemd/issues/11789 but systemd version in ubuntu is too old. ** Changed in: systemd (Ubuntu Xenial) Status: New => Invalid ** Changed in: systemd (Ubuntu Xenial) Importance: Medium => Undecided ** Changed in: systemd (Ubuntu Xenial) Assignee: Heitor Alves de Siqueira (halves) => (unassigned) ** Changed in: systemd (Ubuntu Bionic) Status: Confirmed => In Progress ** Patch added: "lp1818527-bionic.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1818527/+attachment/5268921/+files/lp1818527-bionic.debdiff ** Tags added: sts sts-sponsor -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1818527 Title: Stub resolver cache is corrupted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Invalid Status in systemd source package in Bionic: In Progress Bug description: [Impact] systemd-resolved fails to resolve A records [Description] When systemd-resolve caches a non-existent CNAME record for a specific domain, further attempts at resolving A records for that same domain fail. This has been fixed upstream in v240. Upstream commit: https://github.com/systemd/systemd/commit/3740146a4cbd $ git describe --contains 3740146a4cbd v240~839 $ rmadison systemd --arch amd64
[Group.of.nepali.translators] [Bug 1818527] Re: Stub resolver cache is corrupted
** Also affects: systemd (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu Bionic) Status: New => Confirmed ** Changed in: systemd (Ubuntu) Status: Confirmed => Fix Released ** Changed in: systemd (Ubuntu Bionic) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: systemd (Ubuntu Xenial) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: systemd (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: systemd (Ubuntu Xenial) Importance: Undecided => Medium -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1818527 Title: Stub resolver cache is corrupted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: New Status in systemd source package in Bionic: Confirmed Bug description: It seems that when systemd-resolve cache an non-existent CNAME record for a domain, any attempt to resolve A record for the same domain fail. systemd version the issue has been seen with Installed: 237-3ubuntu10.13 Used distribution Distributor ID: Ubuntu Description: Ubuntu 18.04.2 LTS Release: 18.04 Codename: bionic Expected behaviour you didn't see Return A record for a domain when it exists. Unexpected behaviour you saw Resolution failed. Steps to reproduce the problem Whait for 1 minutes (github.com TTL for A record) Try to resolv github.com CNAME record dig CNAME github.com This will return an empty result. Then try to resolve github.com A record dig A github.com. This will now return empty result unless you restart systemd-resolved or wait for cache expiration. At the same time using another DNS will resolve correctly dig A github.com @8.8.8.8. Exemple : Wait for 1 minutes to let cache expire, then run dig CNAME github.com dig A github.com # no result dig A github.com @8.8.8.8 # ;; ANSWER SECTION: # github.com. 59 IN A 192.30.253.113 # github.com. 59 IN A 192.30.253.112 PS: Don't forget to restart systemd-resolve, before trying to post an answer. This bug was first reported in github https://github.com/systemd/systemd/issues/11789 but systemd version in ubuntu is too old. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1818527/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1822270] Re: Debconf readline frontend does not show options
** Bug watch added: Debian Bug tracker #928182 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928182 ** Also affects: debconf (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928182 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1822270 Title: Debconf readline frontend does not show options Status in debconf package in Ubuntu: Confirmed Status in debconf source package in Xenial: Confirmed Status in debconf source package in Bionic: Confirmed Status in debconf source package in Cosmic: Confirmed Status in debconf source package in Disco: Confirmed Status in debconf source package in Eoan: Confirmed Status in debconf package in Debian: Unknown Bug description: [Impact] debconf prompts the user for input before displaying options [Description] When upgrading packages with apt or dpkg, debconf scripts are ran through 'run-parts' with the '--report' flag. This causes script output to be handled through pipes set up by run-parts, and buffers output from maintainer scripts nicely for formatting. If debconf makes use of the readline frontend, any prompts will bypass the run-parts buffers and be displayed directly to /dev/tty. This generally causes the prompt to be displayed before the user gets any of the available options for it, and printing will block until the user inputs a valid option. [Test Case] 1) Deploy a VM through e.g. uvt-kvm $ uvt-kvm create disco release=disco 2) Remove the whiptail package to force the readline frontend in debconf root@disco:~# apt remove --purge whiptail -y 3) Install grub-legacy-ec2 and prepare /boot/grub/menu.lst for an upgrade through run-parts root@disco:~# apt update && apt install -y grub-legacy-ec2 root@disco:~# rm -f /boot/grub/menu.lst* root@disco:~# touch -d "4 years ago" /boot/grub/menu.lst 4) Invoke run-parts as in a kernel upgrade (kernel version doesn't matter, we just need it to think menu.lst needs an upgrade) root@disco:~# run-parts --exit-on-error --arg=5.0.0 /etc/kernel/postinst.d --report ... /etc/kernel/postinst.d/x-grub-legacy-ec2: debconf: unable to initialize frontend: Dialog debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.) debconf: falling back to frontend: Readline Searching for GRUB installation directory ... found: /boot/grub Searching for default file ... found: /boot/grub/default Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst Searching for splash image ... none found, skipping ... What would you like to do about menu.lst? The "What would you like to do about menu.lst?" prompt will block until the user enter a valid option, even though it's being displayed before the available options. [Regression Potential] We could hit regressions if changing debconf's printing to /dev/tty is expected by other programs. The changes are needed only in the readline frontend, so that would minimize impact of any possible regressions. The fixes will be thoroughly tested with autopkgtest and use-case scenarios. # # # # [Original Description] When upgrading the kernel on a recent Bionic minimal image, the user is prompted to resolve a conflict in the file /boot/grub/menu.lst. The minimal images do not have dialog/whiptail installed, so debconf falls back to using the readline frontend. The user sees the prompt: "What would you like to do about menu.lst?" but is not presented with the list of options to choose from. If a valid option is typed in, debconf will continue processing correctly and the list of options appears on the screen. See also https://pastebin.ubuntu.com/p/8xvSn88SKG/ STEPS TO REPRODUCE: Launch the minimal Bionic image with serial 20190212 http://cloud- images.ubuntu.com/minimal/releases/bionic/release-20190212/ubuntu-18.04 -minimal-cloudimg-amd64.img for example via multipass and run `apt-get update` and `apt-get dist- upgrade`. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1822270/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1825250] Re: ethmonitor does not list interfaces without assigned IP address
** Also affects: resource-agents (Ubuntu Eoan) Importance: Medium Assignee: Heitor Alves de Siqueira (halves) Status: Confirmed -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1825250 Title: ethmonitor does not list interfaces without assigned IP address Status in resource-agents package in Ubuntu: Confirmed Status in resource-agents source package in Xenial: Confirmed Status in resource-agents source package in Bionic: Confirmed Status in resource-agents source package in Cosmic: Confirmed Status in resource-agents source package in Disco: Confirmed Status in resource-agents source package in Eoan: Confirmed Status in resource-agents package in Debian: New Bug description: [Impact] Some network interfaces will not be monitored by ethmonitor [Description] The is_interface() function in ethmonitor tries to match an interface to a list obtained from the 'ip' tool. It lists interfaces using the 'inet' family, which omits interfaces that don't have an IP address assigned. If the interface that we're looking for is e.g. a VLAN bridge that does not have an IP address, it won't show up in the listing and is_interface() will return false. ethmonitor will miss that interface, and it won't be available for monitoring. Upstream commits: - https://github.com/ClusterLabs/resource-agents/commit/40d05029ce0b - https://github.com/ClusterLabs/resource-agents/commit/c0ac191c73f1 [Test Case] 1) Ensure there's a network interface without an assigned IP address. For example, virbr0-nic will be created automatically by uvt-kvm: # ip addr show dev virbr0-nic 11: virbr0-nic: mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000 link/ether 52:54:00:e9:5e:af brd ff:ff:ff:ff:ff:ff 2) Install pcs+arping and create a new ethmonitor resource with the target interface: # sudo apt update && sudo apt install pcs arping -y # pcs resource create p_nic ocf:heartbeat:ethmonitor interface=virbr0-nic op monitor timeout="10s" 3) Debug-start ethmonitor resource and check for "Interface does not exist messages" # pcs resource debug-start p_nic Operation start for p_nic (ocf:heartbeat:ethmonitor) returned: 'ok' (0) > stderr: WARNING: Interface virbr0-nic does not exist > stderr: NOTICE: link_status: DOWN [Regression Potential] The regression potential is low, since we are relaxing the monitoring conditions for interfaces without an assigned IP address. The patches have been tested against Travis-CI before being merged upstream, and will be tested against autopkgtest for each target distro. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resource-agents/+bug/1825250/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1825250] Re: ethmonitor does not list interfaces without assigned IP address
** Also affects: resource-agents (Ubuntu Disco) Importance: Undecided Status: New ** Changed in: resource-agents (Ubuntu Disco) Status: New => Confirmed ** Changed in: resource-agents (Ubuntu Disco) Importance: Undecided => Critical ** Changed in: resource-agents (Ubuntu Disco) Importance: Critical => Medium ** Changed in: resource-agents (Ubuntu Disco) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Patch added: "lp1825250-eoan.debdiff" https://bugs.launchpad.net/ubuntu/+source/resource-agents/+bug/1825250/+attachment/5258311/+files/lp1825250-eoan.debdiff ** Tags added: sts-sponsor -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1825250 Title: ethmonitor does not list interfaces without assigned IP address Status in resource-agents package in Ubuntu: Confirmed Status in resource-agents source package in Xenial: Confirmed Status in resource-agents source package in Bionic: Confirmed Status in resource-agents source package in Cosmic: Confirmed Status in resource-agents source package in Disco: Confirmed Status in resource-agents package in Debian: New Bug description: [Impact] Some network interfaces will not be monitored by ethmonitor [Description] The is_interface() function in ethmonitor tries to match an interface to a list obtained from the 'ip' tool. It lists interfaces using the 'inet' family, which omits interfaces that don't have an IP address assigned. If the interface that we're looking for is e.g. a VLAN bridge that does not have an IP address, it won't show up in the listing and is_interface() will return false. ethmonitor will miss that interface, and it won't be available for monitoring. Upstream commits: - https://github.com/ClusterLabs/resource-agents/commit/40d05029ce0b - https://github.com/ClusterLabs/resource-agents/commit/c0ac191c73f1 [Test Case] 1) Ensure there's a network interface without an assigned IP address. For example, virbr0-nic will be created automatically by uvt-kvm: # ip addr show dev virbr0-nic 11: virbr0-nic: mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000 link/ether 52:54:00:e9:5e:af brd ff:ff:ff:ff:ff:ff 2) Install pcs+arping and create a new ethmonitor resource with the target interface: # sudo apt update && sudo apt install pcs arping -y # pcs resource create p_nic ocf:heartbeat:ethmonitor interface=virbr0-nic op monitor timeout="10s" 3) Debug-start ethmonitor resource and check for "Interface does not exist messages" # pcs resource debug-start p_nic Operation start for p_nic (ocf:heartbeat:ethmonitor) returned: 'ok' (0) > stderr: WARNING: Interface virbr0-nic does not exist > stderr: NOTICE: link_status: DOWN [Regression Potential] The regression potential is low, since we are relaxing the monitoring conditions for interfaces without an assigned IP address. The patches have been tested against Travis-CI before being merged upstream, and will be tested against autopkgtest for each target distro. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resource-agents/+bug/1825250/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1825250] Re: ethmonitor does not list interfaces without assigned IP address
** Bug watch added: Debian Bug tracker #927311 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927311 ** Also affects: resource-agents (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927311 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1825250 Title: ethmonitor does not list interfaces without assigned IP address Status in resource-agents package in Ubuntu: Confirmed Status in resource-agents source package in Xenial: Confirmed Status in resource-agents source package in Bionic: Confirmed Status in resource-agents source package in Cosmic: Confirmed Status in resource-agents package in Debian: Unknown Bug description: [Impact] Some network interfaces will not be monitored by ethmonitor [Description] The is_interface() function in ethmonitor tries to match an interface to a list obtained from the 'ip' tool. It lists interfaces using the 'inet' family, which omits interfaces that don't have an IP address assigned. If the interface that we're looking for is e.g. a VLAN bridge that does not have an IP address, it won't show up in the listing and is_interface() will return false. ethmonitor will miss that interface, and it won't be available for monitoring. Upstream commits: - https://github.com/ClusterLabs/resource-agents/commit/40d05029ce0b - https://github.com/ClusterLabs/resource-agents/commit/c0ac191c73f1 [Test Case] 1) Ensure there's a network interface without an assigned IP address. For example, virbr0-nic will be created automatically by uvt-kvm: # ip addr show dev virbr0-nic 11: virbr0-nic: mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000 link/ether 52:54:00:e9:5e:af brd ff:ff:ff:ff:ff:ff 2) Install pcs+arping and create a new ethmonitor resource with the target interface: # sudo apt update && sudo apt install pcs arping -y # pcs resource create p_nic ocf:heartbeat:ethmonitor interface=virbr0-nic op monitor timeout="10s" 3) Debug-start ethmonitor resource and check for "Interface does not exist messages" # pcs resource debug-start p_nic Operation start for p_nic (ocf:heartbeat:ethmonitor) returned: 'ok' (0) > stderr: WARNING: Interface virbr0-nic does not exist > stderr: NOTICE: link_status: DOWN [Regression Potential] The regression potential is low, since we are relaxing the monitoring conditions for interfaces without an assigned IP address. The patches have been tested against Travis-CI before being merged upstream, and will be tested against autopkgtest for each target distro. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/resource-agents/+bug/1825250/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1825250] [NEW] ethmonitor does not list interfaces without assigned IP address
Public bug reported:
[Impact]
Some network interfaces will not be monitored by ethmonitor
[Description]
The is_interface() function in ethmonitor tries to match an interface to a list
obtained from the 'ip' tool. It lists interfaces using the 'inet' family, which
omits interfaces that don't have an IP address assigned.
If the interface that we're looking for is e.g. a VLAN bridge that does
not have an IP address, it won't show up in the listing and
is_interface() will return false. ethmonitor will miss that interface,
and it won't be available for monitoring.
Upstream commits:
- https://github.com/ClusterLabs/resource-agents/commit/40d05029ce0b
- https://github.com/ClusterLabs/resource-agents/commit/c0ac191c73f1
[Test Case]
1) Ensure there's a network interface without an assigned IP address. For
example, virbr0-nic will be created automatically by uvt-kvm:
# ip addr show dev virbr0-nic
11: virbr0-nic: mtu 1500 qdisc fq_codel
master virbr0 state DOWN group default qlen 1000
link/ether 52:54:00:e9:5e:af brd ff:ff:ff:ff:ff:ff
2) Install pcs+arping and create a new ethmonitor resource with the target
interface:
# sudo apt update && sudo apt install pcs arping -y
# pcs resource create p_nic ocf:heartbeat:ethmonitor interface=virbr0-nic op
monitor timeout="10s"
3) Debug-start ethmonitor resource and check for "Interface does not exist
messages"
# pcs resource debug-start p_nic
Operation start for p_nic (ocf:heartbeat:ethmonitor) returned: 'ok' (0)
> stderr: WARNING: Interface virbr0-nic does not exist
> stderr: NOTICE: link_status: DOWN
[Regression Potential]
The regression potential is low, since we are relaxing the monitoring
conditions for interfaces without an assigned IP address. The patches have been
tested against Travis-CI before being merged upstream, and will be tested
against autopkgtest for each target distro.
** Affects: resource-agents (Ubuntu)
Importance: Medium
Assignee: Heitor Alves de Siqueira (halves)
Status: Confirmed
** Affects: resource-agents (Ubuntu Xenial)
Importance: Medium
Assignee: Heitor Alves de Siqueira (halves)
Status: Confirmed
** Affects: resource-agents (Ubuntu Bionic)
Importance: Medium
Assignee: Heitor Alves de Siqueira (halves)
Status: Confirmed
** Affects: resource-agents (Ubuntu Cosmic)
Importance: Medium
Assignee: Heitor Alves de Siqueira (halves)
Status: Confirmed
** Affects: resource-agents (Debian)
Importance: Unknown
Status: Unknown
** Tags: sts
** Also affects: resource-agents (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: resource-agents (Ubuntu Cosmic)
Importance: Undecided
Status: New
** Also affects: resource-agents (Ubuntu Bionic)
Importance: Undecided
Status: New
** Changed in: resource-agents (Ubuntu Xenial)
Status: New => Confirmed
** Changed in: resource-agents (Ubuntu Bionic)
Status: New => Confirmed
** Changed in: resource-agents (Ubuntu Cosmic)
Status: New => Confirmed
** Changed in: resource-agents (Ubuntu Xenial)
Importance: Undecided => Medium
** Changed in: resource-agents (Ubuntu Bionic)
Importance: Undecided => Medium
** Changed in: resource-agents (Ubuntu Cosmic)
Importance: Undecided => Medium
** Changed in: resource-agents (Ubuntu Xenial)
Assignee: (unassigned) => Heitor Alves de Siqueira (halves)
** Changed in: resource-agents (Ubuntu Cosmic)
Assignee: (unassigned) => Heitor Alves de Siqueira (halves)
** Changed in: resource-agents (Ubuntu Bionic)
Assignee: (unassigned) => Heitor Alves de Siqueira (halves)
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1825250
Title:
ethmonitor does not list interfaces without assigned IP address
Status in resource-agents package in Ubuntu:
Confirmed
Status in resource-agents source package in Xenial:
Confirmed
Status in resource-agents source package in Bionic:
Confirmed
Status in resource-agents source package in Cosmic:
Confirmed
Status in resource-agents package in Debian:
Unknown
Bug description:
[Impact]
Some network interfaces will not be monitored by ethmonitor
[Description]
The is_interface() function in ethmonitor tries to match an interface to a
list obtained from the 'ip' tool. It lists interfaces using the 'inet' family,
which omits interfaces that don't have an IP address assigned.
If the interface that we're looking for is e.g. a VLAN bridge that
does not have an IP address, it won't show up in the listing and
is_interface() will return false. ethmonitor will miss that interface,
and it won't be available for monitoring.
Upstream commits:
- https://github.com/ClusterLabs/resource-agents/commit/40d05029ce
