[Touch-packages] [Bug 2061825] Re: [SRU] ucf fails to work for local diversions on Jammy
Thanks for the confirmation on Focal, @pponnuvel! I've tested your debdiff, and it seems to work correctly. Patch is also a straightforward cherry-pick from Debian. Sponsored for Jammy, with the update-maintainer changes. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ucf in Ubuntu. https://bugs.launchpad.net/bugs/2061825 Title: [SRU] ucf fails to work for local diversions on Jammy Status in ucf package in Ubuntu: Fix Released Status in ucf source package in Jammy: In Progress Bug description: [ Impact ] When a dpkg-diversion is used to setup a package diversion and ucf for managing the configuration files for chrony package, the postinst script of ucf fails when installing chrony. This issue isn't specific to chrony but can happen for any package whose config files are managed by ucf. This affects users on Jammy who use ucf. Newer versions of ucf have this bug fixed already. [ Test Plan ] 1. Create a Jammy container or VM 2. Setup a diversion for chrony.conf: dpkg-divert --package chrony --add --rename --divert /etc/chrony/chrony.conf.custom /etc/chrony/chrony.conf 3. Install chrony: apt install chrony -y 4. Notice the postinst script fail with syntax errors such as: ``` Preparing to unpack .../chrony_4.2-2ubuntu2_amd64.deb ... Unpacking chrony (4.2-2ubuntu2) ... Setting up chrony (4.2-2ubuntu2) ... /usr/bin/ucf: 444: [: missing ] grep: ]: No such file or directory /usr/bin/ucf: 444: [: missing ] grep: ]: No such file or directory ``` 5. Install the package with the fix from the PPA: https://launchpad.net/~pponnuvel/+archive/ubuntu/ucf-jammy (to be replaced with the package from the -proposed pocket) 6. Repeat the same from steps 1 to 4 and notice no failures at step4. [ Where problems could occur ] Can further introduce similar bugs if the patch contains similar syntax errors. Consequently local diversion may not take effect for packages using ucf to manage configuration files. [ Other Info ] Upstream bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979354 It's been fixed in version ucf/3.0043+nmu1. Lunar/Mantic/Noble all have the ucf version with this patch. Affects Jammy only and thus backported to only Jammy. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ucf/+bug/2061825/+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 2036761] Re: [mantic] ppa-purge no longer purges what add-apt-repository adds
Marking as verified according to comment #21 ** Tags removed: verification-needed verification-needed-mantic ** Tags added: verification-done verification-done-mantic ** Changed in: software-properties (Ubuntu) Status: Confirmed => Invalid ** Changed in: software-properties (Ubuntu Mantic) Status: Confirmed => Invalid ** Changed in: software-properties (Ubuntu Noble) Status: Confirmed => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/2036761 Title: [mantic] ppa-purge no longer purges what add-apt-repository adds Status in ppa-purge package in Ubuntu: Fix Released Status in software-properties package in Ubuntu: Invalid Status in ppa-purge source package in Mantic: Fix Committed Status in software-properties source package in Mantic: Invalid Status in ppa-purge source package in Noble: Fix Released Status in software-properties source package in Noble: Invalid Bug description: Thank you @jbicha for the original bug report! [ Impact ] Currently ppa-purge fails to purge packages on distribution using the deb822 source format. Currently mantic and noble make use of this format and are affected by this issue. When running ppa-purge to remove a custom PPA, ppa-purge fails to disable the custom PPA since it cannot disable deb822 sources and leads to apt still querying the ppa when running: $ apt update In older versions of ubuntu, PPAs used the ".list" format which could be disabled by simply commenting out the "deb" line with a "#". This was the method that ppa-purge used to disable PPAs. This new patch allows ppa-purge to detect and disable deb822 source files by adding an "Enabled: no" field in each component section of the deb822 file. It also removes any line that starts with "Enabled:" to make sure the resulting file is clean. [ Test Plan ] The changes were tested on both mantic and noble in a lxc container using the oibaf mesa PPA (https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers) as the test PPA. The following steps were recorded in a noble lxc container. - First make sure that mesa-utils is installed in your environment: $ sudo apt update && sudo apt install mesa-utils - Add the oibaf PPA to your system using the following command: $ sudo add-apt-repository ppa:oibaf/graphics-drivers - Make sure that the mesa-utils packages were upgraded after adding the PPA: $ sudo apt update && sudo apt upgrade $ dpkg - l | grep mesa - output should be similar to the following: ii libegl-mesa0:amd64 24.1~git2402280600.41722c~oibaf~n amd64free implementation of the EGL API -- Mesa vendor library ii libgl1-mesa-dri:amd64 24.1~git2402280600.41722c~oibaf~n amd64free implementation of the OpenGL API -- DRI modules ii libglapi-mesa:amd64 24.1~git2402280600.41722c~oibaf~n amd64free implementation of the GL API -- shared library ii libglx-mesa0:amd64 24.1~git2402280600.41722c~oibaf~n amd64free implementation of the OpenGL API -- GLX vendor library ii mesa-utils 9.0.0-2 amd64Miscellaneous Mesa utilities -- symlinks ii mesa-utils-bin:amd649.0.0-2 amd64Miscellaneous Mesa utilities -- native applications ii mesa-vulkan-drivers:amd64 24.1~git2402280600.41722c~oibaf~n amd64Mesa Vulkan graphics drivers - Install and run ppa-purge: $ sudo apt install ppa-purge $ sudo ppa-purge ppa:oibaf/graphics-drivers - ppa-purge will report at the end that none of the oibaf packages need to be downgraded/removed: libglapi-mesa is already the newest version (24.1~git2402280600.41722c~oibaf~n). libglapi-mesa set to manually installed. libglx-mesa0 is already the newest version (24.1~git2402280600.41722c~oibaf~n). libglx-mesa0 set to manually installed. mesa-vulkan-drivers is already the newest version (24.1~git2402280600.41722c~oibaf~n). mesa-vulkan-drivers set to manually installed. Selected version '2.4.120+git2402271331.1b4e04~oibaf~n' (Updated Open Graphics Drivers - since 2011!:24.04/noble [amd64]) for 'libdrm-amdgpu1' Selected version '2.4.120+git2402271331.1b4e04~oibaf~n' (Updated Open Graphics Drivers - since 2011!:24.04/noble [all]) for 'libdrm-common' Selected version '2.4.120+git2402271331.1b4e04~oibaf~n' (Updated Open Graphics Drivers - since 2011!:24.04/noble [amd64]) for 'libdrm-intel1' Selected version '2.4.120+git2402271331.1b4e04~oibaf~n' (Updated Open Graphics Drivers - since 2011!:24.04/noble [amd64]) for 'libdrm-nouveau2' Selected version
[Touch-packages] [Bug 2061825] Re: [SRU] ucf fails to work for local diversions on Jammy
Hi Pon, thanks for the revised debdiff! This seems to be a non-quilt package, so your approach of directly patching the ucf/ucfr scripts is correct. The only thing missing is running the update-maintainer script, as the ubuntu1 version requires having an ubuntu.com address on the maintainers field. This is something a sponsor can run easily, so don't worry about fixing it for now (but feel free to do it for future debdiffs!). Before uploading this, I'd like to check about Focal; is that release affected at all? If it is, any reason why we shouldn't patch it? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ucf in Ubuntu. https://bugs.launchpad.net/bugs/2061825 Title: [SRU] ucf fails to work for local diversions on Jammy Status in ucf package in Ubuntu: Fix Released Status in ucf source package in Jammy: In Progress Bug description: [ Impact ] When a dpkg-diversion is used to setup a package diversion and ucf for managing the configuration files for chrony package, the postinst script of ucf fails when installing chrony. This issue isn't specific to chrony but can happen for any package whose config files are managed by ucf. This affects users on Jammy who use ucf. Newer versions of ucf have this bug fixed already. [ Test Plan ] 1. Create a Jammy container or VM 2. Setup a diversion for chrony.conf: dpkg-divert --package chrony --add --rename --divert /etc/chrony/chrony.conf.custom /etc/chrony/chrony.conf 3. Install chrony: apt install chrony -y 4. Notice the postinst script fail with syntax errors such as: ``` Preparing to unpack .../chrony_4.2-2ubuntu2_amd64.deb ... Unpacking chrony (4.2-2ubuntu2) ... Setting up chrony (4.2-2ubuntu2) ... /usr/bin/ucf: 444: [: missing ] grep: ]: No such file or directory /usr/bin/ucf: 444: [: missing ] grep: ]: No such file or directory ``` 5. Install the package with the fix from the PPA: https://launchpad.net/~pponnuvel/+archive/ubuntu/ucf-jammy (to be replaced with the package from the -proposed pocket) 6. Repeat the same from steps 1 to 4 and notice no failures at step4. [ Where problems could occur ] Can further introduce similar bugs if the patch contains similar syntax errors. Consequently local diversion may not take effect for packages using ucf to manage configuration files. [ Other Info ] Upstream bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979354 It's been fixed in version ucf/3.0043+nmu1. Lunar/Mantic/Noble all have the ucf version with this patch. Affects Jammy only and thus backported to only Jammy. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ucf/+bug/2061825/+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 2038453] Re: [SRU] apt snapshot integration backport
** Changed in: ubuntu-pro/18.04 Status: Triaged => In Progress -- 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/2038453 Title: [SRU] apt snapshot integration backport Status in Ubuntu Pro: In Progress Status in Ubuntu Pro 18.04 series: In Progress Status in apt package in Ubuntu: Fix Released Status in apt source package in Bionic: Won't Fix Status in apt source package in Focal: Fix Released Status in apt source package in Jammy: Fix Released Status in apt source package in Lunar: Won't Fix Status in apt source package in Mantic: Fix Released Bug description: [Impact] The snapshot service provides users access to older states of the archive with ease of use, and enables a consistent user experience across all supported releases, as otherwise users would have to rewrite their sources.list to make use of snapshots and set up pinning; hence partners requested the feature be SRUed to older releases as well. [Test plan] The complete regression test suite in autopkgtests includes an automatic test case for this and the known limitations that have been fixed. Aside from that, it is also worthwhile to do an end-to-end test: Configure snapshot=yes for Ubuntu sources in your sources.list and 1. run apt update - it should not use snapshot 2. run apt update --snapshot 20231001T00Z, it should download the snapshot 3. run apt policy --snapshot 20231001T00Z hello, it should show hello in the snapshot 4. run apt install --snapshot 20231001T00Z hello, it should install hello from the snapshot 5. Run apt update; observe snapshot not being downloaded 6. Observe snapshots are gone from /var/lib/apt/lists again [Where problems could occur] The integration has been purposefully limited in how it works to reduce the impact it has on the APT code; hence it was possible to cherry-pick this into 22.04, 20.04, and even 18.04, with only a minor editorial change. This significantly limits the risk. This feature is only enabled for sources with snapshot=yes (.list) or Snapshot: yes (.sources) or other truthy values apt recognizes. Most users will not have such entries as they did not have an APT supporting it. This combined should ensure that users do not experience any regressions. However the feature may be lacking in some ways that we may want to address in follow up SRUs; it has not been used in the wild a lot. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-pro/+bug/2038453/+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 2036761] Re: [mantic] ppa-purge no longer purges what add-apt-repository adds
Hi Ghadi, thanks for the debdiff! I've considered trimming down the new version to 0.2.8+bzr63-0ubuntu1.1 according to [0], but ultimately think your approach is correct (otherwise it'll be hard to update ppa-purge in Jammy if we ever need to!). Tested and sponsored for Mantic. [0] https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging ** Changed in: ppa-purge (Ubuntu Mantic) Status: Triaged => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/2036761 Title: [mantic] ppa-purge no longer purges what add-apt-repository adds Status in ppa-purge package in Ubuntu: Fix Released Status in software-properties package in Ubuntu: Confirmed Status in ppa-purge source package in Mantic: In Progress Status in software-properties source package in Mantic: Confirmed Status in ppa-purge source package in Noble: Fix Released Status in software-properties source package in Noble: Confirmed Bug description: Thank you @jbicha for the original bug report! [ Impact ] Currently ppa-purge fails to purge packages on distribution using the deb822 source format. Currently mantic and noble make use of this format and are affected by this issue. When running ppa-purge to remove a custom PPA, ppa-purge fails to disable the custom PPA since it cannot disable deb822 sources and leads to apt still querying the ppa when running: $ apt update In older versions of ubuntu, PPAs used the ".list" format which could be disabled by simply commenting out the "deb" line with a "#". This was the method that ppa-purge used to disable PPAs. This new patch allows ppa-purge to detect and disable deb822 source files by adding an "Enabled: no" field in each component section of the deb822 file. It also removes any line that starts with "Enabled:" to make sure the resulting file is clean. [ Test Plan ] The changes were tested on both mantic and noble in a lxc container using the oibaf mesa PPA (https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers) as the test PPA. The following steps were recorded in a noble lxc container. - First make sure that mesa-utils is installed in your environment: $ sudo apt update && sudo apt install mesa-utils - Add the oibaf PPA to your system using the following command: $ sudo add-apt-repository ppa:oibaf/graphics-drivers - Make sure that the mesa-utils packages were upgraded after adding the PPA: $ sudo apt update && sudo apt upgrade $ dpkg - l | grep mesa - output should be similar to the following: ii libegl-mesa0:amd64 24.1~git2402280600.41722c~oibaf~n amd64free implementation of the EGL API -- Mesa vendor library ii libgl1-mesa-dri:amd64 24.1~git2402280600.41722c~oibaf~n amd64free implementation of the OpenGL API -- DRI modules ii libglapi-mesa:amd64 24.1~git2402280600.41722c~oibaf~n amd64free implementation of the GL API -- shared library ii libglx-mesa0:amd64 24.1~git2402280600.41722c~oibaf~n amd64free implementation of the OpenGL API -- GLX vendor library ii mesa-utils 9.0.0-2 amd64Miscellaneous Mesa utilities -- symlinks ii mesa-utils-bin:amd649.0.0-2 amd64Miscellaneous Mesa utilities -- native applications ii mesa-vulkan-drivers:amd64 24.1~git2402280600.41722c~oibaf~n amd64Mesa Vulkan graphics drivers - Install and run ppa-purge: $ sudo apt install ppa-purge $ sudo ppa-purge ppa:oibaf/graphics-drivers - ppa-purge will report at the end that none of the oibaf packages need to be downgraded/removed: libglapi-mesa is already the newest version (24.1~git2402280600.41722c~oibaf~n). libglapi-mesa set to manually installed. libglx-mesa0 is already the newest version (24.1~git2402280600.41722c~oibaf~n). libglx-mesa0 set to manually installed. mesa-vulkan-drivers is already the newest version (24.1~git2402280600.41722c~oibaf~n). mesa-vulkan-drivers set to manually installed. Selected version '2.4.120+git2402271331.1b4e04~oibaf~n' (Updated Open Graphics Drivers - since 2011!:24.04/noble [amd64]) for 'libdrm-amdgpu1' Selected version '2.4.120+git2402271331.1b4e04~oibaf~n' (Updated Open Graphics Drivers - since 2011!:24.04/noble [all]) for 'libdrm-common' Selected version '2.4.120+git2402271331.1b4e04~oibaf~n' (Updated Open Graphics Drivers - since 2011!:24.04/noble [amd64]) for 'libdrm-intel1' Selected version '2.4.120+git2402271331.1b4e04~oibaf~n' (Updated Open Graphics Drivers - since 2011!:24.04/noble [amd64]) for 'libdrm-nouveau2' Selected version
[Touch-packages] [Bug 2056802] Re: crypttab does not honor `x-initrd.attach` option
Thank you for the bug, Heather! I'm marking Bionic as "Won't Fix", as it's EOL. If needed, please re-target against Pro 18.04. Thanks! ** Changed in: systemd (Ubuntu Bionic) Status: New => Won't Fix -- 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/2056802 Title: crypttab does not honor `x-initrd.attach` option Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: Won't Fix Status in systemd source package in Focal: New Status in systemd source package in Jammy: New Status in systemd source package in Mantic: New Status in systemd source package in Noble: New Bug description: From systemd version 245+ an option was added x-initrd.attach - Setup this encrypted block device in the initrd, similarly to systemd.mount(5) units marked with x-initrd.mount. Although it's not necessary to mark the mount entry for the root file system with x-initrd.mount, x-initrd.attach is still recommended with the encrypted block device containing the root file system as otherwise systemd will attempt to detach the device during the regular system shutdown while it's still in use. With this option the device will still be detached but later after the root file system is unmounted. All other encrypted block devices that contain file systems mounted in the initrd should use this option. Added in version 245. [0] - release: noble systemd version: 253.5-1ubuntu6 Install noble to a vm with virt-manager and encrypt the lvm during subiquity install. After successful install, Modify /etc/crypttab to include the parameter in the 4th column example: sda6_crypt UUID=099aae4a-b11b-49a6-a6c4-62939eddf7a0 none luks,x-initrd.attach update-initramfs -u -k all During boot or shutdown the logs show cryptsetup: WARNING: dm_crypt-0: ignoring unknown option x-initrd.attach There are two separate problems 1. crypttab doesn't recognize x-initrd.attach option in /etc/crypttab file. cryptsetup: WARNING: dm_crypt-0: ignoring unknown option x-initrd.attach 2. this error happens on shutdown/restart [systemd-cryptsetup]: Device dm-crypt-0 is still in use. [systemd-cryptsetup]: Failed to deactivate: Device or resource busy. The vm does eventually shutdown after throwing the above warnings. [0] https://www.freedesktop.org/software/systemd/man/latest/crypttab.html#x-initrd.attach These patches look like they could fix the issue, The last one might not be needed. git format-patch -1 8ce02b87cece09797c1030c778db4180e1e2ce2e https://github.com/systemd/systemd/commit/8ce02b87cece09797c1030c778db4180e1e2ce2e git format-patch -1 1dc85eff1d0dff18aaeaae530c91bf53f34b726e https://github.com/systemd/systemd/commit/1dc85eff1d0dff18aaeaae530c91bf53f34b726e git format-patch -1 bf1484c70a24cf04c145a9509c8124ffd7fb0879 https://github.com/systemd/systemd/commit/bf1484c70a24cf04c145a9509c8124ffd7fb0879 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2056802/+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 1837227] Re: systemd mount units fail during boot, while file system is correctly mounted
I've successfully confirmed that the mount issues seem to be fixed using systemd from focal-proposed. Using the 'rep-tmpfs.sh' script, all variants ran without any issues for multiple rounds. Basic testing on a VM also looks good. Below are the versions used for this test: $ dpkg -l systemd ... ||/ Name Version Architecture Description +++-==-=--= ii systemd245.4-4ubuntu3.23 amd64system and service manager $ uname -rv 5.4.0-169-generic #187-Ubuntu SMP Thu Nov 23 14:52:28 UTC 2023 I'll look into the reported regressions next, to confirm none of them are caused by this LP. ** Tags removed: se-sponsor-halves verification-needed verification-needed-focal ** Tags added: verification-done verification-done-focal -- 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/1837227 Title: systemd mount units fail during boot, while file system is correctly mounted Status in systemd: New Status in Ubuntu Pro: In Progress Status in Ubuntu Pro 18.04 series: In Progress Status in linux package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in linux source package in Bionic: Won't Fix Status in systemd source package in Bionic: Won't Fix Status in linux source package in Focal: Fix Released Status in systemd source package in Focal: Fix Committed Status in linux source package in Jammy: Fix Released Status in systemd source package in Jammy: Fix Released Bug description: [Impact] systemd mount units fail during boot, and the system boots into emergency mode [Test Plan] This issue seems to happen randomly, and doesn't seem related to a specific mount unit. We've used a test script with good results during investigation to reproduce similar mount failures in a running system, and have seen a strong correlation between the script failures and the boot time mount failures. The attached 'rep-tmpfs.sh' script should be used to validate that mount points are working correctly under stress. One can run through the different variants as below: # ./rep-tmpfs.sh --variant-0 # ./rep-tmpfs.sh --variant-1 # ./rep-tmpfs.sh --variant-2 # ./rep-tmpfs.sh --variant-3 # ./rep-tmpfs.sh --variant-4 All of these should run successfully without any reported errors. [Where problems could occur] The patches change the way systemd tracks and handles mount points in general, so potential regressions could affect other mount units. We should keep an eye out for any issues with mounting file systems, as well as rapid mount/unmount operations. Successful test runs with the reproducer script should increase reliability in having no new regressions. [Other Info] This has been tackled upstream with several attempts, which have resulted in the final patch from 2022: 01400460ae16 core/mount: adjust deserialized state based on /proc/self/mountinfo For Bionic, systemd requires several dependency patches as below: 6a1d4d9fa6b9 core: properly reset all ExecStatus structures when entering a new unit cycle 7eba1463dedc mount: flush out cycle state on DEAD→MOUNTED only, not the other way round 350804867dbc mount: rescan /proc/self/mountinfo before processing waitid() results 1d086a6e5972 mount: mark an existing "mounting" unit from /proc/self/mountinfo as "just_mounted" Additionally, the kernel also requires the following patches: 28ca0d6d39ab list: introduce list_for_each_continue() 9f6c61f96f2d proc/mounts: add cursor [Original Description] In Ubuntu 18.04 at least, we sometimes get a random server in emergency mode with a failed mount unit (ext4 file system), while the corresponding file system is in fact correctly mounted. It happens roughly once every 1000 reboots. It seems to be related with this bug : https://github.com/systemd/systemd/issues/10872 Is it possible to apply the fix (https://github.com/systemd/systemd/commit/350804867dbcc9b7ccabae1187d730d37e2d8a21) in Ubuntu 18.04 ? Thanks in advance. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1837227/+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 1907878] Re: wrong var declaration in if-up.d/resolved (nm-dispatcher[54417]: /etc/network/if-up.d/resolved: 12: mystatedir: not found)
Validated according to test case from description. No error messages
shown, and networking has been correctly configured.
root@halves-lp1907878-j:~# dpkg -l | grep ifupdown
ii ifupdown 0.8.36+nmu1ubuntu3.1
amd64high level tools to configure network interfaces
root@halves-lp1907878-j:~# ifdown enp5s0; ifup enp5s0
Killed old client process
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/enp5s0/00:16:3e:a6:40:b0
Sending on LPF/enp5s0/00:16:3e:a6:40:b0
Sending on Socket/fallback
DHCPRELEASE of 10.125.177.48 on enp5s0 to 10.125.177.1 port 67 (xid=0x66ead755)
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/enp5s0/00:16:3e:a6:40:b0
Sending on LPF/enp5s0/00:16:3e:a6:40:b0
Sending on Socket/fallback
DHCPDISCOVER on enp5s0 to 255.255.255.255 port 67 interval 3 (xid=0x58e2)
DHCPOFFER of 10.125.177.48 from 10.125.177.1
DHCPREQUEST for 10.125.177.48 on enp5s0 to 255.255.255.255 port 67
(xid=0xe258)
DHCPACK of 10.125.177.48 from 10.125.177.1 (xid=0x58e2)
bound to 10.125.177.48 -- renewal in 1555 seconds.
** Tags removed: verification-needed verification-needed-jammy
** Tags added: verification-done verification-done-jammy
--
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/1907878
Title:
wrong var declaration in if-up.d/resolved (nm-dispatcher[54417]:
/etc/network/if-up.d/resolved: 12: mystatedir: not found)
Status in ifupdown package in Ubuntu:
Fix Released
Status in ifupdown source package in Jammy:
Fix Committed
Bug description:
Syslog error:
nm-dispatcher[...]: /etc/network/if-up.d/resolved: 12: mystatedir:
not found
I think it's because of this line:
if systemctl is-enabled systemd-resolved > /dev/null 2>&1; then
mystatedir statedir ifindex interface <- this
is interpreted as a 'mystatedir' command and fails
interface=$IFACE
if [ ! "$interface" ]; then
Perhaps the intention was to 'export mystatedir statedir ...'
SRU for Jammy:
[ Impact ]
* /etc/network/if-{up,down}.d/resolved have a mistype:
mystatedir statedir ifindex interface
And when this line is executed, mystatedir is not found (not a valid
command)
and it generates an error log in /var/log/syslog and the terminal output.
It's not fatal, and the rest of the code gets executed, but it generates
the
message.
# ifup ens3
/etc/network/if-up.d/resolved: 12: mystatedir: not found
# ifdown ens3
/etc/network/if-down.d/resolved: 12: mystatedir: not found
The fix accepted in kinetic is only to remove this line. The same fix can
be
applied to Jammy.
[ Test Plan ]
With the new package installed, remove netplan configuration and add a
valid
/etc/network/interfaces file and then use the commands:
# ifdown
# ifup
And confirm the messages are not displayed and the network configuration
succeeds.
[ Where problems could occur ]
If mystatedir would be a valid command or function, which is not the case,
that could break the script.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1907878/+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 1981103] Re: System with DNS server in /etc/network/interfaces has bogus systemd-resolved config after upgrade to 22.04
Validated for Jammy according to test case from description. No error messages were thrown, and networking has been correctly set up. root@halves-lp1981103-j:~# ifdown enp5s0; ifup enp5s0 Killed old client process Internet Systems Consortium DHCP Client 4.4.1 Copyright 2004-2018 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/enp5s0/00:16:3e:bb:4d:57 Sending on LPF/enp5s0/00:16:3e:bb:4d:57 Sending on Socket/fallback DHCPRELEASE of 10.125.177.27 on enp5s0 to 10.125.177.1 port 67 (xid=0x4969e444) Internet Systems Consortium DHCP Client 4.4.1 Copyright 2004-2018 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/enp5s0/00:16:3e:bb:4d:57 Sending on LPF/enp5s0/00:16:3e:bb:4d:57 Sending on Socket/fallback DHCPDISCOVER on enp5s0 to 255.255.255.255 port 67 interval 3 (xid=0x787e8804) DHCPOFFER of 10.125.177.27 from 10.125.177.1 DHCPREQUEST for 10.125.177.27 on enp5s0 to 255.255.255.255 port 67 (xid=0x4887e78) DHCPACK of 10.125.177.27 from 10.125.177.1 (xid=0x787e8804) bound to 10.125.177.27 -- renewal in 1648 seconds. root@halves-lp1981103-j:~# dpkg -l | grep ifupdown ii ifupdown 0.8.36+nmu1ubuntu3.1 amd64high level tools to configure network interfaces ** Tags removed: verification-needed-jammy ** Tags added: verification-done-jammy -- 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/1981103 Title: System with DNS server in /etc/network/interfaces has bogus systemd- resolved config after upgrade to 22.04 Status in ifupdown package in Ubuntu: Fix Released Status in ifupdown source package in Focal: Fix Released Status in ifupdown source package in Jammy: Fix Committed Status in ifupdown source package in Lunar: Fix Committed Bug description: [ Impact ] ifupdown configurations will stop having a working DNS server on upgrade [ Test Plan ] Upgrading from an Ubuntu 18.04 or earlier release, bounce a network interface with configured DNS server: root@pangaea-pm:~# ifdown ens13; ifup ens13 /etc/network/if-down.d/resolved: 12: mystatedir: not found /etc/network/if-up.d/resolved: 12: mystatedir: not found /etc/network/if-up.d/resolved: 71: DNS: not found /etc/network/if-up.d/resolved: 1: /run/network/ifupdown-inet-ens13: DNS=134.102.20.20 134.102.200.14: not found /etc/network/if-up.d/resolved: 2: /run/network/ifupdown-inet-ens13: DOMAINS=marum.de: not found Failed to parse DNS server address: DNS Failed to set DNS configuration: Invalid argument This should result in no errors, and in a valid network configuration with working DNS resolution. It's likely that existing netplan configuration needs to be removed and migrated to classic ifupdown scripts before running the test above. [ Where problems could occur ] Although we're only fixing the resolved scripts, more complex network setups might see regressions in DNS resolution for some cases. We should pay special attention to bridges or virtual interfaces that have been configured through ifupdown, as well as validate the other scripts under /etc/network/if-up.d/ [ Other Info ] Description:Ubuntu 22.04 LTS Release:22.04 ifupdown: Installed: 0.8.36+nmu1ubuntu3 Candidate: 0.8.36+nmu1ubuntu3 Version table: *** 0.8.36+nmu1ubuntu3 500 500 http://de.archive.ubuntu.com/ubuntu jammy/universe amd64 Packages 100 /var/lib/dpkg/status After upgrading a server with classic ifupdown configuration after reboot the machine had no valid dns servers anymore. The problem is that the state file created by ifupdown using /etc/network/if-up.d/resolved looks like this: root@pangaea-pm:~# cat /run/network/ifupdown-inet-ens13 "DNS"="134.102.20.20 134.102.200.14" "DOMAINS"="marum.de" The script later sources this file and causes the following errors, easy to see when you execute this: root@pangaea-pm:~# ifdown ens13; ifup ens13 /etc/network/if-down.d/resolved: 12: mystatedir: not found /etc/network/if-up.d/resolved: 12: mystatedir: not found /etc/network/if-up.d/resolved: 71: DNS: not found /etc/network/if-up.d/resolved: 1: /run/network/ifupdown-inet-ens13: DNS=134.102.20.20 134.102.200.14: not found /etc/network/if-up.d/resolved: 2: /run/network/ifupdown-inet-ens13: DOMAINS=marum.de: not found Failed to parse DNS server address: DNS Failed to set DNS configuration: Invalid argument This happened to me on three different servers, so this is a serious bug and should be fixed before 22.04 upgrades are allowed for everybody. Most servers provided by data centers like Hetzner (Germany) are configure like that. After a do-release-upgrade you have no working DNS anymore, unless you disable
[Touch-packages] [Bug 1981103] Re: System with DNS server in /etc/network/interfaces has bogus systemd-resolved config after upgrade to 22.04
Validated for Lunar according to test case from description. No error messages were thrown, and networking has been correctly set up. root@halves-lp1981103-l:~# ifdown enp5s0; ifup enp5s0 Killed old client process Internet Systems Consortium DHCP Client 4.4.3-P1 Copyright 2004-2022 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/enp5s0/00:16:3e:c7:2c:be Sending on LPF/enp5s0/00:16:3e:c7:2c:be Sending on Socket/fallback xid: warning: no netdev with useable HWADDR found for seed's uniqueness enforcement xid: rand init seed (0x65355010) built using gethostid DHCPRELEASE of 10.125.177.42 on enp5s0 to 10.125.177.1 port 67 (xid=0x1adc66da) Internet Systems Consortium DHCP Client 4.4.3-P1 Copyright 2004-2022 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/enp5s0/00:16:3e:c7:2c:be Sending on LPF/enp5s0/00:16:3e:c7:2c:be Sending on Socket/fallback xid: warning: no netdev with useable HWADDR found for seed's uniqueness enforcement xid: rand init seed (0x65355010) built using gethostid DHCPDISCOVER on enp5s0 to 255.255.255.255 port 67 interval 3 (xid=0xda66dc1a) DHCPOFFER of 10.125.177.42 from 10.125.177.1 DHCPREQUEST for 10.125.177.42 on enp5s0 to 255.255.255.255 port 67 (xid=0x1adc66da) DHCPACK of 10.125.177.42 from 10.125.177.1 (xid=0xda66dc1a) bound to 10.125.177.42 -- renewal in 1683 seconds. root@halves-lp1981103-l:~# dpkg -l | grep ifupdown ii ifupdown 0.8.36+nmu1ubuntu4.1 amd64 high level tools to configure network interfaces ** Tags removed: verification-needed verification-needed-lunar ** Tags added: verification-done verification-done-lunar -- 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/1981103 Title: System with DNS server in /etc/network/interfaces has bogus systemd- resolved config after upgrade to 22.04 Status in ifupdown package in Ubuntu: Fix Released Status in ifupdown source package in Focal: Fix Released Status in ifupdown source package in Jammy: Fix Committed Status in ifupdown source package in Lunar: Fix Committed Bug description: [ Impact ] ifupdown configurations will stop having a working DNS server on upgrade [ Test Plan ] Upgrading from an Ubuntu 18.04 or earlier release, bounce a network interface with configured DNS server: root@pangaea-pm:~# ifdown ens13; ifup ens13 /etc/network/if-down.d/resolved: 12: mystatedir: not found /etc/network/if-up.d/resolved: 12: mystatedir: not found /etc/network/if-up.d/resolved: 71: DNS: not found /etc/network/if-up.d/resolved: 1: /run/network/ifupdown-inet-ens13: DNS=134.102.20.20 134.102.200.14: not found /etc/network/if-up.d/resolved: 2: /run/network/ifupdown-inet-ens13: DOMAINS=marum.de: not found Failed to parse DNS server address: DNS Failed to set DNS configuration: Invalid argument This should result in no errors, and in a valid network configuration with working DNS resolution. It's likely that existing netplan configuration needs to be removed and migrated to classic ifupdown scripts before running the test above. [ Where problems could occur ] Although we're only fixing the resolved scripts, more complex network setups might see regressions in DNS resolution for some cases. We should pay special attention to bridges or virtual interfaces that have been configured through ifupdown, as well as validate the other scripts under /etc/network/if-up.d/ [ Other Info ] Description:Ubuntu 22.04 LTS Release:22.04 ifupdown: Installed: 0.8.36+nmu1ubuntu3 Candidate: 0.8.36+nmu1ubuntu3 Version table: *** 0.8.36+nmu1ubuntu3 500 500 http://de.archive.ubuntu.com/ubuntu jammy/universe amd64 Packages 100 /var/lib/dpkg/status After upgrading a server with classic ifupdown configuration after reboot the machine had no valid dns servers anymore. The problem is that the state file created by ifupdown using /etc/network/if-up.d/resolved looks like this: root@pangaea-pm:~# cat /run/network/ifupdown-inet-ens13 "DNS"="134.102.20.20 134.102.200.14" "DOMAINS"="marum.de" The script later sources this file and causes the following errors, easy to see when you execute this: root@pangaea-pm:~# ifdown ens13; ifup ens13 /etc/network/if-down.d/resolved: 12: mystatedir: not found /etc/network/if-up.d/resolved: 12: mystatedir: not found /etc/network/if-up.d/resolved: 71: DNS: not found /etc/network/if-up.d/resolved: 1: /run/network/ifupdown-inet-ens13: DNS=134.102.20.20 134.102.200.14: not found /etc/network/if-up.d/resolved: 2: /run/network/ifupdown-inet-ens13: DOMAINS=marum.de: not found Failed to parse DNS server address: DNS Failed to set DNS configuration: Invalid argument This
[Touch-packages] [Bug 1907878] Re: wrong var declaration in if-up.d/resolved (nm-dispatcher[54417]: /etc/network/if-up.d/resolved: 12: mystatedir: not found)
@jasimioni I've dropped some bits of your diff that aren't necessary for
SRU (the typo fix), and sponsored your changes with mine from bug
1981103. Thank you for the help on fixing this!
--
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/1907878
Title:
wrong var declaration in if-up.d/resolved (nm-dispatcher[54417]:
/etc/network/if-up.d/resolved: 12: mystatedir: not found)
Status in ifupdown package in Ubuntu:
Fix Released
Status in ifupdown source package in Jammy:
In Progress
Bug description:
Syslog error:
nm-dispatcher[...]: /etc/network/if-up.d/resolved: 12: mystatedir:
not found
I think it's because of this line:
if systemctl is-enabled systemd-resolved > /dev/null 2>&1; then
mystatedir statedir ifindex interface <- this
is interpreted as a 'mystatedir' command and fails
interface=$IFACE
if [ ! "$interface" ]; then
Perhaps the intention was to 'export mystatedir statedir ...'
SRU for Jammy:
[ Impact ]
* /etc/network/if-{up,down}.d/resolved have a mistype:
mystatedir statedir ifindex interface
And when this line is executed, mystatedir is not found (not a valid
command)
and it generates an error log in /var/log/syslog and the terminal output.
It's not fatal, and the rest of the code gets executed, but it generates
the
message.
# ifup ens3
/etc/network/if-up.d/resolved: 12: mystatedir: not found
# ifdown ens3
/etc/network/if-down.d/resolved: 12: mystatedir: not found
The fix accepted in kinetic is only to remove this line. The same fix can
be
applied to Jammy.
[ Test Plan ]
With the new package installed, remove netplan configuration and add a
valid
/etc/network/interfaces file and then use the commands:
# ifdown
# ifup
And confirm the messages are not displayed and the network configuration
succeeds.
[ Where problems could occur ]
If mystatedir would be a valid command or function, which is not the case,
that could break the script.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1907878/+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 1981103] Re: System with DNS server in /etc/network/interfaces has bogus systemd-resolved config after upgrade to 22.04
Focal isn't affected by this, so marking it as Fix Released.
** Changed in: ifupdown (Ubuntu Focal)
Status: In Progress => Fix Released
--
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/1981103
Title:
System with DNS server in /etc/network/interfaces has bogus systemd-
resolved config after upgrade to 22.04
Status in ifupdown package in Ubuntu:
Fix Released
Status in ifupdown source package in Focal:
Fix Released
Status in ifupdown source package in Jammy:
In Progress
Status in ifupdown source package in Lunar:
In Progress
Bug description:
[ Impact ]
ifupdown configurations will stop having a working DNS server on upgrade
[ Test Plan ]
Upgrading from an Ubuntu 18.04 or earlier release, bounce a network interface
with configured DNS server:
root@pangaea-pm:~# ifdown ens13; ifup ens13
/etc/network/if-down.d/resolved: 12: mystatedir: not found
/etc/network/if-up.d/resolved: 12: mystatedir: not found
/etc/network/if-up.d/resolved: 71: DNS: not found
/etc/network/if-up.d/resolved: 1: /run/network/ifupdown-inet-ens13:
DNS=134.102.20.20 134.102.200.14: not found
/etc/network/if-up.d/resolved: 2: /run/network/ifupdown-inet-ens13:
DOMAINS=marum.de: not found
Failed to parse DNS server address: DNS
Failed to set DNS configuration: Invalid argument
This should result in no errors, and in a valid network configuration with
working DNS resolution.
It's likely that existing netplan configuration needs to be removed and
migrated to classic ifupdown scripts before running the test above.
[ Where problems could occur ]
Although we're only fixing the resolved scripts, more complex network setups
might see regressions in DNS resolution for some cases. We should pay special
attention to bridges or virtual interfaces that have been configured through
ifupdown, as well as validate the other scripts under /etc/network/if-up.d/
[ Other Info ]
Description:Ubuntu 22.04 LTS
Release:22.04
ifupdown:
Installed: 0.8.36+nmu1ubuntu3
Candidate: 0.8.36+nmu1ubuntu3
Version table:
*** 0.8.36+nmu1ubuntu3 500
500 http://de.archive.ubuntu.com/ubuntu jammy/universe amd64 Packages
100 /var/lib/dpkg/status
After upgrading a server with classic ifupdown configuration after
reboot the machine had no valid dns servers anymore.
The problem is that the state file created by ifupdown using
/etc/network/if-up.d/resolved looks like this:
root@pangaea-pm:~# cat /run/network/ifupdown-inet-ens13
"DNS"="134.102.20.20 134.102.200.14"
"DOMAINS"="marum.de"
The script later sources this file and causes the following errors,
easy to see when you execute this:
root@pangaea-pm:~# ifdown ens13; ifup ens13
/etc/network/if-down.d/resolved: 12: mystatedir: not found
/etc/network/if-up.d/resolved: 12: mystatedir: not found
/etc/network/if-up.d/resolved: 71: DNS: not found
/etc/network/if-up.d/resolved: 1: /run/network/ifupdown-inet-ens13:
DNS=134.102.20.20 134.102.200.14: not found
/etc/network/if-up.d/resolved: 2: /run/network/ifupdown-inet-ens13:
DOMAINS=marum.de: not found
Failed to parse DNS server address: DNS
Failed to set DNS configuration: Invalid argument
This happened to me on three different servers, so this is a serious
bug and should be fixed before 22.04 upgrades are allowed for
everybody. Most servers provided by data centers like Hetzner
(Germany) are configure like that. After a do-release-upgrade you have
no working DNS anymore, unless you disable systemd-resolved. I don't
want to use netplan, so changing to this is no option.
The fix is easy - remove the quotes in the script on the left side
"$DNS" => $DNS; same for DOMAINS:
if [ -n "$NEW_DNS" ]; then
cat <"$mystatedir/ifupdown-${ADDRFAM}-$interface"
$DNS="$NEW_DNS"
EOF
if [ -n "$NEW_DOMAINS" ]; then
cat <>"$mystatedir/ifupdown-${ADDRFAM}-$interface"
$DOMAINS="$NEW_DOMAINS"
EOF
fi
fi
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1981103/+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 1981103] Re: System with DNS server in /etc/network/interfaces has bogus systemd-resolved config after upgrade to 22.04
** Description changed:
+ [ Impact ]
+ ifupdown configurations will stop having a working DNS server on upgrade
+
+ [ Test Plan ]
+ Upgrading from an Ubuntu 18.04 or earlier release, bounce a network interface
with configured DNS server:
+
+ root@pangaea-pm:~# ifdown ens13; ifup ens13
+ /etc/network/if-down.d/resolved: 12: mystatedir: not found
+ /etc/network/if-up.d/resolved: 12: mystatedir: not found
+ /etc/network/if-up.d/resolved: 71: DNS: not found
+ /etc/network/if-up.d/resolved: 1: /run/network/ifupdown-inet-ens13:
DNS=134.102.20.20 134.102.200.14: not found
+ /etc/network/if-up.d/resolved: 2: /run/network/ifupdown-inet-ens13:
DOMAINS=marum.de: not found
+ Failed to parse DNS server address: DNS
+ Failed to set DNS configuration: Invalid argument
+
+ This should result in no errors, and in a valid network configuration with
working DNS resolution.
+ It's likely that existing netplan configuration needs to be removed and
migrated to classic ifupdown scripts before running the test above.
+
+ [ Where problems could occur ]
+ Although we're only fixing the resolved scripts, more complex network setups
might see regressions in DNS resolution for some cases. We should pay special
attention to bridges or virtual interfaces that have been configured through
ifupdown, as well as validate the other scripts under /etc/network/if-up.d/
+
+ [ Other Info ]
Description:Ubuntu 22.04 LTS
Release:22.04
ifupdown:
- Installed: 0.8.36+nmu1ubuntu3
- Candidate: 0.8.36+nmu1ubuntu3
- Version table:
- *** 0.8.36+nmu1ubuntu3 500
- 500 http://de.archive.ubuntu.com/ubuntu jammy/universe amd64 Packages
- 100 /var/lib/dpkg/status
+ Installed: 0.8.36+nmu1ubuntu3
+ Candidate: 0.8.36+nmu1ubuntu3
+ Version table:
+ *** 0.8.36+nmu1ubuntu3 500
+ 500 http://de.archive.ubuntu.com/ubuntu jammy/universe amd64 Packages
+ 100 /var/lib/dpkg/status
After upgrading a server with classic ifupdown configuration after
reboot the machine had no valid dns servers anymore.
The problem is that the state file created by ifupdown using
/etc/network/if-up.d/resolved looks like this:
root@pangaea-pm:~# cat /run/network/ifupdown-inet-ens13
"DNS"="134.102.20.20 134.102.200.14"
"DOMAINS"="marum.de"
The script later sources this file and causes the following errors, easy
to see when you execute this:
root@pangaea-pm:~# ifdown ens13; ifup ens13
/etc/network/if-down.d/resolved: 12: mystatedir: not found
/etc/network/if-up.d/resolved: 12: mystatedir: not found
/etc/network/if-up.d/resolved: 71: DNS: not found
/etc/network/if-up.d/resolved: 1: /run/network/ifupdown-inet-ens13:
DNS=134.102.20.20 134.102.200.14: not found
/etc/network/if-up.d/resolved: 2: /run/network/ifupdown-inet-ens13:
DOMAINS=marum.de: not found
Failed to parse DNS server address: DNS
Failed to set DNS configuration: Invalid argument
This happened to me on three different servers, so this is a serious bug
and should be fixed before 22.04 upgrades are allowed for everybody.
Most servers provided by data centers like Hetzner (Germany) are
configure like that. After a do-release-upgrade you have no working DNS
anymore, unless you disable systemd-resolved. I don't want to use
netplan, so changing to this is no option.
The fix is easy - remove the quotes in the script on the left side
"$DNS" => $DNS; same for DOMAINS:
- if [ -n "$NEW_DNS" ]; then
- cat <"$mystatedir/ifupdown-${ADDRFAM}-$interface"
+ if [ -n "$NEW_DNS" ]; then
+ cat <"$mystatedir/ifupdown-${ADDRFAM}-$interface"
$DNS="$NEW_DNS"
EOF
- if [ -n "$NEW_DOMAINS" ]; then
- cat <>"$mystatedir/ifupdown-${ADDRFAM}-$interface"
+ if [ -n "$NEW_DOMAINS" ]; then
+ cat <>"$mystatedir/ifupdown-${ADDRFAM}-$interface"
$DOMAINS="$NEW_DOMAINS"
EOF
- fi
- fi
+ fi
+ fi
** Also affects: ifupdown (Ubuntu Focal)
Importance: Undecided
Status: New
** Also affects: ifupdown (Ubuntu Jammy)
Importance: Undecided
Status: New
** Also affects: ifupdown (Ubuntu Lunar)
Importance: Undecided
Status: New
** Changed in: ifupdown (Ubuntu Focal)
Assignee: (unassigned) => Heitor Alves de Siqueira (halves)
** Changed in: ifupdown (Ubuntu Jammy)
Assignee: (unassigned) => Heitor Alves de Siqueira (halves)
** Changed in: ifupdown (Ubuntu Lunar)
Assignee: (unassigned) => Heitor Alves de Siqueira (halves)
** Changed in: ifupdown (Ubuntu Focal)
Status: New => In Progress
** Changed in: ifupdown (Ubuntu Jammy)
Status: New => In Progress
** Changed in: ifupdown (Ubuntu Lunar)
Status: New => In Progress
** Changed in: ifupdown (Ubuntu Focal)
Importance: Undecided
[Touch-packages] [Bug 2024864] Re: systemd-networkd crashes with SIGSEGV
This bug was fixed in the package below, available under Ubuntu Pro
18.04.
systemd (237-3ubuntu10.57+esm1) bionic; urgency=medium
* d/p/lp2024864-add-missing-null-check.patch:
- Add NULL check on link_drop_foreign_request (LP: #2024864)
-- Tiago Pasqualini Fri, 23 Jun 2023
16:51:01 -0300
** Changed in: ubuntu-pro/18.04
Status: In Progress => Fix Released
--
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/2024864
Title:
systemd-networkd crashes with SIGSEGV
Status in systemd:
Fix Released
Status in Ubuntu Pro:
Fix Released
Status in Ubuntu Pro 18.04 series:
Fix Released
Status in systemd package in Ubuntu:
Fix Released
Bug description:
[ Impact ]
Customer reported that this issue happens randomly during their
automated regression runs. It's not consistent and hard to reproduce.
They have shared a coredump:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x555962aa1c34 in link_drop_foreign_config
(link=link@entry=0x555963583f30) at ../src/network/networkd-link.c:2741
2741 ../src/network/networkd-link.c: No such file or directory.
(gdb) bt
#0 0x555962aa1c34 in link_drop_foreign_config
(link=link@entry=0x555963583f30) at ../src/network/networkd-link.c:2741
#1 0x555962aa233d in link_carrier_lost.lto_priv.328 (link=, link=) at ../src/network/networkd-link.c:3462
#2 0x555962a8e9b2 in link_update (m=0x5559635702c0, link=)
at ../src/network/networkd-link.c:3698
#3 manager_rtnl_process_link (rtnl=, message=0x5559635702c0,
userdata=) at ../src/network/networkd-manager.c:713
#4 0x555962a48a16 in process_match (m=0x5559635702c0,
rtnl=0x55596355d990) at ../src/libsystemd/sd-netlink/sd-netlink.c:388
#5 process_running (ret=0x0, rtnl=0x55596355d990) at
../src/libsystemd/sd-netlink/sd-netlink.c:418
#6 sd_netlink_process (rtnl=0x55596355d990, ret=ret@entry=0x0) at
../src/libsystemd/sd-netlink/sd-netlink.c:452
#7 0x555962a48cb3 in time_callback (s=, usec=, userdata=) at ../src/libsystemd/sd-netlink/sd-netlink.c:759
#8 0x555962a4dbae in source_dispatch (s=s@entry=0x55596355dce0) at
../src/libsystemd/sd-event/sd-event.c:2311
#9 0x555962a4de2a in sd_event_dispatch (e=,
e@entry=0x55596355bf70) at ../src/libsystemd/sd-event/sd-event.c:2663
#10 0x555962a4dfb9 in sd_event_run (e=,
e@entry=0x55596355bf70, timeout=timeout@entry=18446744073709551615) at
../src/libsystemd/sd-event/sd-event.c:2723
#11 0x555962a4e1fb in sd_event_loop (e=) at
../src/libsystemd/sd-event/sd-event.c:2744
#12 0x555962a223d6 in main (argc=, argv=)
at ../src/network/networkd.c:158
This can be fixed by simply null checking link->network before doing anything
with it. Upstream has fixed it on this commit:
https://github.com/systemd/systemd/commit/b1b0b42e48303134731e017a108c6c334ef5f4c8
[ Test Plan ]
Since this issue is hard to reproduce, I was able trigger it on gdb,
by adding a breakpoint once the manager is setup, getting the loopback
device and running link_drop_foreign_config on the loopback device:
(gdb) b src/network/networkd.c:150
Breakpoint 1 at 0x2f38f: file ../src/network/networkd.c, line 150.
(gdb) r
Starting program: /lib/systemd/systemd-networkd
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
eth0: IPv6 successfully enabled
eth0: Gained IPv6LL
Breakpoint 1, main (argc=, argv=) at
../src/network/networkd.c:152
152 log_info("Enumeration completed");
(gdb) p *m->links
$1 = {b = {hash_ops = 0x5578f230 , {indirect = {storage
= 0x2e, hash_key = "\200\376yUUU\000\000\001\000\000\000\000\000\000",
n_entries = 1434074992, n_buckets = 21845, idx_lowest_entry = 256,
_pad = "\000\000"}, direct = {
storage =
".\000\000\000\000\000\000\000\200\376yUUU\000\000\001\000\000\000\000\000\000\000p?zUUU\000\000\000\001\000\000\000\000"}},
type = HASHMAP_TYPE_PLAIN, has_indirect = false, n_direct_entries = 2,
from_pool = true}}
(gdb) set $mylink = (Link **) malloc(sizeof(Link *))
(gdb) call link_get(m, 1, $mylink)
$2 = 0
(gdb) p *$mylink
$3 = (Link *) 0x557a3f70
(gdb) p **$mylink
$4 = {manager = 0x55796940, n_ref = 2, ifindex = 1, master_ifindex = 0,
ifname = 0x557a0060 "lo", kind = 0x0, iftype = 772,
state_file = 0x5579c670 "/run/systemd/netif/links/1", mac =
{ether_addr_octet = "\000\000\000\000\000"}, ipv6ll_address = {__in6_u = {
__u6_addr8 = '\000' , __u6_addr16 = {0, 0, 0, 0, 0,
0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, mtu = 65536, udev_device = 0x0,
flags = 65609, kernel_operstate = 0 '\000', network = 0x0, state =
LINK_STATE_UNMANAGED, operstate = LINK_OPERSTATE_CARRIER, address_messages = 0,
address_label_messages = 0, route_messages = 0,
routing_policy_rule_messages = 0,
[Touch-packages] [Bug 1837227] Re: systemd mount units fail during boot, while file system is correctly mounted
I've tested the kernel from focal-proposed, with the systemd packages from my personal PPA (as the systemd patches aren't yet available in focal-proposed). All test variants from the rep-tmpfs.sh script ran succesfully, and general smoke testing revealed no further issues. ubuntu@z-rotomvm35:~$ uname -rv 5.4.0-164-generic #181-Ubuntu SMP Fri Sep 1 13:41:22 UTC 2023 ubuntu@z-rotomvm35:~$ dpkg -l systemd Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name VersionArchitecture Description +++-==-==--= ii systemd245.4-4ubuntu3.22+20230626dbg2 amd64system and service manager ** Tags removed: verification-needed-focal-linux ** Tags added: verification-done-focal-linux -- 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/1837227 Title: systemd mount units fail during boot, while file system is correctly mounted Status in systemd: New Status in Ubuntu Pro: In Progress Status in Ubuntu Pro 18.04 series: In Progress Status in linux package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in linux source package in Bionic: Won't Fix Status in systemd source package in Bionic: Won't Fix Status in linux source package in Focal: Fix Committed Status in systemd source package in Focal: In Progress Status in linux source package in Jammy: Fix Released Status in systemd source package in Jammy: Fix Released Bug description: [Impact] systemd mount units fail during boot, and the system boots into emergency mode [Test Plan] This issue seems to happen randomly, and doesn't seem related to a specific mount unit. We've used a test script with good results during investigation to reproduce similar mount failures in a running system, and have seen a strong correlation between the script failures and the boot time mount failures. The attached 'rep-tmpfs.sh' script should be used to validate that mount points are working correctly under stress. One can run through the different variants as below: # ./rep-tmpfs.sh --variant-0 # ./rep-tmpfs.sh --variant-1 # ./rep-tmpfs.sh --variant-2 # ./rep-tmpfs.sh --variant-3 # ./rep-tmpfs.sh --variant-4 All of these should run successfully without any reported errors. [Where problems could occur] The patches change the way systemd tracks and handles mount points in general, so potential regressions could affect other mount units. We should keep an eye out for any issues with mounting file systems, as well as rapid mount/unmount operations. Successful test runs with the reproducer script should increase reliability in having no new regressions. [Other Info] This has been tackled upstream with several attempts, which have resulted in the final patch from 2022: 01400460ae16 core/mount: adjust deserialized state based on /proc/self/mountinfo For Bionic, systemd requires several dependency patches as below: 6a1d4d9fa6b9 core: properly reset all ExecStatus structures when entering a new unit cycle 7eba1463dedc mount: flush out cycle state on DEAD→MOUNTED only, not the other way round 350804867dbc mount: rescan /proc/self/mountinfo before processing waitid() results 1d086a6e5972 mount: mark an existing "mounting" unit from /proc/self/mountinfo as "just_mounted" Additionally, the kernel also requires the following patches: 28ca0d6d39ab list: introduce list_for_each_continue() 9f6c61f96f2d proc/mounts: add cursor [Original Description] In Ubuntu 18.04 at least, we sometimes get a random server in emergency mode with a failed mount unit (ext4 file system), while the corresponding file system is in fact correctly mounted. It happens roughly once every 1000 reboots. It seems to be related with this bug : https://github.com/systemd/systemd/issues/10872 Is it possible to apply the fix (https://github.com/systemd/systemd/commit/350804867dbcc9b7ccabae1187d730d37e2d8a21) in Ubuntu 18.04 ? Thanks in advance. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1837227/+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 1837227] Re: systemd mount units fail during boot, while file system is correctly mounted
** Also affects: linux (Ubuntu) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Bionic) Status: New => Won't Fix ** Changed in: linux (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: linux (Ubuntu Focal) Status: New => Fix Committed ** Changed in: linux (Ubuntu Focal) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: linux (Ubuntu Focal) Importance: Medium => High ** Changed in: systemd (Ubuntu Focal) Status: Fix Committed => In Progress ** Changed in: linux (Ubuntu) Status: New => Fix Released ** Changed in: linux (Ubuntu Jammy) Status: New => Fix Released -- 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/1837227 Title: systemd mount units fail during boot, while file system is correctly mounted Status in systemd: New Status in Ubuntu Pro: In Progress Status in Ubuntu Pro 18.04 series: In Progress Status in linux package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in linux source package in Bionic: Won't Fix Status in systemd source package in Bionic: Won't Fix Status in linux source package in Focal: Fix Committed Status in systemd source package in Focal: In Progress Status in linux source package in Jammy: Fix Released Status in systemd source package in Jammy: Fix Released Bug description: [Impact] systemd mount units fail during boot, and the system boots into emergency mode [Test Plan] This issue seems to happen randomly, and doesn't seem related to a specific mount unit. We've used a test script with good results during investigation to reproduce similar mount failures in a running system, and have seen a strong correlation between the script failures and the boot time mount failures. The attached 'rep-tmpfs.sh' script should be used to validate that mount points are working correctly under stress. One can run through the different variants as below: # ./rep-tmpfs.sh --variant-0 # ./rep-tmpfs.sh --variant-1 # ./rep-tmpfs.sh --variant-2 # ./rep-tmpfs.sh --variant-3 # ./rep-tmpfs.sh --variant-4 All of these should run successfully without any reported errors. [Where problems could occur] The patches change the way systemd tracks and handles mount points in general, so potential regressions could affect other mount units. We should keep an eye out for any issues with mounting file systems, as well as rapid mount/unmount operations. Successful test runs with the reproducer script should increase reliability in having no new regressions. [Other Info] This has been tackled upstream with several attempts, which have resulted in the final patch from 2022: 01400460ae16 core/mount: adjust deserialized state based on /proc/self/mountinfo For Bionic, systemd requires several dependency patches as below: 6a1d4d9fa6b9 core: properly reset all ExecStatus structures when entering a new unit cycle 7eba1463dedc mount: flush out cycle state on DEAD→MOUNTED only, not the other way round 350804867dbc mount: rescan /proc/self/mountinfo before processing waitid() results 1d086a6e5972 mount: mark an existing "mounting" unit from /proc/self/mountinfo as "just_mounted" Additionally, the kernel also requires the following patches: 28ca0d6d39ab list: introduce list_for_each_continue() 9f6c61f96f2d proc/mounts: add cursor [Original Description] In Ubuntu 18.04 at least, we sometimes get a random server in emergency mode with a failed mount unit (ext4 file system), while the corresponding file system is in fact correctly mounted. It happens roughly once every 1000 reboots. It seems to be related with this bug : https://github.com/systemd/systemd/issues/10872 Is it possible to apply the fix (https://github.com/systemd/systemd/commit/350804867dbcc9b7ccabae1187d730d37e2d8a21) in Ubuntu 18.04 ? Thanks in advance. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1837227/+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 1981103] Re: System with DNS server in /etc/network/interfaces has bogus systemd-resolved config after upgrade to 22.04
** Patch added: "lp1981103.debdiff"
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1981103/+attachment/5698057/+files/lp1981103.debdiff
--
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/1981103
Title:
System with DNS server in /etc/network/interfaces has bogus systemd-
resolved config after upgrade to 22.04
Status in ifupdown package in Ubuntu:
In Progress
Bug description:
Description:Ubuntu 22.04 LTS
Release:22.04
ifupdown:
Installed: 0.8.36+nmu1ubuntu3
Candidate: 0.8.36+nmu1ubuntu3
Version table:
*** 0.8.36+nmu1ubuntu3 500
500 http://de.archive.ubuntu.com/ubuntu jammy/universe amd64 Packages
100 /var/lib/dpkg/status
After upgrading a server with classic ifupdown configuration after
reboot the machine had no valid dns servers anymore.
The problem is that the state file created by ifupdown using
/etc/network/if-up.d/resolved looks like this:
root@pangaea-pm:~# cat /run/network/ifupdown-inet-ens13
"DNS"="134.102.20.20 134.102.200.14"
"DOMAINS"="marum.de"
The script later sources this file and causes the following errors,
easy to see when you execute this:
root@pangaea-pm:~# ifdown ens13; ifup ens13
/etc/network/if-down.d/resolved: 12: mystatedir: not found
/etc/network/if-up.d/resolved: 12: mystatedir: not found
/etc/network/if-up.d/resolved: 71: DNS: not found
/etc/network/if-up.d/resolved: 1: /run/network/ifupdown-inet-ens13:
DNS=134.102.20.20 134.102.200.14: not found
/etc/network/if-up.d/resolved: 2: /run/network/ifupdown-inet-ens13:
DOMAINS=marum.de: not found
Failed to parse DNS server address: DNS
Failed to set DNS configuration: Invalid argument
This happened to me on three different servers, so this is a serious
bug and should be fixed before 22.04 upgrades are allowed for
everybody. Most servers provided by data centers like Hetzner
(Germany) are configure like that. After a do-release-upgrade you have
no working DNS anymore, unless you disable systemd-resolved. I don't
want to use netplan, so changing to this is no option.
The fix is easy - remove the quotes in the script on the left side
"$DNS" => $DNS; same for DOMAINS:
if [ -n "$NEW_DNS" ]; then
cat <"$mystatedir/ifupdown-${ADDRFAM}-$interface"
$DNS="$NEW_DNS"
EOF
if [ -n "$NEW_DOMAINS" ]; then
cat <>"$mystatedir/ifupdown-${ADDRFAM}-$interface"
$DOMAINS="$NEW_DOMAINS"
EOF
fi
fi
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1981103/+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 1981103] Re: System with DNS server in /etc/network/interfaces has bogus systemd-resolved config after upgrade to 22.04
I've attached a debdiff with the patches for fixing this one. I've
subscribed ubuntu-sponsors to kindly request sponsorship for mantic.
Thanks!
--
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/1981103
Title:
System with DNS server in /etc/network/interfaces has bogus systemd-
resolved config after upgrade to 22.04
Status in ifupdown package in Ubuntu:
In Progress
Bug description:
Description:Ubuntu 22.04 LTS
Release:22.04
ifupdown:
Installed: 0.8.36+nmu1ubuntu3
Candidate: 0.8.36+nmu1ubuntu3
Version table:
*** 0.8.36+nmu1ubuntu3 500
500 http://de.archive.ubuntu.com/ubuntu jammy/universe amd64 Packages
100 /var/lib/dpkg/status
After upgrading a server with classic ifupdown configuration after
reboot the machine had no valid dns servers anymore.
The problem is that the state file created by ifupdown using
/etc/network/if-up.d/resolved looks like this:
root@pangaea-pm:~# cat /run/network/ifupdown-inet-ens13
"DNS"="134.102.20.20 134.102.200.14"
"DOMAINS"="marum.de"
The script later sources this file and causes the following errors,
easy to see when you execute this:
root@pangaea-pm:~# ifdown ens13; ifup ens13
/etc/network/if-down.d/resolved: 12: mystatedir: not found
/etc/network/if-up.d/resolved: 12: mystatedir: not found
/etc/network/if-up.d/resolved: 71: DNS: not found
/etc/network/if-up.d/resolved: 1: /run/network/ifupdown-inet-ens13:
DNS=134.102.20.20 134.102.200.14: not found
/etc/network/if-up.d/resolved: 2: /run/network/ifupdown-inet-ens13:
DOMAINS=marum.de: not found
Failed to parse DNS server address: DNS
Failed to set DNS configuration: Invalid argument
This happened to me on three different servers, so this is a serious
bug and should be fixed before 22.04 upgrades are allowed for
everybody. Most servers provided by data centers like Hetzner
(Germany) are configure like that. After a do-release-upgrade you have
no working DNS anymore, unless you disable systemd-resolved. I don't
want to use netplan, so changing to this is no option.
The fix is easy - remove the quotes in the script on the left side
"$DNS" => $DNS; same for DOMAINS:
if [ -n "$NEW_DNS" ]; then
cat <"$mystatedir/ifupdown-${ADDRFAM}-$interface"
$DNS="$NEW_DNS"
EOF
if [ -n "$NEW_DOMAINS" ]; then
cat <>"$mystatedir/ifupdown-${ADDRFAM}-$interface"
$DOMAINS="$NEW_DOMAINS"
EOF
fi
fi
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1981103/+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 2002043] Re: Python extension modules get built using wrong compiler flags with python2
Thanks for the debdiffs, Ghadi! I've marked Bionic as Won't Fix, as the
release is not under standard support anymore. If this is needed for
18.04, please consider targeting it under the Ubuntu Pro project.
** Changed in: python2.7 (Ubuntu Bionic)
Status: In Progress => Won't Fix
** Patch removed: "[bionic]add-optimization-flags-to-cflags.diff"
https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/2002043/+attachment/5685152/+files/%5Bbionic%5Dadd-optimization-flags-to-cflags.diff
--
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/2002043
Title:
Python extension modules get built using wrong compiler flags with
python2
Status in python2.7 package in Ubuntu:
In Progress
Status in python2.7 source package in Bionic:
Won't Fix
Status in python2.7 source package in Focal:
In Progress
Status in python2.7 source package in Jammy:
In Progress
Status in python2.7 source package in Kinetic:
In Progress
Status in python2.7 source package in Lunar:
Won't Fix
Status in python2.7 source package in Mantic:
Won't Fix
Bug description:
Compiling a Python extension using Python2 (Python 2.7.18) is making
use of wrong compiler flags, hence dropping required optimizations
when required. This is happening only when python2 is installed from
Ubuntu's repositories. By default, Python's distutils module uses
compiler and linker flags used to compile Python itself to be used to
compile extensions.
Steps to reproduce:
1) On Ubuntu 20.04, install python2 using apt package manager.
2) After successful installation, verify the CFLAGS variable from sysconfig
module. On my machine, the output is
Python 2.7.18 (default, Jul 1 2022, 12:27:04)
[GCC 9.4.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sysconfig
>>> sysconfig.get_config_var('CFLAGS')
'-fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes
-Wdate-time -D_FORTIFY_SOURCE=2 -g
-fdebug-prefix-map=/build/python2.7-vvQ8AI/python2.7-2.7.18=.
-fstack-protector-strong -Wformat -Werror=format-security '
3) Build a test extension module using python2 and verify the compilation
flags.
python2 setup.py build_ext --inplace
Output from below command is not matching with our expected above CFLAGS.
aarch64-linux-gnu-gcc -pthread -fno-strict-aliasing -Wdate-time
-D_FORTIFY_SOURCE=2 -g
-fdebug-prefix-map=/build/python2.7-vvQ8AI/python2.7-2.7.18=.
-fstack-protector-strong -Wformat -Werror=format-security -fPIC
-I/usr/include/python2.7 -c testmodule.c -o
build/temp.linux-aarch64-2.7/testmodule.o
On further investigation, it looks like Ubuntu's specific patch applied on
libpython2.7-stdlib package is altering the original upstream implementation of
distutils/sysconfig.py code.
Package - https://packages.ubuntu.com/focal/libpython2.7-stdlib
Patch -
http://archive.ubuntu.com/ubuntu/pool/universe/p/python2.7/python2.7_2.7.18-1~20.04.3.diff.gz
Below is the code block which is causing the issue, where the presence of
configure_cflags is modifying cflags. This code is result of ubuntu's patch and
doesn't come directly from upstream python implementation.
File - /usr/lib/python2.7/distutils/sysconfig.py
Part of code block:
elif configure_cflags:
cflags = ' '.join(str(x) for x in (basecflags, configure_cflags,
extra_cflags) if x)
ldshared = ldshared + ' ' + configure_cflags
I don't see problem on Python3 though we have extra code added from patch
there as well. Patch used on python3, is not modifying the cflags completely
and instead appending new flags to cflags.
On python3 (tested on Ubuntu 20.04)
File - /usr/lib/python3.8/distutils/sysconfig.py
Part of code block which doesn't alter cflags completely
elif configure_cflags:
cflags = cflags + ' ' + configure_cflags
ldshared = ldshared + ' ' + configure_cflags
Request to update the python2 patch to behave similar to what is been done on
python3.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/2002043/+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 1837227] Re: systemd mount units fail during boot, while file system is correctly mounted
I wasn't able to reproduce this with the test script, so Jammy is likely unaffected by this. If this changes, please leave a comment so we can investigate. ** Changed in: systemd (Ubuntu Jammy) Status: In Progress => Fix Released -- 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/1837227 Title: systemd mount units fail during boot, while file system is correctly mounted Status in systemd: New Status in Ubuntu Pro: In Progress Status in Ubuntu Pro 18.04 series: In Progress Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Won't Fix Status in systemd source package in Focal: In Progress Status in systemd source package in Jammy: Fix Released Bug description: [Impact] systemd mount units fail during boot, and the system boots into emergency mode [Test Plan] This issue seems to happen randomly, and doesn't seem related to a specific mount unit. We've used a test script with good results during investigation to reproduce similar mount failures in a running system, and have seen a strong correlation between the script failures and the boot time mount failures. [Where problems could occur] The patches change the way systemd tracks and handles mount points in general, so potential regressions could affect other mount units. We should keep an eye out for any issues with mounting file systems, as well as rapid mount/unmount operations. Successful test runs with the reproducer script should increase reliability in having no new regressions. [Other Info] This has been tackled upstream with several attempts, which have resulted in the final patch from 2022: 01400460ae16 core/mount: adjust deserialized state based on /proc/self/mountinfo For Bionic, systemd requires several dependency patches as below: 6a1d4d9fa6b9 core: properly reset all ExecStatus structures when entering a new unit cycle 7eba1463dedc mount: flush out cycle state on DEAD→MOUNTED only, not the other way round 350804867dbc mount: rescan /proc/self/mountinfo before processing waitid() results 1d086a6e5972 mount: mark an existing "mounting" unit from /proc/self/mountinfo as "just_mounted" Additionally, the kernel also requires the following patches: 28ca0d6d39ab list: introduce list_for_each_continue() 9f6c61f96f2d proc/mounts: add cursor [Original Description] In Ubuntu 18.04 at least, we sometimes get a random server in emergency mode with a failed mount unit (ext4 file system), while the corresponding file system is in fact correctly mounted. It happens roughly once every 1000 reboots. It seems to be related with this bug : https://github.com/systemd/systemd/issues/10872 Is it possible to apply the fix (https://github.com/systemd/systemd/commit/350804867dbcc9b7ccabae1187d730d37e2d8a21) in Ubuntu 18.04 ? Thanks in advance. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1837227/+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 1837227] Re: Random mount units sometimes fail, while file system is correctly mounted
I'm marking Bionic as Won't Fix, as this is no longer under standard support. The fixes for this bug will be made available under Ubuntu Pro for 18.04. ** Also affects: systemd (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu Focal) Status: New => In Progress ** Changed in: systemd (Ubuntu Focal) Importance: Undecided => High ** Changed in: systemd (Ubuntu Focal) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: systemd (Ubuntu Jammy) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: systemd (Ubuntu Jammy) Status: New => In Progress ** Tags removed: ddstreet ** Tags added: se-sponsor-halves ** Summary changed: - Random mount units sometimes fail, while file system is correctly mounted + Mount units sometimes fail, while file system is correctly mounted ** Summary changed: - Mount units sometimes fail, while file system is correctly mounted + systemd mount units fail during boot, while file system is correctly mounted ** Also affects: systemd (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu Bionic) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: systemd (Ubuntu Bionic) Status: New => Won't Fix ** Description changed: - In Ubuntu 18.04 at least, we sometimes get a random server in emergency - mode with a failed mount unit (ext4 file system), while the - corresponding file system is in fact correctly mounted. It happens - roughly once every 1000 reboots. + [Impact] + systemd mount units fail during boot, and the system boots into emergency mode + + [Test Plan] + This issue seems to happen randomly, and doesn't seem related to a specific mount unit. + + We've used a test script with good results during investigation to + reproduce similar mount failures in a running system, and have seen a + strong correlation between the script failures and the boot time mount + failures. + + [Where problems could occur] + The patches change the way systemd tracks and handles mount points in general, so potential regressions could affect other mount units. We should keep an eye out for any issues with mounting file systems, as well as rapid mount/unmount operations. Successful test runs with the reproducer script should increase reliability in having no new regressions. + + [Other Info] + This has been tackled upstream with several attempts, which have resulted in the final patch from 2022: + 01400460ae16 core/mount: adjust deserialized state based on /proc/self/mountinfo + + For Bionic, systemd requires several dependency patches as below: + 6a1d4d9fa6b9 core: properly reset all ExecStatus structures when entering a new unit cycle + 7eba1463dedc mount: flush out cycle state on DEAD→MOUNTED only, not the other way round + 350804867dbc mount: rescan /proc/self/mountinfo before processing waitid() results + 1d086a6e5972 mount: mark an existing "mounting" unit from /proc/self/mountinfo as "just_mounted" + + Additionally, the kernel also requires the following patches: + 28ca0d6d39ab list: introduce list_for_each_continue() + 9f6c61f96f2d proc/mounts: add cursor + + [Original Description] + In Ubuntu 18.04 at least, we sometimes get a random server in emergency mode with a failed mount unit (ext4 file system), while the corresponding file system is in fact correctly mounted. It happens roughly once every 1000 reboots. It seems to be related with this bug : https://github.com/systemd/systemd/issues/10872 Is it possible to apply the fix (https://github.com/systemd/systemd/commit/350804867dbcc9b7ccabae1187d730d37e2d8a21) in Ubuntu 18.04 ? Thanks in advance. ** Also affects: ubuntu-pro Importance: Undecided Status: New ** Also affects: ubuntu-pro/18.04 Importance: Undecided Status: New ** Changed in: ubuntu-pro/18.04 Status: New => In Progress ** Changed in: ubuntu-pro/18.04 Importance: Undecided => High ** Changed in: ubuntu-pro/18.04 Assignee: (unassigned) => Heitor Alves de Siqueira (halves) -- 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/1837227 Title: systemd mount units fail during boot, while file system is correctly mounted Status in systemd: New Status in Ubuntu Pro: In Progress Status in Ubuntu Pro 18.04 series: In Progress Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Won't Fix Status in systemd source package in Focal: In Progress Status in systemd source package in Jammy: Fix Released Bug description: [Impact] systemd mount units fail during boot, and the system boots into emergenc
[Touch-packages] [Bug 2024864] Re: systemd-networkd crashes with SIGSEGV on bionic
Thank you for the bug report, Thiago! I did a little bit of housekeeping
so that this LP accurately reflects this targeting Ubuntu Pro 18.04.
Could you please fill in the description according to the SRU template?
https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template
** Changed in: systemd
Status: New => Fix Released
** Changed in: systemd
Assignee: Tiago Pasqualini da Silva (tiago.pasqualini) => (unassigned)
** Changed in: ubuntu-pro/18.04
Assignee: (unassigned) => Tiago Pasqualini da Silva (tiago.pasqualini)
** Changed in: systemd (Ubuntu)
Status: New => Fix Released
** Changed in: ubuntu-pro/18.04
Status: New => In Progress
** Changed in: ubuntu-pro/18.04
Importance: Undecided => Medium
** Summary changed:
- systemd-networkd crashes with SIGSEGV on bionic
+ systemd-networkd crashes with SIGSEGV
--
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/2024864
Title:
systemd-networkd crashes with SIGSEGV
Status in systemd:
Fix Released
Status in Ubuntu Pro:
In Progress
Status in Ubuntu Pro 18.04 series:
In Progress
Status in systemd package in Ubuntu:
Fix Released
Bug description:
Customer reported that this issue happens randomly during their
automated regression runs. It's not consistent and hard to reproduce.
They have shared a coredump:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x555962aa1c34 in link_drop_foreign_config
(link=link@entry=0x555963583f30) at ../src/network/networkd-link.c:2741
2741 ../src/network/networkd-link.c: No such file or directory.
(gdb) bt
#0 0x555962aa1c34 in link_drop_foreign_config
(link=link@entry=0x555963583f30) at ../src/network/networkd-link.c:2741
#1 0x555962aa233d in link_carrier_lost.lto_priv.328 (link=, link=) at ../src/network/networkd-link.c:3462
#2 0x555962a8e9b2 in link_update (m=0x5559635702c0, link=)
at ../src/network/networkd-link.c:3698
#3 manager_rtnl_process_link (rtnl=, message=0x5559635702c0,
userdata=) at ../src/network/networkd-manager.c:713
#4 0x555962a48a16 in process_match (m=0x5559635702c0,
rtnl=0x55596355d990) at ../src/libsystemd/sd-netlink/sd-netlink.c:388
#5 process_running (ret=0x0, rtnl=0x55596355d990) at
../src/libsystemd/sd-netlink/sd-netlink.c:418
#6 sd_netlink_process (rtnl=0x55596355d990, ret=ret@entry=0x0) at
../src/libsystemd/sd-netlink/sd-netlink.c:452
#7 0x555962a48cb3 in time_callback (s=, usec=, userdata=) at ../src/libsystemd/sd-netlink/sd-netlink.c:759
#8 0x555962a4dbae in source_dispatch (s=s@entry=0x55596355dce0) at
../src/libsystemd/sd-event/sd-event.c:2311
#9 0x555962a4de2a in sd_event_dispatch (e=,
e@entry=0x55596355bf70) at ../src/libsystemd/sd-event/sd-event.c:2663
#10 0x555962a4dfb9 in sd_event_run (e=,
e@entry=0x55596355bf70, timeout=timeout@entry=18446744073709551615) at
../src/libsystemd/sd-event/sd-event.c:2723
#11 0x555962a4e1fb in sd_event_loop (e=) at
../src/libsystemd/sd-event/sd-event.c:2744
#12 0x555962a223d6 in main (argc=, argv=)
at ../src/network/networkd.c:158
The following patch fixes the issue:
https://github.com/systemd/systemd/commit/b1b0b42e48303134731e017a108c6c334ef5f4c8
I was able simulate it to happen on gdb, by breaking once the manager
is setup, getting the loopback device and running
link_drop_foreign_config on the loopback device:
(gdb) b src/network/networkd.c:150
Breakpoint 1 at 0x2f38f: file ../src/network/networkd.c, line 150.
(gdb) r
Starting program: /lib/systemd/systemd-networkd
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
eth0: IPv6 successfully enabled
eth0: Gained IPv6LL
Breakpoint 1, main (argc=, argv=) at
../src/network/networkd.c:152
152 log_info("Enumeration completed");
(gdb) p *m->links
$1 = {b = {hash_ops = 0x5578f230 , {indirect = {storage
= 0x2e, hash_key = "\200\376yUUU\000\000\001\000\000\000\000\000\000",
n_entries = 1434074992, n_buckets = 21845, idx_lowest_entry = 256,
_pad = "\000\000"}, direct = {
storage =
".\000\000\000\000\000\000\000\200\376yUUU\000\000\001\000\000\000\000\000\000\000p?zUUU\000\000\000\001\000\000\000\000"}},
type = HASHMAP_TYPE_PLAIN, has_indirect = false, n_direct_entries = 2,
from_pool = true}}
(gdb) set $mylink = (Link **) malloc(sizeof(Link *))
(gdb) call link_get(m, 1, $mylink)
$2 = 0
(gdb) p *$mylink
$3 = (Link *) 0x557a3f70
(gdb) p **$mylink
$4 = {manager = 0x55796940, n_ref = 2, ifindex = 1, master_ifindex = 0,
ifname = 0x557a0060 "lo", kind = 0x0, iftype = 772,
state_file = 0x5579c670 "/run/systemd/netif/links/1", mac =
{ether_addr_octet = "\000\000\000\000\000"}, ipv6ll_address = {__in6_u = {
__u6_addr8 = '\000' , __u6_addr16 = {0, 0, 0, 0, 0,
[Touch-packages] [Bug 2024864] Re: systemd-networkd crashes with SIGSEGV on bionic
** Tags added: se-sponsor-halves
--
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/2024864
Title:
systemd-networkd crashes with SIGSEGV on bionic
Status in systemd:
New
Status in Ubuntu Pro:
New
Status in Ubuntu Pro 18.04 series:
New
Status in systemd package in Ubuntu:
New
Bug description:
Customer reported that this issue happens randomly during their
automated regression runs. It's not consistent and hard to reproduce.
They have shared a coredump:
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x555962aa1c34 in link_drop_foreign_config
(link=link@entry=0x555963583f30) at ../src/network/networkd-link.c:2741
2741 ../src/network/networkd-link.c: No such file or directory.
(gdb) bt
#0 0x555962aa1c34 in link_drop_foreign_config
(link=link@entry=0x555963583f30) at ../src/network/networkd-link.c:2741
#1 0x555962aa233d in link_carrier_lost.lto_priv.328 (link=, link=) at ../src/network/networkd-link.c:3462
#2 0x555962a8e9b2 in link_update (m=0x5559635702c0, link=)
at ../src/network/networkd-link.c:3698
#3 manager_rtnl_process_link (rtnl=, message=0x5559635702c0,
userdata=) at ../src/network/networkd-manager.c:713
#4 0x555962a48a16 in process_match (m=0x5559635702c0,
rtnl=0x55596355d990) at ../src/libsystemd/sd-netlink/sd-netlink.c:388
#5 process_running (ret=0x0, rtnl=0x55596355d990) at
../src/libsystemd/sd-netlink/sd-netlink.c:418
#6 sd_netlink_process (rtnl=0x55596355d990, ret=ret@entry=0x0) at
../src/libsystemd/sd-netlink/sd-netlink.c:452
#7 0x555962a48cb3 in time_callback (s=, usec=, userdata=) at ../src/libsystemd/sd-netlink/sd-netlink.c:759
#8 0x555962a4dbae in source_dispatch (s=s@entry=0x55596355dce0) at
../src/libsystemd/sd-event/sd-event.c:2311
#9 0x555962a4de2a in sd_event_dispatch (e=,
e@entry=0x55596355bf70) at ../src/libsystemd/sd-event/sd-event.c:2663
#10 0x555962a4dfb9 in sd_event_run (e=,
e@entry=0x55596355bf70, timeout=timeout@entry=18446744073709551615) at
../src/libsystemd/sd-event/sd-event.c:2723
#11 0x555962a4e1fb in sd_event_loop (e=) at
../src/libsystemd/sd-event/sd-event.c:2744
#12 0x555962a223d6 in main (argc=, argv=)
at ../src/network/networkd.c:158
The following patch fixes the issue:
https://github.com/systemd/systemd/commit/b1b0b42e48303134731e017a108c6c334ef5f4c8
I was able simulate it to happen on gdb, by breaking once the manager
is setup, getting the loopback device and running
link_drop_foreign_config on the loopback device:
(gdb) b src/network/networkd.c:150
Breakpoint 1 at 0x2f38f: file ../src/network/networkd.c, line 150.
(gdb) r
Starting program: /lib/systemd/systemd-networkd
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
eth0: IPv6 successfully enabled
eth0: Gained IPv6LL
Breakpoint 1, main (argc=, argv=) at
../src/network/networkd.c:152
152 log_info("Enumeration completed");
(gdb) p *m->links
$1 = {b = {hash_ops = 0x5578f230 , {indirect = {storage
= 0x2e, hash_key = "\200\376yUUU\000\000\001\000\000\000\000\000\000",
n_entries = 1434074992, n_buckets = 21845, idx_lowest_entry = 256,
_pad = "\000\000"}, direct = {
storage =
".\000\000\000\000\000\000\000\200\376yUUU\000\000\001\000\000\000\000\000\000\000p?zUUU\000\000\000\001\000\000\000\000"}},
type = HASHMAP_TYPE_PLAIN, has_indirect = false, n_direct_entries = 2,
from_pool = true}}
(gdb) set $mylink = (Link **) malloc(sizeof(Link *))
(gdb) call link_get(m, 1, $mylink)
$2 = 0
(gdb) p *$mylink
$3 = (Link *) 0x557a3f70
(gdb) p **$mylink
$4 = {manager = 0x55796940, n_ref = 2, ifindex = 1, master_ifindex = 0,
ifname = 0x557a0060 "lo", kind = 0x0, iftype = 772,
state_file = 0x5579c670 "/run/systemd/netif/links/1", mac =
{ether_addr_octet = "\000\000\000\000\000"}, ipv6ll_address = {__in6_u = {
__u6_addr8 = '\000' , __u6_addr16 = {0, 0, 0, 0, 0,
0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, mtu = 65536, udev_device = 0x0,
flags = 65609, kernel_operstate = 0 '\000', network = 0x0, state =
LINK_STATE_UNMANAGED, operstate = LINK_OPERSTATE_CARRIER, address_messages = 0,
address_label_messages = 0, route_messages = 0,
routing_policy_rule_messages = 0, routing_policy_rule_remove_messages = 0,
enslaving = 0,
addresses = 0x0, addresses_foreign = 0x55796120, routes = 0x0,
routes_foreign = 0x55796180, addresses_configured = false,
addresses_ready = false, dhcp_client = 0x0, dhcp_lease = 0x0, lease_file =
0x5579c620 "/run/systemd/netif/leases/1", original_mtu = 0,
dhcp4_messages = 0, dhcp4_configured = false, dhcp6_configured = false,
ndisc_messages = 0, ndisc_configured = false, ipv4ll = 0x0,
ipv4ll_address = false, ipv4ll_route = false,
[Touch-packages] [Bug 1983100] Re: dotnet build intermittently crashes with segfault on Ubuntu 18.04
Thanks for the revised debdiff, Tom! I appreciate that you added a short
description of each patch to the bug, it's really helpful!
We'll need to adjust a few things before proceeding, a few comments
below.
On the debian changelog:
- Since we have many patch files, it would be good to pull the descriptive
entry to the top, and list the files underneath
- We should include the LP bug number in the new changelog entry. This should
be in the format "(LP: #1983100)", preferably at the end of your topmost entry
On the DEP-3 headers:
- let's point the Origin tags to the commit id of each change, so that a
reviewer will be able to find the original commits in a local repo (without
going through a github pull request), e.g.:
Origin: upstream, https://github.com/openssl/openssl/commit/56806f432b6c
- for the Bug-Ubuntu tag, we should use the short-link version:
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1983100
On the patches themselves:
I've noticed that patch 4/7 isn't from the same PR series as the rest (it's
from PR 7626 [0]), so we should correct the Origin header in that patch file.
PR 7626 also has another commit that doesn't seem to be included in the
debdiff, did you run tests to ensure it isn't needed for them to work properly?
[0] https://github.com/openssl/openssl/pull/7626
I'm also not fully convinced patch 7/7 is required for this SRU, as it's
specifically targeted to Windows systems. I don't think our builds
define _WIN32, so I'd imagine the patch would only introduce dead code.
Could we drop it from the next version?
Finally, I'd like to double check the patches that are focused on
shlibloadtest (patches 1, 3-7). I understand some of them aren't related
to the new NO_ATEXIT change, but are fixing the underlying test that's
used by that specific patch. Does this mean that shlibloadtest is
currently broken for bionic? Or are these patches needed for the
additional tests introduced by patch 5?
Ultimately, I wonder if it would be appropriate to e.g. spin the
shlibloadtest fixes into a separate LP bug, or if the NO_ATEXIT tests
will just outright break without them. Could you please confirm whether
this is the case?
Thanks again for all the work on this, Tom! Given we're touching a
critical component (openssl) of an LTS release that's soon to move out
of standard support, we'll have to be a bit more strict than usual and
this SRU is likely to receive extra attention, so thanks for being
understanding about it.
Cheers,
Heitor
** Changed in: openssl (Ubuntu Bionic)
Status: In Progress => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1983100
Title:
dotnet build intermittently crashes with segfault on Ubuntu 18.04
Status in openssl package in Ubuntu:
Fix Released
Status in openssl source package in Bionic:
Incomplete
Bug description:
[Impact]
Bionic's OpenSSL 1.1.1 package
(https://launchpad.net/ubuntu/bionic/+source/openssl) is the only
version of openssl 1.1.1 on any distro that we've encountered that
does not have support for the OPENSSL_NO_ATEXIT functionality from
1.1.1b (openssl/openssl@c2b3db2).
The threading model in .NET has the possibility that background
threads are still running when exit() is called, which can cause
SIGSEGV if a background thread interacts with OpenSSL after/while it
has unloaded. For that reason, we always initialize OpenSSL 1.1.1 with
the OPENSSL_NO_ATEXIT flag (which, of all the distros we run on only
has no effect on Bionic).
We feel that the stability of applications on Ubuntu 18.04 would be
improved if the functionality of OPENSSL_NO_ATEXIT was merged into the
bionic openssl 1.1.1 package, even if the constant isn't published
into the header for the dev package.
Context:
https://github.com/dotnet/runtime/issues/48411#issuecomment-1178405101
[Test Plan]
The described behavior can be reproduced by passing the
OPENSSL_NO_ATEXIT to the OPENSSL_init_ssl() call. The application will
terminate with a SEGFAULT. More concretely, a minimal reproducer is:
#include
#include
#include
#ifndef OPENSSL_INIT_NO_ATEXIT
#define OPENSSL_INIT_NO_ATEXIT 0x0008L
#endif
static void print_error_string()
{
printf("print_error_string:\n");
printf("ERR_reason_error_string(0) => %s\n", ERR_reason_error_string(0));
}
int main(int argc, char* argv[])
{
// register this handler first, so it runs last.
atexit(print_error_string);
OPENSSL_init_ssl(
OPENSSL_INIT_ADD_ALL_CIPHERS |
OPENSSL_INIT_ADD_ALL_DIGESTS |
OPENSSL_INIT_LOAD_CONFIG |
OPENSSL_INIT_NO_ATEXIT |
OPENSSL_INIT_LOAD_CRYPTO_STRINGS |
OPENSSL_INIT_LOAD_SSL_STRINGS,
NULL);
print_error_string();
return 0;
}
Building
$ sudo apt install libssl-dev
$ gcc
[Touch-packages] [Bug 1983100] Re: dotnet build intermittently crashes with segfault on Ubuntu 18.04
** Changed in: openssl (Ubuntu Bionic)
Status: Incomplete => In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1983100
Title:
dotnet build intermittently crashes with segfault on Ubuntu 18.04
Status in openssl package in Ubuntu:
Fix Released
Status in openssl source package in Bionic:
In Progress
Bug description:
[Impact]
Bionic's OpenSSL 1.1.1 package
(https://launchpad.net/ubuntu/bionic/+source/openssl) is the only
version of openssl 1.1.1 on any distro that we've encountered that
does not have support for the OPENSSL_NO_ATEXIT functionality from
1.1.1b (openssl/openssl@c2b3db2).
The threading model in .NET has the possibility that background
threads are still running when exit() is called, which can cause
SIGSEGV if a background thread interacts with OpenSSL after/while it
has unloaded. For that reason, we always initialize OpenSSL 1.1.1 with
the OPENSSL_NO_ATEXIT flag (which, of all the distros we run on only
has no effect on Bionic).
We feel that the stability of applications on Ubuntu 18.04 would be
improved if the functionality of OPENSSL_NO_ATEXIT was merged into the
bionic openssl 1.1.1 package, even if the constant isn't published
into the header for the dev package.
Context:
https://github.com/dotnet/runtime/issues/48411#issuecomment-1178405101
[Test Plan]
The described behavior can be reproduced by passing the
OPENSSL_NO_ATEXIT to the OPENSSL_init_ssl() call. The application will
terminate with a SEGFAULT. More concretely, a minimal reproducer is:
#include
#include
#include
#ifndef OPENSSL_INIT_NO_ATEXIT
#define OPENSSL_INIT_NO_ATEXIT 0x0008L
#endif
static void print_error_string()
{
printf("print_error_string:\n");
printf("ERR_reason_error_string(0) => %s\n", ERR_reason_error_string(0));
}
int main(int argc, char* argv[])
{
// register this handler first, so it runs last.
atexit(print_error_string);
OPENSSL_init_ssl(
OPENSSL_INIT_ADD_ALL_CIPHERS |
OPENSSL_INIT_ADD_ALL_DIGESTS |
OPENSSL_INIT_LOAD_CONFIG |
OPENSSL_INIT_NO_ATEXIT |
OPENSSL_INIT_LOAD_CRYPTO_STRINGS |
OPENSSL_INIT_LOAD_SSL_STRINGS,
NULL);
print_error_string();
return 0;
}
Building
$ sudo apt install libssl-dev
$ gcc test.c -lssl -lcrypto
$ ./a.out
print_error_string:
ERR_reason_error_string(0) => (null)
print_error_string:
Segmentation fault (core dumped)
[Other Info]
All of these patches are included in upstream release 1.1.1b
- lp1983100-0001-Fix-shlibloadtest-to-properly-execute-the-dso_ref-te.patch
Fixes the shlibloadtest that was updated as part of #0005
- lp1983100-0002-Implement-OPENSSL_INIT_NO_ATEXIT.patch
Patch adds the OPENSSL_INIT_NO_ATEXIT option
- lp1983100-0003-Don-t-link-shlibloadtest-against-libcrypto.patch
Additional fixes for shlibloadtest
- lp1983100-0004-Fix-rpath-related-Linux-test_shlibload-failure.patch
Additional fixes for shlibloadtest
- lp1983100-0005-Test-atexit-handlers.patch
Adds test for OPENSSL_INIT_NO_ATEXIT option and updates the shlibloadtest
- lp1983100-0006-Introduce-a-no-pinshared-option.patch
This patch includes tests to ensure that if OPENSSL_INIT_NO_ATEXIT is not
defined then the atexit() handler is run
- lp1983100-0007-Support-_onexit-in-preference-to-atexit-on-Windows.patch
This patch ensures that atexit() is only called when on non-Windows systems
as Windows uses _onexit() during library unloading
All seven patches are required to ensure the correct logic and
operation of the OPENSSL_INIT_NO_ATEXIT option.
[Where problems could occur]
The patches adds an option to the OPENSSL_init_crypto() function to
disable the default behavior of calling of a cleanup function on
application exit. The patch also includes a few bug fixes around
various initializations that were supposed to happen once when running
threaded but were not.
These changes have the potential for regressions and it is conceivable
that they lead to incorrect behavior. However, I have also backported
and included all new testing functions in the hope that the changed
behavior will get appropriate testing.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1983100/+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 2002043] Re: Python extension modules get built using wrong compiler flags with python2
** Tags added: se-sponsor-halves
--
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/2002043
Title:
Python extension modules get built using wrong compiler flags with
python2
Status in python2.7 package in Ubuntu:
In Progress
Status in python2.7 source package in Bionic:
In Progress
Status in python2.7 source package in Focal:
In Progress
Status in python2.7 source package in Jammy:
In Progress
Status in python2.7 source package in Kinetic:
In Progress
Status in python2.7 source package in Lunar:
In Progress
Bug description:
Compiling a Python extension using Python2 (Python 2.7.18) is making
use of wrong compiler flags, hence dropping required optimizations
when required. This is happening only when python2 is installed from
Ubuntu's repositories. By default, Python's distutils module uses
compiler and linker flags used to compile Python itself to be used to
compile extensions.
Steps to reproduce:
1) On Ubuntu 20.04, install python2 using apt package manager.
2) After successful installation, verify the CFLAGS variable from sysconfig
module. On my machine, the output is
Python 2.7.18 (default, Jul 1 2022, 12:27:04)
[GCC 9.4.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sysconfig
>>> sysconfig.get_config_var('CFLAGS')
'-fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes
-Wdate-time -D_FORTIFY_SOURCE=2 -g
-fdebug-prefix-map=/build/python2.7-vvQ8AI/python2.7-2.7.18=.
-fstack-protector-strong -Wformat -Werror=format-security '
3) Build a test extension module using python2 and verify the compilation
flags.
python2 setup.py build_ext --inplace
Output from below command is not matching with our expected above CFLAGS.
aarch64-linux-gnu-gcc -pthread -fno-strict-aliasing -Wdate-time
-D_FORTIFY_SOURCE=2 -g
-fdebug-prefix-map=/build/python2.7-vvQ8AI/python2.7-2.7.18=.
-fstack-protector-strong -Wformat -Werror=format-security -fPIC
-I/usr/include/python2.7 -c testmodule.c -o
build/temp.linux-aarch64-2.7/testmodule.o
On further investigation, it looks like Ubuntu's specific patch applied on
libpython2.7-stdlib package is altering the original upstream implementation of
distutils/sysconfig.py code.
Package - https://packages.ubuntu.com/focal/libpython2.7-stdlib
Patch -
http://archive.ubuntu.com/ubuntu/pool/universe/p/python2.7/python2.7_2.7.18-1~20.04.3.diff.gz
Below is the code block which is causing the issue, where the presence of
configure_cflags is modifying cflags. This code is result of ubuntu's patch and
doesn't come directly from upstream python implementation.
File - /usr/lib/python2.7/distutils/sysconfig.py
Part of code block:
elif configure_cflags:
cflags = ' '.join(str(x) for x in (basecflags, configure_cflags,
extra_cflags) if x)
ldshared = ldshared + ' ' + configure_cflags
I don't see problem on Python3 though we have extra code added from patch
there as well. Patch used on python3, is not modifying the cflags completely
and instead appending new flags to cflags.
On python3 (tested on Ubuntu 20.04)
File - /usr/lib/python3.8/distutils/sysconfig.py
Part of code block which doesn't alter cflags completely
elif configure_cflags:
cflags = cflags + ' ' + configure_cflags
ldshared = ldshared + ' ' + configure_cflags
Request to update the python2 patch to behave similar to what is been done on
python3.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/2002043/+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 1999104] Re: arm64: broken c++ exception handler support leads to std::terminate() being called and program abort
** Tags removed: sts-sponsor-halves -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libunwind in Ubuntu. https://bugs.launchpad.net/bugs/1999104 Title: arm64: broken c++ exception handler support leads to std::terminate() being called and program abort Status in libunwind package in Ubuntu: Fix Released Status in libunwind source package in Bionic: In Progress Status in libunwind source package in Focal: In Progress Bug description: [Impact] On architectures other than i386 and amd64, the C++ exception support in libunwind appears to be broken, always failing and calling std::terminate() which leads to the program aborting. (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0xf7c2daac in __GI_abort () at abort.c:79 #2 0xf7e21868 in __gnu_cxx::__verbose_terminate_handler() () from /lib/aarch64-linux-gnu/libstdc++.so.6 #3 0xf7e1f21c in ?? () from /lib/aarch64-linux-gnu/libstdc++.so.6 #4 0xf7e1f280 in std::terminate() () from /lib/aarch64-linux-gnu/libstdc++.so.6 #5 0xf7e1f5e0 in __cxa_rethrow () from /lib/aarch64-linux-gnu/libstdc++.so.6 #6 0xf7e21804 in __gnu_cxx::__verbose_terminate_handler() () from /lib/aarch64-linux-gnu/libstdc++.so.6 #7 0xf7e1f21c in ?? () from /lib/aarch64-linux-gnu/libstdc++.so.6 #8 0xf7e1f280 in std::terminate() () from /lib/aarch64-linux-gnu/libstdc++.so.6 #9 0xf7e1f574 in __cxa_throw () from /lib/aarch64-linux-gnu/libstdc++.so.6 #10 0xf7fb9f50 in function_throws_int () at lib.cpp:9 #11 0x0d54 in main (argc=1, argv=0xfab8) at main.cpp:9 Compiling libunwind with --enable-cxx-exceptions enabled leads to _Unwind_RaiseException being called during __cxa_throw(), which fails to find a handler, and the generic std::terminate() is called instead, aborting the program. On i386 and amd64 this doesn't seem to be the case, and the libunwind handlers seem to be present. To fix, we only enable the configure option --enable-cxx-exceptions on i386 and amd64 only, in debian/rules. This lets other architectures fall back to the symbols provided by libgcc_s, which implementation works correctly. [Testcase] Ali Sadi has provided a reproducer program. Start an arm64 instance, for example, a c6g.medium instance on AWS, with either Bionic or Focal. $ wget https://bugs.launchpad.net/ubuntu/+source/libunwind/+bug/1999104/+attachment/5635122/+files/libunwind.tar.gz $ sudo apt install -y build-essential libunwind-dev $ tar xvf libunwind.tar.gz && cd test $ make all There are two executable, main and main_unwind. main is not linked to libunwind, and main_unwind is linked to libunwind. $ ./main int throws lib int caught main $ ./main_unwind terminate called after throwing an instance of 'int' terminate called recursively Aborted (core dumped) If you install the test package available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/sf350246-test $ make clean $ sudo apt install -y libunwind-dev $ make all $ ./main int throws lib int caught main $ ./main_unwind int throws lib int caught main The exception is caught as expected the program does not abort. [Where problems could occur] For architectures other than i386 and amd64, we are changing from libunwind provided exception handlers for __cxa_throw(), and using those provided by libgcc_s instead. There are a few reverse dependencies for libunwind-dev and libunwind8, which need to be considered: $ apt rdepends libunwind-dev libunwind-dev Reverse Depends: Depends: libunwind-setjmp0-dev (= 1.2.1-9build1) Depends: libefl-all-dev t$ apt rdepends libunwind-dev8 libunwind8 Reverse Depends: Depends: libunwind-dev (= 1.2.1-9build1) Depends: xvfb Depends: xnest Depends: xdmx Depends: xwayland Depends: xserver-xorg-core Depends: xserver-xephyr Depends: linux-tools-5.4.0-* Depends: linux-raspi-tools-* Depends: linux-raspi2-tools-5.4.0-* Depends: linux-raspi2-5.4-tools-5.4.0-* Depends: linux-oracle-5.15-tools-5.15.0-* Depends: linux-lowlatency-hwe-5.15-tools-5.15.0-* Depends: linux-hwe-5.8-tools-5.8.0-* Depends: linux-hwe-5.15-tools-5.15.0-* Depends: linux-gke-tools-5.4.0-* Depends: linux-gke-5.15-tools-5.15.0-* Depends: linux-gcp-tools-5.4.0-* Depends: linux-gcp-5.15-tools-5.15.0-* Depends: linux-azure-tools-5.4.0-* Depends: linux-azure-5.15-tools-5.15.0-* Depends: linux-aws-tools-5.4.0-* Depends: linux-aws-5.8-tools-5.8.0-* Depends: linux-aws-5.15-tools-5.15.0-* Depends: xvfb Depends: xnest Depends: xdmx Depends: trafficserver Depends: tilix Depends: tigervnc-standalone-server Depends: tarantool
[Touch-packages] [Bug 1999104] Re: arm64: broken c++ exception handler support leads to std::terminate() being called and program abort
** Tags removed: sts-sponsor ** Tags added: sts-sponsor-halves -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libunwind in Ubuntu. https://bugs.launchpad.net/bugs/1999104 Title: arm64: broken c++ exception handler support leads to std::terminate() being called and program abort Status in libunwind package in Ubuntu: Fix Released Status in libunwind source package in Bionic: In Progress Status in libunwind source package in Focal: In Progress Bug description: [Impact] On architectures other than i386 and amd64, the C++ exception support in libunwind appears to be broken, always failing and calling std::terminate() which leads to the program aborting. (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0xf7c2daac in __GI_abort () at abort.c:79 #2 0xf7e21868 in __gnu_cxx::__verbose_terminate_handler() () from /lib/aarch64-linux-gnu/libstdc++.so.6 #3 0xf7e1f21c in ?? () from /lib/aarch64-linux-gnu/libstdc++.so.6 #4 0xf7e1f280 in std::terminate() () from /lib/aarch64-linux-gnu/libstdc++.so.6 #5 0xf7e1f5e0 in __cxa_rethrow () from /lib/aarch64-linux-gnu/libstdc++.so.6 #6 0xf7e21804 in __gnu_cxx::__verbose_terminate_handler() () from /lib/aarch64-linux-gnu/libstdc++.so.6 #7 0xf7e1f21c in ?? () from /lib/aarch64-linux-gnu/libstdc++.so.6 #8 0xf7e1f280 in std::terminate() () from /lib/aarch64-linux-gnu/libstdc++.so.6 #9 0xf7e1f574 in __cxa_throw () from /lib/aarch64-linux-gnu/libstdc++.so.6 #10 0xf7fb9f50 in function_throws_int () at lib.cpp:9 #11 0x0d54 in main (argc=1, argv=0xfab8) at main.cpp:9 Compiling libunwind with --enable-cxx-exceptions enabled leads to _Unwind_RaiseException being called during __cxa_throw(), which fails to find a handler, and the generic std::terminate() is called instead, aborting the program. On i386 and amd64 this doesn't seem to be the case, and the libunwind handlers seem to be present. To fix, we only enable the configure option --enable-cxx-exceptions on i386 and amd64 only, in debian/rules. This lets other architectures fall back to the symbols provided by libgcc_s, which implementation works correctly. [Testcase] Ali Sadi has provided a reproducer program. Start an arm64 instance, for example, a c6g.medium instance on AWS, with either Bionic or Focal. $ wget https://bugs.launchpad.net/ubuntu/+source/libunwind/+bug/1999104/+attachment/5635122/+files/libunwind.tar.gz $ sudo apt install -y build-essential libunwind-dev $ tar xvf libunwind.tar.gz && cd test $ make all There are two executable, main and main_unwind. main is not linked to libunwind, and main_unwind is linked to libunwind. $ ./main int throws lib int caught main $ ./main_unwind terminate called after throwing an instance of 'int' terminate called recursively Aborted (core dumped) If you install the test package available in the following ppa: https://launchpad.net/~mruffell/+archive/ubuntu/sf350246-test $ make clean $ sudo apt install -y libunwind-dev $ make all $ ./main int throws lib int caught main $ ./main_unwind int throws lib int caught main The exception is caught as expected the program does not abort. [Where problems could occur] For architectures other than i386 and amd64, we are changing from libunwind provided exception handlers for __cxa_throw(), and using those provided by libgcc_s instead. There are a few reverse dependencies for libunwind-dev and libunwind8, which need to be considered: $ apt rdepends libunwind-dev libunwind-dev Reverse Depends: Depends: libunwind-setjmp0-dev (= 1.2.1-9build1) Depends: libefl-all-dev t$ apt rdepends libunwind-dev8 libunwind8 Reverse Depends: Depends: libunwind-dev (= 1.2.1-9build1) Depends: xvfb Depends: xnest Depends: xdmx Depends: xwayland Depends: xserver-xorg-core Depends: xserver-xephyr Depends: linux-tools-5.4.0-* Depends: linux-raspi-tools-* Depends: linux-raspi2-tools-5.4.0-* Depends: linux-raspi2-5.4-tools-5.4.0-* Depends: linux-oracle-5.15-tools-5.15.0-* Depends: linux-lowlatency-hwe-5.15-tools-5.15.0-* Depends: linux-hwe-5.8-tools-5.8.0-* Depends: linux-hwe-5.15-tools-5.15.0-* Depends: linux-gke-tools-5.4.0-* Depends: linux-gke-5.15-tools-5.15.0-* Depends: linux-gcp-tools-5.4.0-* Depends: linux-gcp-5.15-tools-5.15.0-* Depends: linux-azure-tools-5.4.0-* Depends: linux-azure-5.15-tools-5.15.0-* Depends: linux-aws-tools-5.4.0-* Depends: linux-aws-5.8-tools-5.8.0-* Depends: linux-aws-5.15-tools-5.15.0-* Depends: xvfb Depends: xnest Depends: xdmx Depends: trafficserver Depends: tilix Depends: tigervnc-standalone-server
[Touch-packages] [Bug 1972029] Re: dhclient overriding stub-resolv.conf file on Jammy
** Tags removed: sts sts-sponsor-halves -- 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/1972029 Title: dhclient overriding stub-resolv.conf file on Jammy Status in isc-dhcp package in Ubuntu: Fix Released Status in isc-dhcp source package in Jammy: In Progress Status in isc-dhcp source package in Kinetic: Fix Released Bug description: [Issue] On Jammy, the stub-resolv.conf file on /run/systemd/resolve gets overwritten if dhclient is executed. While debugging this, I found the reference on LP#1889068 [0] of the move of `resolved` hook from dhclient-enter-hooks.d/ to dhclient-exit- hooks.d/, and this new hook [2] has no reference of make_resolv_conf() being called. [Reproducer] - I used a cloud-image based Jammy installation (uvt-kvm). Once in: $ cat /run/system/resolve/stub-resolv.conf And one will see: nameserver 127.0.0.53 options edns0 trust-ad search . Then: $ sudo dhclient $ cat /run/system/resolve/stub-resolv.conf You'll see the definition of the nameserver(s) in, and the stub IP address no longer there. To revert this, a `systemctl restart systemd-resolved` is needed. [Impact] This is an improper way to keep nameserver(s) in *resolv* files; the override of the file should never happen in these circumstances. [Extra] - As a minor test, I copied over the dhclient-enter-hooks.d/resolved file from a Focal installation to a Jammy one, and the problem _does not happen_ when such hook is in place. [ . . . ] Let me know if further clarification is needed to proceed. Thank you. BR, pprincipeza [0] https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1889068 [1] https://paste.ubuntu.com/p/bvqPZXZZ8w/ [2] https://paste.ubuntu.com/p/YQdG6z4WS7/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1972029/+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 1983100] Re: dotnet build intermittently crashes with segfault on Ubuntu 18.04
Hi Nicolas,
Thank you for the patches! I've taken a quick look at the contents, in
hopes of giving you some more feedback for the v2 (in addition to
Mauricio's already suggested changes).
Going through the list, I noticed that there are quite a few patches for a
single bug fix, and that some of them have a substantial diffstat. There's an
impression that these patches are more targeted towards including new features
rather than fixing specific bugs, given their complexity and level of
changes. From the description, I understand most of these changes are probably
required in order to fix faulty behavior, so we should try to get more
information about each patch and what they intend to fix.
Without further context, it's not straightforward to understand why some of the
patches are necessary. As an example, patch 6/7 seems to introduce a new option
related to memory pinning, and patch 7/7 seems to be a Windows-specific change.
It would be very helpful if you could describe your reasoning for each patch in
more detail (e.g. with the "[Other Info]" section of the SRU Bug
Template), something like below:
- patch 0001 is a hard dependency of OPENSSL_INIT_NO_ATEXIT
- patch 0002 implements OPENSSL_INIT_NO_ATEXIT
- patch 0003-0004 add OPENSSL_INIT_NO_ATEXIT to the openssl test suite
...
This would make it easier to understand why each patch included, and help
deciding on whether they would be appropriate for the SRU scenario.
In addition to that, it would be great to have more concrete examples in the
"[Where problems could occur]" section. You mentioned that the patches could
lead to incorrect behavior, so having examples of that would be helpful in
spotting them once the changes go through. For instance, are these problems
expected to show up in openssl itself? Would an external library or program
using openssl start exhibiting different behavior or crashes due to these
changes?
I don't want to come off as excessive, but given that openssl is a
somewhat 'hot' package with potentially big impact on systems, having
good justification and proper context on the patches would be very
beneficial when evaluating the changes.
Thanks again for the help on fixing this bug, and let us know if you
have any questions!
** Changed in: openssl (Ubuntu Bionic)
Status: New => Incomplete
** Changed in: openssl (Ubuntu)
Status: New => Fix Released
** Changed in: openssl (Ubuntu Bionic)
Importance: Undecided => Medium
** Changed in: openssl (Ubuntu Bionic)
Assignee: (unassigned) => Nicolas Bock (nicolasbock)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1983100
Title:
dotnet build intermittently crashes with segfault on Ubuntu 18.04
Status in openssl package in Ubuntu:
Fix Released
Status in openssl source package in Bionic:
Incomplete
Bug description:
[Impact]
Bionic's OpenSSL 1.1.1 package
(https://launchpad.net/ubuntu/bionic/+source/openssl) is the only
version of openssl 1.1.1 on any distro that we've encountered that
does not have support for the OPENSSL_NO_ATEXIT functionality from
1.1.1b (openssl/openssl@c2b3db2).
The threading model in .NET has the possibility that background
threads are still running when exit() is called, which can cause
SIGSEGV if a background thread interacts with OpenSSL after/while it
has unloaded. For that reason, we always initialize OpenSSL 1.1.1 with
the OPENSSL_NO_ATEXIT flag (which, of all the distros we run on only
has no effect on Bionic).
We feel that the stability of applications on Ubuntu 18.04 would be
improved if the functionality of OPENSSL_NO_ATEXIT was merged into the
bionic openssl 1.1.1 package, even if the constant isn't published
into the header for the dev package.
Context:
https://github.com/dotnet/runtime/issues/48411#issuecomment-1178405101
[Test Plan]
The described behavior can be reproduced by passing the
OPENSSL_NO_ATEXIT to the OPENSSL_init_ssl() call. The application will
terminate with a SEGFAULT. More concretely, a minimal reproducer is:
#include
#include
#include
#ifndef OPENSSL_INIT_NO_ATEXIT
#define OPENSSL_INIT_NO_ATEXIT 0x0008L
#endif
static void print_error_string()
{
printf("print_error_string:\n");
printf("ERR_reason_error_string(0) => %s\n", ERR_reason_error_string(0));
}
int main(int argc, char* argv[])
{
// register this handler first, so it runs last.
atexit(print_error_string);
OPENSSL_init_ssl(
OPENSSL_INIT_ADD_ALL_CIPHERS |
OPENSSL_INIT_ADD_ALL_DIGESTS |
OPENSSL_INIT_LOAD_CONFIG |
OPENSSL_INIT_NO_ATEXIT |
OPENSSL_INIT_LOAD_CRYPTO_STRINGS |
OPENSSL_INIT_LOAD_SSL_STRINGS,
NULL);
print_error_string();
return 0;
}
Building
$ sudo apt install libssl-dev
$
[Touch-packages] [Bug 1983100] Re: dotnet build intermittently crashes with segfault on Ubuntu 18.04
** Tags added: se-sponsor-halves
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1983100
Title:
dotnet build intermittently crashes with segfault on Ubuntu 18.04
Status in openssl package in Ubuntu:
New
Status in openssl source package in Bionic:
New
Bug description:
[Impact]
Bionic's OpenSSL 1.1.1 package
(https://launchpad.net/ubuntu/bionic/+source/openssl) is the only
version of openssl 1.1.1 on any distro that we've encountered that
does not have support for the OPENSSL_NO_ATEXIT functionality from
1.1.1b (openssl/openssl@c2b3db2).
The threading model in .NET has the possibility that background
threads are still running when exit() is called, which can cause
SIGSEGV if a background thread interacts with OpenSSL after/while it
has unloaded. For that reason, we always initialize OpenSSL 1.1.1 with
the OPENSSL_NO_ATEXIT flag (which, of all the distros we run on only
has no effect on Bionic).
We feel that the stability of applications on Ubuntu 18.04 would be
improved if the functionality of OPENSSL_NO_ATEXIT was merged into the
bionic openssl 1.1.1 package, even if the constant isn't published
into the header for the dev package.
Context:
https://github.com/dotnet/runtime/issues/48411#issuecomment-1178405101
[Test Plan]
The described behavior can be reproduced by passing the
OPENSSL_NO_ATEXIT to the OPENSSL_init_ssl() call. The application will
terminate with a SEGFAULT. More concretely, a minimal reproducer is:
#include
#include
#include
#ifndef OPENSSL_INIT_NO_ATEXIT
#define OPENSSL_INIT_NO_ATEXIT 0x0008L
#endif
static void print_error_string()
{
printf("print_error_string:\n");
printf("ERR_reason_error_string(0) => %s\n", ERR_reason_error_string(0));
}
int main(int argc, char* argv[])
{
// register this handler first, so it runs last.
atexit(print_error_string);
OPENSSL_init_ssl(
OPENSSL_INIT_ADD_ALL_CIPHERS |
OPENSSL_INIT_ADD_ALL_DIGESTS |
OPENSSL_INIT_LOAD_CONFIG |
OPENSSL_INIT_NO_ATEXIT |
OPENSSL_INIT_LOAD_CRYPTO_STRINGS |
OPENSSL_INIT_LOAD_SSL_STRINGS,
NULL);
print_error_string();
return 0;
}
Building
$ sudo apt install libssl-dev
$ gcc test.c -lssl -lcrypto
$ ./a.out
print_error_string:
ERR_reason_error_string(0) => (null)
print_error_string:
Segmentation fault (core dumped)
[Where problems could occur]
The patches adds an option to the OPENSSL_init_crypto() function to
disable the default behavior of calling of a cleanup function on
application exit. The patch also includes a few bug fixes around
various initializations that were supposed to happen once when running
threaded but were not.
These changes have the potential for regressions and it is conceivable
that they lead to incorrect behavior. However, I have also backported
and included all new testing functions in the hope that the changed
behavior will get appropriate testing.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1983100/+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 1972029] Re: dhclient overriding stub-resolv.conf file on Jammy
** Tags added: sts sts-sponsor-halves -- 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/1972029 Title: dhclient overriding stub-resolv.conf file on Jammy Status in isc-dhcp package in Ubuntu: New Bug description: [Issue] On Jammy, the stub-resolv.conf file on /run/systemd/resolve gets overwritten if dhclient is executed. While debugging this, I found the reference on LP#1889068 [0] of the move of `resolved` hook from dhclient-enter-hooks.d/ to dhclient-exit- hooks.d/, and this new hook [2] has no reference of make_resolv_conf() being called. [Reproducer] - I used a cloud-image based Jammy installation (uvt-kvm). Once in: $ cat /run/system/resolve/stub-resolv.conf And one will see: nameserver 127.0.0.53 options edns0 trust-ad search . Then: $ sudo dhclient $ cat /run/system/resolve/stub-resolv.conf You'll see the definition of the nameserver(s) in, and the stub IP address no longer there. To revert this, a `systemctl restart systemd-resolved` is needed. [Impact] This is an improper way to keep nameserver(s) in *resolv* files; the override of the file should never happen in these circumstances. [Extra] - As a minor test, I copied over the dhclient-enter-hooks.d/resolved file from a Focal installation to a Jammy one, and the problem _does not happen_ when such hook is in place. [ . . . ] Let me know if further clarification is needed to proceed. Thank you. BR, pprincipeza [0] https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1889068 [1] https://paste.ubuntu.com/p/bvqPZXZZ8w/ [2] https://paste.ubuntu.com/p/YQdG6z4WS7/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1972029/+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 1863930] Re: SSH 1.99 clients fail to connect to openssh-server 1:7.6p1-4ubuntu0.3
Validated according to test case from description: root@bionic-ssh:~# python3 test_bug_1863930.py localhost Server is patched root@bionic-ssh:~# dpkg -l | grep openssh ii openssh-client 1:7.6p1-4ubuntu0.6 amd64 secure shell (SSH) client, for secure access to remote machines ii openssh-server 1:7.6p1-4ubuntu0.6 amd64 secure shell (SSH) server, for secure access from remote machines ii openssh-sftp-server 1:7.6p1-4ubuntu0.6 amd64 secure shell (SSH) sftp server module, for SFTP access from remote machines Given we have an ACK from both Server and Security and this is affecting multiple users, I'll remove the blocked tag as well. ** Tags removed: block-proposed-bionic verification-needed verification-needed-bionic ** Tags added: verification-done verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1863930 Title: SSH 1.99 clients fail to connect to openssh-server 1:7.6p1-4ubuntu0.3 Status in openssh package in Ubuntu: Fix Released Status in openssh source package in Bionic: Fix Committed Bug description: [Impact] * The version check in ssh was broken no more following RFC 4253 and thereby denying some clients that it shouldn't. https://datatracker.ietf.org/doc/html/rfc4253#section-5.1 * It is intended for clients reporting SSH-1.99 to be treated as if they were advertising SSH-2.0, but with some backwards compatibility. * Upstream fixed that, and this request is to back-port the changes into 18.04 Bionic. * In practice this is affecting clients using the SolarWinds monitoring agent. Solarwinds SSH client advertises SSH-1.99 and Ubuntu 18.04 openssh-server is refusing the connection. * This results in the following error in the auth.log, and a failed connection from the agent. Protocol major versions differ for port : SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 vs. SSH-1.99-WeOnlyDo.Net * More information from SolarWinds at the link below. They call out 18.04 as affected and recommend upgrading OpenSSH-server to 7.7 or greater. https://support.solarwinds.com/SuccessCenter/s/article/SAM-s-Linux- Unix-Script-monitor-fails-to-connect-on-a-server-running- OpenSSH-7-6?language=en_US [Test Case] # Prep * configure the ssh server to generally work # Testcase $ wget https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1863930/+attachment/5332797/+files/test_bug_1863930.py $ apt install python3-paramiko $ python3 test_bug_1863930.py localhost (or whatever your host is) Will report "Server is not patched." or "Server is patched. * for an extra regression check it might be worth to do some "normal" ssh connections as well [Regression Potential] * The change is very small and reviewable as well as being upstream and in all Ubuntu releases >=Cosmic for a while now so it seems safe. If anything the kind of regression to expect is that some former (wrong) connection denials will then succeed. I can only think of that being an issue in test suites but not in the real world. [Other Info] * n/a -- SSHD closes the connection and logs the error message below when a client presents a protoversion of "1.99": Protocol major versions differ for X.X.X.X port X: SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 vs. SSH-1.99-XXX RFC 4253 only states that clients should treat a server's protoversion of "1.99" as equivalent to "2.0"; however, some backward-compatible clients send a protoversion of "1.99" and expect the server to treat it as "2.0". This regression was introduced in openssh-portable 7.6p1 from commit 97f4d3083; fixes were implemented in commits 9e9c4a7e5 and c9c1bba06. I've attached a patch with both of those fixes. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1863930/+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 1863930] Re: SSH 1.99 clients fail to connect to openssh-server 1:7.6p1-4ubuntu0.3
** Changed in: openssh (Ubuntu Bionic) Status: Incomplete => In Progress ** Tags added: sts sts-sponsor-halves -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1863930 Title: SSH 1.99 clients fail to connect to openssh-server 1:7.6p1-4ubuntu0.3 Status in openssh package in Ubuntu: Fix Released Status in openssh source package in Bionic: In Progress Bug description: [Impact] * The version check in ssh was broken no more following RFC 4253 and thereby denying some clients that it shouldn't. https://datatracker.ietf.org/doc/html/rfc4253#section-5.1 * It is intended for clients reporting SSH-1.99 to be treated as if they were advertising SSH-2.0, but with some backwards compatibility. * Upstream fixed that, and this request is to back-port the changes into 18.04 Bionic. * In practice this is affecting clients using the SolarWinds monitoring agent. Solarwinds SSH client advertises SSH-1.99 and Ubuntu 18.04 openssh-server is refusing the connection. * This results in the following error in the auth.log, and a failed connection from the agent. Protocol major versions differ for port : SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 vs. SSH-1.99-WeOnlyDo.Net * More information from SolarWinds at the link below. They call out 18.04 as affected and recommend upgrading OpenSSH-server to 7.7 or greater. https://support.solarwinds.com/SuccessCenter/s/article/SAM-s-Linux- Unix-Script-monitor-fails-to-connect-on-a-server-running- OpenSSH-7-6?language=en_US [Test Case] # Prep * configure the ssh server to generally work # Testcase $ wget https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1863930/+attachment/5332797/+files/test_bug_1863930.py $ apt install python3-paramiko $ python3 test_bug_1863930.py localhost (or whatever your host is) Will report "Server is not patched." or "Server is patched. * for an extra regression check it might be worth to do some "normal" ssh connections as well [Regression Potential] * The change is very small and reviewable as well as being upstream and in all Ubuntu releases >=Cosmic for a while now so it seems safe. If anything the kind of regression to expect is that some former (wrong) connection denials will then succeed. I can only think of that being an issue in test suites but not in the real world. [Other Info] * n/a -- SSHD closes the connection and logs the error message below when a client presents a protoversion of "1.99": Protocol major versions differ for X.X.X.X port X: SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 vs. SSH-1.99-XXX RFC 4253 only states that clients should treat a server's protoversion of "1.99" as equivalent to "2.0"; however, some backward-compatible clients send a protoversion of "1.99" and expect the server to treat it as "2.0". This regression was introduced in openssh-portable 7.6p1 from commit 97f4d3083; fixes were implemented in commits 9e9c4a7e5 and c9c1bba06. I've attached a patch with both of those fixes. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1863930/+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 1863930] Re: SSH 1.99 clients fail to connect to openssh-server 1:7.6p1-4ubuntu0.3
** Changed in: openssh (Ubuntu Bionic) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: openssh (Ubuntu Bionic) Importance: Low => High ** Changed in: openssh (Ubuntu Bionic) Importance: High => Medium -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1863930 Title: SSH 1.99 clients fail to connect to openssh-server 1:7.6p1-4ubuntu0.3 Status in openssh package in Ubuntu: Fix Released Status in openssh source package in Bionic: Incomplete Bug description: [Impact] * The version check in ssh was broken no more following RFC 4253 and thereby denying some clients that it shouldn't. https://datatracker.ietf.org/doc/html/rfc4253#section-5.1 * It is intended for clients reporting SSH-1.99 to be treated as if they were advertising SSH-2.0, but with some backwards compatibility. * Upstream fixed that, and this request is to back-port the changes into 18.04 Bionic. * In practice this is affecting clients using the SolarWinds monitoring agent. Solarwinds SSH client advertises SSH-1.99 and Ubuntu 18.04 openssh-server is refusing the connection. * This results in the following error in the auth.log, and a failed connection from the agent. Protocol major versions differ for port : SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 vs. SSH-1.99-WeOnlyDo.Net * More information from SolarWinds at the link below. They call out 18.04 as affected and recommend upgrading OpenSSH-server to 7.7 or greater. https://support.solarwinds.com/SuccessCenter/s/article/SAM-s-Linux- Unix-Script-monitor-fails-to-connect-on-a-server-running- OpenSSH-7-6?language=en_US [Test Case] # Prep * configure the ssh server to generally work # Testcase $ wget https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1863930/+attachment/5332797/+files/test_bug_1863930.py $ apt install python3-paramiko $ python3 test_bug_1863930.py localhost (or whatever your host is) Will report "Server is not patched." or "Server is patched. * for an extra regression check it might be worth to do some "normal" ssh connections as well [Regression Potential] * The change is very small and reviewable as well as being upstream and in all Ubuntu releases >=Cosmic for a while now so it seems safe. If anything the kind of regression to expect is that some former (wrong) connection denials will then succeed. I can only think of that being an issue in test suites but not in the real world. [Other Info] * n/a -- SSHD closes the connection and logs the error message below when a client presents a protoversion of "1.99": Protocol major versions differ for X.X.X.X port X: SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 vs. SSH-1.99-XXX RFC 4253 only states that clients should treat a server's protoversion of "1.99" as equivalent to "2.0"; however, some backward-compatible clients send a protoversion of "1.99" and expect the server to treat it as "2.0". This regression was introduced in openssh-portable 7.6p1 from commit 97f4d3083; fixes were implemented in commits 9e9c4a7e5 and c9c1bba06. I've attached a patch with both of those fixes. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1863930/+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 1920047] Re: sanlock global lock creation fail
We've determined this to be due to using disks with mixed sector sizes (i.e. different physical and logical sector sizes). The mentioned patch [0] enables lvmlockd to create shared leases in mixed sector sized disks, but additional support is needed in sanlock for these to work correctly. The required sanlock patches are: * d5e4def0d087 - sanlock: add flags to specify sector size [1] * 445e86700fa3 - configurable sector size and align size [2] If we don't have these additional sanlock patches, sanlock isn't able to find the written leases due to alignment issues and ultimately those are handled as invalid. Unfortunately, both sanlock patches are extensive and change a lot of low-level internal structures, so providing them as SRU updates would be prone to backporting errors and regressions. Since both lvm2 and sanlock are working as expected with non-mixed sector sizes, and the current versions actively prevent leases to be written to mixed sector disks, we can consider that things are working correctly. Support for mixed sector sizes should be considered a "feature" instead, which is available starting with the versions below: - lvm2: 2.03.10 - sanlock: 3.8.0 These versions are available in Ubuntu releases starting with Hirsute, and have been provided as backports in focal-backports and groovy- backports. Please refer to bug #1929432 and bug #1928708 for further details on the -backports versions. [0] https://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=2d1fe38d84d4 [1] https://pagure.io/sanlock/c/d5e4def0d087 [2] https://pagure.io/sanlock/c/445e86700fa3 ** Changed in: lvm2 (Ubuntu Focal) Status: Confirmed => Won't Fix ** Changed in: lvm2 (Ubuntu Groovy) Status: Confirmed => Won't Fix -- 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/1920047 Title: sanlock global lock creation fail Status in lvm2 package in Ubuntu: Fix Released Status in lvm2 source package in Focal: Won't Fix Status in lvm2 source package in Groovy: Won't Fix Bug description: Hello, Running Ubuntu server 20.04, I cannot create a shared VG using sanlock : # vgcreate --shared foo /dev/mapper/vol Enabling sanlock global lock Skipping global lock: lockspace not found or started Logical volume "lvmlock" created. VG foo init failed: -28 Failed to initialize lock args for lock type sanlock Volume group "foo" successfully removed Messages in /var/log/syslog lvmlockd[446807]: 1616089866 WARNING: mixed block sizes physical 4096 logical 512 (using 4096) for /dev/mapper/foo-lvmlock lvmlockd[446807]: 1616089866 S lvm_foo init_vg_san write_resource gl error -28 /dev/mapper/foo-lvmlock # lsb_release -rd Description:Ubuntu 20.04.2 LTS Release:20.04 # dpkg -l | grep lvm ii liblvm2cmd2.03:amd64 2.03.07-1ubuntu1 amd64LVM2 command library ii lvm2 2.03.07-1ubuntu1 amd64Linux Logical Volume Manager ii lvm2-lockd 2.03.07-1ubuntu1 amd64LVM locking daemon A similar bug report from RHEL8 : https://bugzilla.redhat.com/show_bug.cgi?id=1833837 Bug has been fixed upstream : https://sourceware.org/git/?p=lvm2.git;a=commit;h=2d1fe38d84d499011d13ae1ea11535398528fc87 It seems to be included in version 2.03.10 : https://sourceware.org/git/?p=lvm2.git;a=shortlog;h=refs/tags/v2_03_10 How can we get this patch included in Ubuntu 20.04 ? King Regards, Charles To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1920047/+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 1920047] Re: sanlock global lock creation fail
** Changed in: lvm2 (Ubuntu) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: lvm2 (Ubuntu) Importance: Undecided => High ** Changed in: lvm2 (Ubuntu) Status: New => Fix Released ** Also affects: lvm2 (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: lvm2 (Ubuntu Groovy) Importance: Undecided Status: New ** Changed in: lvm2 (Ubuntu Focal) Status: New => Confirmed ** Changed in: lvm2 (Ubuntu Groovy) Status: New => Confirmed ** Changed in: lvm2 (Ubuntu Focal) Importance: Undecided => High ** Changed in: lvm2 (Ubuntu Focal) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: lvm2 (Ubuntu Groovy) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: lvm2 (Ubuntu Groovy) Importance: Undecided => High -- 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/1920047 Title: sanlock global lock creation fail Status in lvm2 package in Ubuntu: Fix Released Status in lvm2 source package in Focal: Confirmed Status in lvm2 source package in Groovy: Confirmed Bug description: Hello, Running Ubuntu server 20.04, I cannot create a shared VG using sanlock : # vgcreate --shared foo /dev/mapper/vol Enabling sanlock global lock Skipping global lock: lockspace not found or started Logical volume "lvmlock" created. VG foo init failed: -28 Failed to initialize lock args for lock type sanlock Volume group "foo" successfully removed Messages in /var/log/syslog lvmlockd[446807]: 1616089866 WARNING: mixed block sizes physical 4096 logical 512 (using 4096) for /dev/mapper/foo-lvmlock lvmlockd[446807]: 1616089866 S lvm_foo init_vg_san write_resource gl error -28 /dev/mapper/foo-lvmlock # lsb_release -rd Description:Ubuntu 20.04.2 LTS Release:20.04 # dpkg -l | grep lvm ii liblvm2cmd2.03:amd64 2.03.07-1ubuntu1 amd64LVM2 command library ii lvm2 2.03.07-1ubuntu1 amd64Linux Logical Volume Manager ii lvm2-lockd 2.03.07-1ubuntu1 amd64LVM locking daemon A similar bug report from RHEL8 : https://bugzilla.redhat.com/show_bug.cgi?id=1833837 Bug has been fixed upstream : https://sourceware.org/git/?p=lvm2.git;a=commit;h=2d1fe38d84d499011d13ae1ea11535398528fc87 It seems to be included in version 2.03.10 : https://sourceware.org/git/?p=lvm2.git;a=shortlog;h=refs/tags/v2_03_10 How can we get this patch included in Ubuntu 20.04 ? King Regards, Charles To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1920047/+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 1920047] Re: sanlock global lock creation fail
** Tags added: sts -- 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/1920047 Title: sanlock global lock creation fail Status in lvm2 package in Ubuntu: New Bug description: Hello, Running Ubuntu server 20.04, I cannot create a shared VG using sanlock : # vgcreate --shared foo /dev/mapper/vol Enabling sanlock global lock Skipping global lock: lockspace not found or started Logical volume "lvmlock" created. VG foo init failed: -28 Failed to initialize lock args for lock type sanlock Volume group "foo" successfully removed Messages in /var/log/syslog lvmlockd[446807]: 1616089866 WARNING: mixed block sizes physical 4096 logical 512 (using 4096) for /dev/mapper/foo-lvmlock lvmlockd[446807]: 1616089866 S lvm_foo init_vg_san write_resource gl error -28 /dev/mapper/foo-lvmlock # lsb_release -rd Description:Ubuntu 20.04.2 LTS Release:20.04 # dpkg -l | grep lvm ii liblvm2cmd2.03:amd64 2.03.07-1ubuntu1 amd64LVM2 command library ii lvm2 2.03.07-1ubuntu1 amd64Linux Logical Volume Manager ii lvm2-lockd 2.03.07-1ubuntu1 amd64LVM locking daemon A similar bug report from RHEL8 : https://bugzilla.redhat.com/show_bug.cgi?id=1833837 Bug has been fixed upstream : https://sourceware.org/git/?p=lvm2.git;a=commit;h=2d1fe38d84d499011d13ae1ea11535398528fc87 It seems to be included in version 2.03.10 : https://sourceware.org/git/?p=lvm2.git;a=shortlog;h=refs/tags/v2_03_10 How can we get this patch included in Ubuntu 20.04 ? King Regards, Charles To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1920047/+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 1825186] Re: gpgv-win32 autopkgtest always fails
Autopkgtest failures for gnupg2 on armhf have been fixed with a re-run, so it was likely due to a flaky testbed setup. Failures for libgnupg-interface-perl are the result of the upstream test suite and very unlikely to be related to this SRU. I've opened bug 1916499 to investigate those separately. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnupg in Ubuntu. https://bugs.launchpad.net/bugs/1825186 Title: gpgv-win32 autopkgtest always fails Status in gnupg package in Ubuntu: Invalid Status in gnupg2 package in Ubuntu: Fix Released Status in gnupg source package in Xenial: Won't Fix Status in gnupg2 source package in Bionic: Fix Committed Status in gnupg2 source package in Cosmic: Won't Fix Status in gnupg2 source package in Disco: Fix Released Bug description: [impact] gpgv-win32 autopkgtest always fails [test case] check http://autopkgtest.ubuntu.com/packages/g/gnupg2 or run autopkgtest manually note the gpgv-win32 test is skipped on ppc64el and s390x for b/c, and has been removed from d/t/control entirely in d [regression potential] little to none; this affects the test case only [other info] as mentioned, in disco, the gpgv-win32 test has been removed from the tests/control completely. not sure if that is a better approach than fixing the test case. For now, I marked this Fix Released for disco since it doesn't fail there (since the testcase was removed). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnupg/+bug/1825186/+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 1825186] Re: gpgv-win32 autopkgtest always fails
I can see autopkgtest completing successfully for most archs on http://autopkgtest.ubuntu.com/packages/g/gnupg2 for the new Bionic release, so I'll mark this as verified. I'm still looking into the regressions for armhf and for libgnupg- interface-perl, but the latter seems to have been broken since 2018. ** Tags removed: verification-needed verification-needed-bionic ** Tags added: verification-done verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gnupg in Ubuntu. https://bugs.launchpad.net/bugs/1825186 Title: gpgv-win32 autopkgtest always fails Status in gnupg package in Ubuntu: Invalid Status in gnupg2 package in Ubuntu: Fix Released Status in gnupg source package in Xenial: Won't Fix Status in gnupg2 source package in Bionic: Fix Committed Status in gnupg2 source package in Cosmic: Won't Fix Status in gnupg2 source package in Disco: Fix Released Bug description: [impact] gpgv-win32 autopkgtest always fails [test case] check http://autopkgtest.ubuntu.com/packages/g/gnupg2 or run autopkgtest manually note the gpgv-win32 test is skipped on ppc64el and s390x for b/c, and has been removed from d/t/control entirely in d [regression potential] little to none; this affects the test case only [other info] as mentioned, in disco, the gpgv-win32 test has been removed from the tests/control completely. not sure if that is a better approach than fixing the test case. For now, I marked this Fix Released for disco since it doesn't fail there (since the testcase was removed). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnupg/+bug/1825186/+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 1895757] Re: Terminal hangs running sudo when "use_pty" is set in /etc/sudoers
Verified according to test case from description:
halves@bionic-vm:~$ sudo grep use_pty /etc/sudoers
Defaultsuse_pty
halves@bionic-vm:~$ dpkg -l | grep sudo
ii sudo 1.8.21p2-3ubuntu1.3
amd64Provide limited super user privileges to specific users
halves@bionic-vm:~$ for i in {1..10}; do sudo -- cat /var/log/syslog; done
Oct 1 14:37:40 bionic-vm kernel: [0.00] Linux version
4.15.0-118-generic (buildd@lgw01-amd64-039) (gcc version 7.5.0 (Ubuntu
7.5.0-3ubuntu1~18.04)) #119-Ubuntu SMP Tue Sep 8 12:30:01 UTC 2020 (Ubuntu
4.15.0-118.119-generic 4.15.18)
O
Oct 23 15:53:15 bionic-vm systemd[1]: Started User Manager for UID 1000.
Oct 23 15:53:15 bionic-vm systemd[1810]: Reached target Default.
Oct 23 15:53:15 bionic-vm systemd[1810]: Startup finished in 30ms.
halves@bionic-vm:~$
** Tags removed: verification-needed verification-needed-bionic
** Tags added: verification-done verification-done-bionic
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to sudo in Ubuntu.
https://bugs.launchpad.net/bugs/1895757
Title:
Terminal hangs running sudo when "use_pty" is set in /etc/sudoers
Status in sudo package in Ubuntu:
Fix Released
Status in sudo source package in Bionic:
Fix Committed
Bug description:
[Impact]
sudo commands can hang when IO logging is enabled
[Description]
When doing cleanup in pty_close(), sudo can leave file descriptors and events
behind that would later cause poll() to wait on a "dead" pty. This can cause
sudo to hang when IO logging is enabled, due to the poll() timeouts.
The issue has been fixed upstream by the commit below:
- In pty_close() close the slave and remove any events associated
(4df454310dae)
$ git describe --contains 4df454310dae96d01d09a05be89dc8c57fd4cef7
SUDO_1_8_23
$ rmadison sudo
sudo | 1.8.16-0ubuntu1 | xenial | source, ...
sudo | 1.8.16-0ubuntu1.9 | xenial-security | source, ...
sudo | 1.8.16-0ubuntu1.9 | xenial-updates | source, ...
sudo | 1.8.21p2-3ubuntu1 | bionic | source, ...
sudo | 1.8.21p2-3ubuntu1.2 | bionic-security | source, ...
=> sudo | 1.8.21p2-3ubuntu1.2 | bionic-updates | source, ... <
sudo | 1.8.31-1ubuntu1 | focal| source, ...
sudo | 1.8.31-1ubuntu1.1 | focal-updates| source, ...
sudo | 1.9.1-1ubuntu1 | groovy | source, ...
Xenial doesn't exhibit this behaviour, so fixes are only needed for Bionic
(Focal onwards already have the fix by default due to sudo version).
[Test Case]
1. Ensure /etc/sudoers contains 'Defaults use_pty'
2. Execute the following test command:
$ for i in {1..10}; do sudo -- cat /var/log/syslog; done
The terminal will hang during syslog output.
[Regression Potential]
The fix introduces additional cleaning when closing/flushing pty devices, so
the
regression potential should be low. It has been present upstream since
sudo-1.8.23, so it has seen thorough testing in most Linux distributions
including Ubuntu.
A regression could possibly cause issues when switching back out from sudo
sessions, as the changes only touch the pty_close path, but seems unlikely
considering the patch has been present in other Ubuntu releases as well.
--
An SSH terminal into an Ubuntu server (tested on 18.04.5) hangs running a
command using 'sudo' when 'use_pty' is set in /etc/sudoers.
Steps to reproduce ('sudo' version --> 1.8.21p2-3ubuntu1.2):
1) Log in into an Ubuntu server (tested on 18.04.5 using SSH)
2) Ensure that /etc/sudoers has the following line (add this line if not
present)
Defaults use_pty
3) Execute the following (test 'sudo' command):
for i in {1..10}; do sudo -- cat /var/log/syslog; done
The terminal hangs and the following backtrace is obtained:
(gdb) bt
#0 0x7f751d5c8cc4 in __GI___poll (fds=0x55d0159917b0, nfds=1,
timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1 0x7f751d8b146a in poll (__timeout=, __nfds=, __fds=) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
#2 sudo_ev_scan_impl (base=base@entry=0x55d015990dc0, flags=flags@entry=0)
at ../../../lib/util/event_poll.c:155
#3 0x7f751d8aa74d in sudo_ev_loop_v1 (base=base@entry=0x55d015990dc0,
flags=flags@entry=0) at ../../../lib/util/event.c:617
#4 0x55d01570597a in del_io_events (nonblocking=nonblocking@entry=false)
at ../../src/exec_pty.c:1537
#5 0x55d015707b97 in pty_close (cstat=0x7ffd074d6110) at
../../src/exec_pty.c:697
#6 exec_pty (details=details@entry=0x55d01591e0e0 ,
cstat=cstat@entry=0x7ffd074d6110) at ../../src/exec_pty.c:1412
#7 0x55d015701178 in sudo_execute (details=0x55d01591e0e0
, cstat=0x7ffd074d6110) at ../../src/exec.c:391
#8 0x55d01570e15b in run_command (details=0x55d01591e0e0
) at ../../src/sudo.c:968
#9 0x55d0156ff9a0 in main (argc=, argv=,
[Touch-packages] [Bug 1895757] Re: Terminal hangs running sudo when "use_pty" is set in /etc/sudoers
Builds for this patchset have been uploaded to:
https://launchpad.net/~halves/+archive/ubuntu/lp1895757
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to sudo in Ubuntu.
https://bugs.launchpad.net/bugs/1895757
Title:
Terminal hangs running sudo when "use_pty" is set in /etc/sudoers
Status in sudo package in Ubuntu:
Fix Released
Status in sudo source package in Bionic:
In Progress
Bug description:
[Impact]
sudo commands can hang when IO logging is enabled
[Description]
When doing cleanup in pty_close(), sudo can leave file descriptors and events
behind that would later cause poll() to wait on a "dead" pty. This can cause
sudo to hang when IO logging is enabled, due to the poll() timeouts.
The issue has been fixed upstream by the commit below:
- In pty_close() close the slave and remove any events associated
(4df454310dae)
$ rmadison sudo
sudo | 1.8.16-0ubuntu1 | xenial | source, ...
sudo | 1.8.16-0ubuntu1.9 | xenial-security | source, ...
sudo | 1.8.16-0ubuntu1.9 | xenial-updates | source, ...
sudo | 1.8.21p2-3ubuntu1 | bionic | source, ...
sudo | 1.8.21p2-3ubuntu1.2 | bionic-security | source, ...
sudo | 1.8.21p2-3ubuntu1.2 | bionic-updates | source, ... <
sudo | 1.8.31-1ubuntu1 | focal| source, ...
sudo | 1.8.31-1ubuntu1.1 | focal-updates| source, ...
sudo | 1.9.1-1ubuntu1 | groovy | source, ...
Xenial doesn't exhibit this behaviour, so fixes are only needed for Bionic
(Focal onwards already have the fix by default due to sudo version).
[Test Case]
1. Ensure /etc/sudoers contains 'Defaults use_pty'
2. Execute the following test command:
$ for i in {1..10}; do sudo -- cat /var/log/syslog; done
The terminal will hang during syslog output.
[Regression Potential]
The fix introduces additional cleaning when closing/flushing pty devices, so
the
regression potential should be low. It has been present upstream since
sudo-1.8.23, so it has seen thorough testing in most Linux distributions
including Ubuntu.
A regression could possibly cause issues when switching back out from sudo
sessions, as the changes only touch the pty_close path, but seems unlikely
considering the patch has been present in other Ubuntu releases as well.
--
An SSH terminal into an Ubuntu server (tested on 18.04.5) hangs running a
command using 'sudo' when 'use_pty' is set in /etc/sudoers.
Steps to reproduce ('sudo' version --> 1.8.21p2-3ubuntu1.2):
1) Log in into an Ubuntu server (tested on 18.04.5 using SSH)
2) Ensure that /etc/sudoers has the following line (add this line if not
present)
Defaults use_pty
3) Execute the following (test 'sudo' command):
for i in {1..10}; do sudo -- cat /var/log/syslog; done
The terminal hangs and the following backtrace is obtained:
(gdb) bt
#0 0x7f751d5c8cc4 in __GI___poll (fds=0x55d0159917b0, nfds=1,
timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1 0x7f751d8b146a in poll (__timeout=, __nfds=, __fds=) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
#2 sudo_ev_scan_impl (base=base@entry=0x55d015990dc0, flags=flags@entry=0)
at ../../../lib/util/event_poll.c:155
#3 0x7f751d8aa74d in sudo_ev_loop_v1 (base=base@entry=0x55d015990dc0,
flags=flags@entry=0) at ../../../lib/util/event.c:617
#4 0x55d01570597a in del_io_events (nonblocking=nonblocking@entry=false)
at ../../src/exec_pty.c:1537
#5 0x55d015707b97 in pty_close (cstat=0x7ffd074d6110) at
../../src/exec_pty.c:697
#6 exec_pty (details=details@entry=0x55d01591e0e0 ,
cstat=cstat@entry=0x7ffd074d6110) at ../../src/exec_pty.c:1412
#7 0x55d015701178 in sudo_execute (details=0x55d01591e0e0
, cstat=0x7ffd074d6110) at ../../src/exec.c:391
#8 0x55d01570e15b in run_command (details=0x55d01591e0e0
) at ../../src/sudo.c:968
#9 0x55d0156ff9a0 in main (argc=, argv=,
envp=) at ../../src/sudo.c:294
A similar (most likely the same) bug has been reported here
https://access.redhat.com/solutions/3404401.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1895757/+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 1895757] Re: Terminal hangs running sudo when "use_pty" is set in /etc/sudoers
** Tags added: sts-sponsor
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to sudo in Ubuntu.
https://bugs.launchpad.net/bugs/1895757
Title:
Terminal hangs running sudo when "use_pty" is set in /etc/sudoers
Status in sudo package in Ubuntu:
Fix Released
Status in sudo source package in Bionic:
In Progress
Bug description:
[Impact]
sudo commands can hang when IO logging is enabled
[Description]
When doing cleanup in pty_close(), sudo can leave file descriptors and events
behind that would later cause poll() to wait on a "dead" pty. This can cause
sudo to hang when IO logging is enabled, due to the poll() timeouts.
The issue has been fixed upstream by the commit below:
- In pty_close() close the slave and remove any events associated
(4df454310dae)
$ rmadison sudo
sudo | 1.8.16-0ubuntu1 | xenial | source, ...
sudo | 1.8.16-0ubuntu1.9 | xenial-security | source, ...
sudo | 1.8.16-0ubuntu1.9 | xenial-updates | source, ...
sudo | 1.8.21p2-3ubuntu1 | bionic | source, ...
sudo | 1.8.21p2-3ubuntu1.2 | bionic-security | source, ...
sudo | 1.8.21p2-3ubuntu1.2 | bionic-updates | source, ... <
sudo | 1.8.31-1ubuntu1 | focal| source, ...
sudo | 1.8.31-1ubuntu1.1 | focal-updates| source, ...
sudo | 1.9.1-1ubuntu1 | groovy | source, ...
Xenial doesn't exhibit this behaviour, so fixes are only needed for Bionic
(Focal onwards already have the fix by default due to sudo version).
[Test Case]
1. Ensure /etc/sudoers contains 'Defaults use_pty'
2. Execute the following test command:
$ for i in {1..10}; do sudo -- cat /var/log/syslog; done
The terminal will hang during syslog output.
[Regression Potential]
The fix introduces additional cleaning when closing/flushing pty devices, so
the
regression potential should be low. It has been present upstream since
sudo-1.8.23, so it has seen thorough testing in most Linux distributions
including Ubuntu.
A regression could possibly cause issues when switching back out from sudo
sessions, as the changes only touch the pty_close path, but seems unlikely
considering the patch has been present in other Ubuntu releases as well.
--
An SSH terminal into an Ubuntu server (tested on 18.04.5) hangs running a
command using 'sudo' when 'use_pty' is set in /etc/sudoers.
Steps to reproduce ('sudo' version --> 1.8.21p2-3ubuntu1.2):
1) Log in into an Ubuntu server (tested on 18.04.5 using SSH)
2) Ensure that /etc/sudoers has the following line (add this line if not
present)
Defaults use_pty
3) Execute the following (test 'sudo' command):
for i in {1..10}; do sudo -- cat /var/log/syslog; done
The terminal hangs and the following backtrace is obtained:
(gdb) bt
#0 0x7f751d5c8cc4 in __GI___poll (fds=0x55d0159917b0, nfds=1,
timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1 0x7f751d8b146a in poll (__timeout=, __nfds=, __fds=) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
#2 sudo_ev_scan_impl (base=base@entry=0x55d015990dc0, flags=flags@entry=0)
at ../../../lib/util/event_poll.c:155
#3 0x7f751d8aa74d in sudo_ev_loop_v1 (base=base@entry=0x55d015990dc0,
flags=flags@entry=0) at ../../../lib/util/event.c:617
#4 0x55d01570597a in del_io_events (nonblocking=nonblocking@entry=false)
at ../../src/exec_pty.c:1537
#5 0x55d015707b97 in pty_close (cstat=0x7ffd074d6110) at
../../src/exec_pty.c:697
#6 exec_pty (details=details@entry=0x55d01591e0e0 ,
cstat=cstat@entry=0x7ffd074d6110) at ../../src/exec_pty.c:1412
#7 0x55d015701178 in sudo_execute (details=0x55d01591e0e0
, cstat=0x7ffd074d6110) at ../../src/exec.c:391
#8 0x55d01570e15b in run_command (details=0x55d01591e0e0
) at ../../src/sudo.c:968
#9 0x55d0156ff9a0 in main (argc=, argv=,
envp=) at ../../src/sudo.c:294
A similar (most likely the same) bug has been reported here
https://access.redhat.com/solutions/3404401.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1895757/+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 1895757] Re: Terminal hangs running sudo when "use_pty" is set in /etc/sudoers
** Description changed:
- An SSH terminal into an Ubuntu server (tested on 18.04.5) hangs running
- a command using 'sudo' when 'use_pty' is set in /etc/sudoers.
+ [Impact]
+ sudo commands can hang when IO logging is enabled
+
+ [Description]
+ When doing cleanup in pty_close(), sudo can leave file descriptors and events
+ behind that would later cause poll() to wait on a "dead" pty. This can cause
+ sudo to hang when IO logging is enabled, due to the poll() timeouts.
+
+ The issue has been fixed upstream by the commit below:
+ - In pty_close() close the slave and remove any events associated
(4df454310dae)
+
+ $ rmadison sudo
+ sudo | 1.8.16-0ubuntu1 | xenial | source, ...
+ sudo | 1.8.16-0ubuntu1.9 | xenial-security | source, ...
+ sudo | 1.8.16-0ubuntu1.9 | xenial-updates | source, ...
+ sudo | 1.8.21p2-3ubuntu1 | bionic | source, ...
+ sudo | 1.8.21p2-3ubuntu1.2 | bionic-security | source, ...
+ sudo | 1.8.21p2-3ubuntu1.2 | bionic-updates | source, ... <
+ sudo | 1.8.31-1ubuntu1 | focal| source, ...
+ sudo | 1.8.31-1ubuntu1.1 | focal-updates| source, ...
+ sudo | 1.9.1-1ubuntu1 | groovy | source, ...
+
+ Xenial doesn't exhibit this behaviour, so fixes are only needed for Bionic
+ (Focal onwards already have the fix by default due to sudo version).
+
+ [Test Case]
+
+ 1. Ensure /etc/sudoers contains 'Defaults use_pty'
+ 2. Execute the following test command:
+ $ for i in {1..10}; do sudo -- cat /var/log/syslog; done
+
+ The terminal will hang during syslog output.
+
+ [Regression Potential]
+ The fix introduces additional cleaning when closing/flushing pty devices, so
the
+ regression potential should be low. It has been present upstream since
+ sudo-1.8.23, so it has seen thorough testing in most Linux distributions
+ including Ubuntu.
+
+ A regression could possibly cause issues when switching back out from sudo
+ sessions, as the changes only touch the pty_close path, but seems unlikely
+ considering the patch has been present in other Ubuntu releases as well.
+
+ --
+ An SSH terminal into an Ubuntu server (tested on 18.04.5) hangs running a
command using 'sudo' when 'use_pty' is set in /etc/sudoers.
Steps to reproduce ('sudo' version --> 1.8.21p2-3ubuntu1.2):
1) Log in into an Ubuntu server (tested on 18.04.5 using SSH)
2) Ensure that /etc/sudoers has the following line (add this line if not
present)
Defaults use_pty
3) Execute the following (test 'sudo' command):
for i in {1..10}; do sudo -- cat /var/log/syslog; done
The terminal hangs and the following backtrace is obtained:
(gdb) bt
#0 0x7f751d5c8cc4 in __GI___poll (fds=0x55d0159917b0, nfds=1,
timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1 0x7f751d8b146a in poll (__timeout=, __nfds=, __fds=) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
#2 sudo_ev_scan_impl (base=base@entry=0x55d015990dc0, flags=flags@entry=0)
at ../../../lib/util/event_poll.c:155
#3 0x7f751d8aa74d in sudo_ev_loop_v1 (base=base@entry=0x55d015990dc0,
flags=flags@entry=0) at ../../../lib/util/event.c:617
#4 0x55d01570597a in del_io_events (nonblocking=nonblocking@entry=false)
at ../../src/exec_pty.c:1537
#5 0x55d015707b97 in pty_close (cstat=0x7ffd074d6110) at
../../src/exec_pty.c:697
#6 exec_pty (details=details@entry=0x55d01591e0e0 ,
cstat=cstat@entry=0x7ffd074d6110) at ../../src/exec_pty.c:1412
#7 0x55d015701178 in sudo_execute (details=0x55d01591e0e0
, cstat=0x7ffd074d6110) at ../../src/exec.c:391
#8 0x55d01570e15b in run_command (details=0x55d01591e0e0
) at ../../src/sudo.c:968
#9 0x55d0156ff9a0 in main (argc=, argv=,
envp=) at ../../src/sudo.c:294
A similar (most likely the same) bug has been reported here
https://access.redhat.com/solutions/3404401.
** Changed in: sudo (Ubuntu)
Status: New => Fix Released
** Changed in: sudo (Ubuntu Bionic)
Status: New => In Progress
** Changed in: sudo (Ubuntu Bionic)
Importance: Undecided => High
** Changed in: sudo (Ubuntu Bionic)
Assignee: (unassigned) => Heitor Alves de Siqueira (halves)
** Tags added: sts
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to sudo in Ubuntu.
https://bugs.launchpad.net/bugs/1895757
Title:
Terminal hangs running sudo when "use_pty" is set in /etc/sudoers
Status in sudo package in Ubuntu:
Fix Released
Status in sudo source package in Bionic:
In Progress
Bug description:
[Impact]
sudo commands can hang when IO logging is enabled
[Description]
When doing cleanup in pty_close(), sudo can leave file descriptors and events
behind that would later cause poll() to wait on a "dead" pty. This can cause
sudo to hang when IO logging is enabled, due to the poll() timeouts.
The issue has been fixed upstream by the commit below:
[Touch-packages] [Bug 1876600] Re: cookie overruns can cause org.freedesktop.systemd1 dbus to hang
Validated systemd/229-4ubuntu21.29 from xenial-proposed, according to test case from description: ubuntu@systemd-cookie-xenial:~$ dpkg -l systemd | grep systemd ii systemd229-4ubuntu21.29 amd64system and service manager ubuntu@systemd-cookie-xenial:~$ gcc -Wall test.c -o cookie -lsystemd -g ubuntu@systemd-cookie-xenial:~$ gdb --batch --command=test.gdb --args ./cookie Breakpoint 1 at 0x400ddb: file test.c, line 38. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". (65s) cookie: 0x0001reply-cookie: 0x0001 Breakpoint 1, print_unit_path (bus=0x603040) at test.c:38 38 r = sd_bus_message_new_method_call(bus, , $1 = 0x1 $2 = 0xff00 (65s) cookie: 0x8000reply-cookie: 0x8000 (129s) cookie: 0x8001 reply-cookie: 0x8001 (188s) cookie: 0x8002 reply-cookie: 0x8002 ** Tags removed: verification-needed verification-needed-xenial ** Tags added: verification-done verification-done-xenial -- 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/1876600 Title: cookie overruns can cause org.freedesktop.systemd1 dbus to hang Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Fix Committed Status in systemd source package in Bionic: Fix Released 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 include a "cookie" value to uniquely identify them in their bus context. This value is obtained from the bus header, and incremented for each exchanged message in the same bus object. 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 fail. This can lead to these services becoming unresponsive, as they get stuck trying to communicate with invalid bus cookie values. This issue 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). Using GDB, we can construct an artificial test case to test the cookie overflow. The test case below performs the following steps: 1. Create a new system bus object through sd_bus_default_system() 2. Allocate and append a new method_call message to the bus 3. Send the message through sd_bus_call() 4. Handle the response message and free up the message objects It's essentially the example code from the sd_bus_message_new_method_call() manpage, with minor modifications: this is done continuously, to keep incrementing the bus cookie value. We step in with GDB when it reaches 0x1, and set its value to 0xff00 which then causes the test program to fail shortly afterwards. An example test run of an impacted system: ubuntu@bionic:~$ gcc -Wall test.c -o cookie -lsystemd -g ubuntu@bionic:~$ gdb --batch --command=test.gdb --args ./cookie Breakpoint 1 at 0xe61: file test.c, line 38. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". (16s) cookie: 0x0001reply-cookie: 0x0001 Breakpoint 1, print_unit_path (bus=0x55757290) at test.c:38 38 r = sd_bus_message_new_method_call(bus, , $1 = 0x1 $2 = 0xff00 Call failed: Operation not supported Sleeping and retrying... Call failed: Invalid argument Assertion 'm->n_ref > 0' failed at ../src/libsystemd/sd-bus/bus-message.c:934, function sd_bus_message_unref(). Aborting. Program received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. To compile and debug the test
[Touch-packages] [Bug 1876600] Re: cookie overruns can cause org.freedesktop.systemd1 dbus to hang
Validated systemd 237-3ubuntu10.41 from bionic-proposed, according to test case from bug description: ubuntu@systemd-cookie-bionic:~$ dpkg -l systemd | grep systemd ii systemd237-3ubuntu10.41 amd64system and service manager ubuntu@systemd-cookie-bionic:~$ gcc -Wall test.c -o cookie -lsystemd -g ubuntu@systemd-cookie-bionic:~$ gdb --batch --command=test.gdb --args ./cookie Breakpoint 1 at 0xe61: file test.c, line 38. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". (15s) cookie: 0x0001reply-cookie: 0x0001 Breakpoint 1, print_unit_path (bus=0x55757290) at test.c:38 38 r = sd_bus_message_new_method_call(bus, , $1 = 0x1 $2 = 0xff00 (15s) cookie: 0x8000reply-cookie: 0x8000 (29s) cookie: 0x8001reply-cookie: 0x8001 (43s) cookie: 0x8002reply-cookie: 0x8002 ** Tags removed: verification-needed verification-needed-bionic ** Tags added: verification-done verification-done-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/1876600 Title: cookie overruns can cause org.freedesktop.systemd1 dbus to hang Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: In Progress Status in systemd source package in Bionic: Fix Committed 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 include a "cookie" value to uniquely identify them in their bus context. This value is obtained from the bus header, and incremented for each exchanged message in the same bus object. 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 fail. This can lead to these services becoming unresponsive, as they get stuck trying to communicate with invalid bus cookie values. This issue 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). Using GDB, we can construct an artificial test case to test the cookie overflow. The test case below performs the following steps: 1. Create a new system bus object through sd_bus_default_system() 2. Allocate and append a new method_call message to the bus 3. Send the message through sd_bus_call() 4. Handle the response message and free up the message objects It's essentially the example code from the sd_bus_message_new_method_call() manpage, with minor modifications: this is done continuously, to keep incrementing the bus cookie value. We step in with GDB when it reaches 0x1, and set its value to 0xff00 which then causes the test program to fail shortly afterwards. An example test run of an impacted system: ubuntu@bionic:~$ gcc -Wall test.c -o cookie -lsystemd -g ubuntu@bionic:~$ gdb --batch --command=test.gdb --args ./cookie Breakpoint 1 at 0xe61: file test.c, line 38. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". (16s) cookie: 0x0001reply-cookie: 0x0001 Breakpoint 1, print_unit_path (bus=0x55757290) at test.c:38 38 r = sd_bus_message_new_method_call(bus, , $1 = 0x1 $2 = 0xff00 Call failed: Operation not supported Sleeping and retrying... Call failed: Invalid argument Assertion 'm->n_ref > 0' failed at ../src/libsystemd/sd-bus/bus-message.c:934, function sd_bus_message_unref(). Aborting. Program received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. To compile and debug the
[Touch-packages] [Bug 1876600] Re: cookie overruns can cause org.freedesktop.systemd1 dbus to hang
** Changed in: systemd (Ubuntu Xenial) Status: Confirmed => In Progress ** 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/1876600 Title: cookie overruns can cause org.freedesktop.systemd1 dbus to hang Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: In Progress Status in systemd source package in Bionic: In Progress 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 include a "cookie" value to uniquely identify them in their bus context. This value is obtained from the bus header, and incremented for each exchanged message in the same bus object. 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 fail. This can lead to these services becoming unresponsive, as they get stuck trying to communicate with invalid bus cookie values. This issue 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). Using GDB, we can construct an artificial test case to test the cookie overflow. The test case below performs the following steps: 1. Create a new system bus object through sd_bus_default_system() 2. Allocate and append a new method_call message to the bus 3. Send the message through sd_bus_call() 4. Handle the response message and free up the message objects It's essentially the example code from the sd_bus_message_new_method_call() manpage, with minor modifications: this is done continuously, to keep incrementing the bus cookie value. We step in with GDB when it reaches 0x1, and set its value to 0xff00 which then causes the test program to fail shortly afterwards. An example test run of an impacted system: ubuntu@bionic:~$ gcc -Wall test.c -o cookie -lsystemd -g ubuntu@bionic:~$ gdb --batch --command=test.gdb --args ./cookie Breakpoint 1 at 0xe61: file test.c, line 38. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". (16s) cookie: 0x0001reply-cookie: 0x0001 Breakpoint 1, print_unit_path (bus=0x55757290) at test.c:38 38 r = sd_bus_message_new_method_call(bus, , $1 = 0x1 $2 = 0xff00 Call failed: Operation not supported Sleeping and retrying... Call failed: Invalid argument Assertion 'm->n_ref > 0' failed at ../src/libsystemd/sd-bus/bus-message.c:934, function sd_bus_message_unref(). Aborting. Program received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. To compile and debug the test case above, libsystemd-dev and libsystemd0-dbgsym are required. Both test.c and test.gdb source code are attached to this LP bug. [Regression Potential] This fix introduces some changes in the way cookie incrementation is handled. We now have a reduced number of available values, since the patch makes use of a high order bit to indicate whether we have overflowed or not. Potential issues could arise from two distinct messages repeating the cookie value, or from us not handling the cookie reuse properly. In practice, this shouldn't cause serious problems as most dbus messages should not stall long enough for a possible overlap in the 2^31 space. The patch has been present in other stable Ubuntu Series and upstream, and has been validated and tested through the systemd test suite and autopkgtests. To manage notifications about this bug go to:
[Touch-packages] [Bug 1876600] Re: cookie overruns can cause org.freedesktop.systemd1 dbus to hang
** Description changed: [Impact] Long-running services overflow the sd_bus->cookie counter, causing further communication with org.freedesktop.systemd1 to stall. [Description] Systemd dbus messages include a "cookie" value to uniquely identify them in their bus context. This value is obtained from the bus header, and incremented for each exchanged message in the same bus object. 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 fail. This can lead to these services becoming unresponsive, as they get stuck trying to communicate with invalid bus cookie values. This issue 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). Using GDB, we can construct an artificial test case to test the cookie overflow. The test case below performs the following steps: 1. Create a new system bus object through sd_bus_default_system() 2. Allocate and append a new method_call message to the bus 3. Send the message through sd_bus_call() 4. Handle the response message and free up the message objects It's essentially the example code from the sd_bus_message_new_method_call() manpage, with minor modifications: this is done continuously, to keep incrementing the bus cookie value. We step in with GDB when it reaches 0x1, and set its value to 0xff00 which then causes the test program to fail shortly afterwards. An example test run of an impacted system: ubuntu@bionic:~$ gcc -Wall test.c -o cookie -lsystemd -g ubuntu@bionic:~$ gdb --batch --command=test.gdb --args ./cookie Breakpoint 1 at 0xe61: file test.c, line 38. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". (16s) cookie: 0x0001reply-cookie: 0x0001 Breakpoint 1, print_unit_path (bus=0x55757290) at test.c:38 38 r = sd_bus_message_new_method_call(bus, , $1 = 0x1 $2 = 0xff00 Call failed: Operation not supported Sleeping and retrying... Call failed: Invalid argument Assertion 'm->n_ref > 0' failed at ../src/libsystemd/sd-bus/bus-message.c:934, function sd_bus_message_unref(). Aborting. Program received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. - u To compile and debug the test case above, libsystemd-dev and libsystemd0-dbgsym are required. Both test.c and test.gdb source code are attached to this LP bug. [Regression Potential] This fix introduces some changes in the way cookie incrementation is handled. We now have a reduced number of available values, since the patch makes use of a high order bit to indicate whether we have overflowed or not. Potential issues could arise from two distinct messages repeating the cookie value, or from us not handling the cookie reuse properly. In practice, this shouldn't cause serious problems as most dbus messages should not stall long enough for a possible overlap in the 2^31 space. The patch has been present in other stable Ubuntu Series and upstream, and has been validated and tested through the systemd test suite and autopkgtests. -- 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/1876600 Title: cookie overruns can cause org.freedesktop.systemd1 dbus to hang Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: In Progress Status in systemd source package in Bionic: In Progress 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
[Touch-packages] [Bug 1876600] Re: cookie overruns can cause org.freedesktop.systemd1 dbus to hang
Test builds for the proposed merge can be found at the lp1876600 PPA [0]. [0] https://launchpad.net/~halves/+archive/ubuntu/lp1876600 ** Tags added: 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/1876600 Title: cookie overruns can 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 include a "cookie" value to uniquely identify them in their bus context. This value is obtained from the bus header, and incremented for each exchanged message in the same bus object. 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 fail. This can lead to these services becoming unresponsive, as they get stuck trying to communicate with invalid bus cookie values. This issue 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). Using GDB, we can construct an artificial test case to test the cookie overflow. The test case below performs the following steps: 1. Create a new system bus object through sd_bus_default_system() 2. Allocate and append a new method_call message to the bus 3. Send the message through sd_bus_call() 4. Handle the response message and free up the message objects It's essentially the example code from the sd_bus_message_new_method_call() manpage, with minor modifications: this is done continuously, to keep incrementing the bus cookie value. We step in with GDB when it reaches 0x1, and set its value to 0xff00 which then causes the test program to fail shortly afterwards. An example test run of an impacted system: ubuntu@bionic:~$ gcc -Wall test.c -o cookie -lsystemd -g ubuntu@bionic:~$ gdb --batch --command=test.gdb --args ./cookie Breakpoint 1 at 0xe61: file test.c, line 38. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". (16s) cookie: 0x0001reply-cookie: 0x0001 Breakpoint 1, print_unit_path (bus=0x55757290) at test.c:38 38 r = sd_bus_message_new_method_call(bus, , $1 = 0x1 $2 = 0xff00 Call failed: Operation not supported Sleeping and retrying... Call failed: Invalid argument Assertion 'm->n_ref > 0' failed at ../src/libsystemd/sd-bus/bus-message.c:934, function sd_bus_message_unref(). Aborting. Program received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. u To compile and debug the test case above, libsystemd-dev and libsystemd0-dbgsym are required. Both test.c and test.gdb source code are attached to this LP bug. [Regression Potential] This fix introduces some changes in the way cookie incrementation is handled. We now have a reduced number of available values, since the patch makes use of a high order bit to indicate whether we have overflowed or not. Potential issues could arise from two distinct messages repeating the cookie value, or from us not handling the cookie reuse properly. In practice, this shouldn't cause serious problems as most dbus messages should not stall long enough for a possible overlap in the 2^31 space. The patch has been present in other stable Ubuntu Series and upstream, and has been validated and tested through the systemd test suite and autopkgtests. To manage notifications about this bug go to:
[Touch-packages] [Bug 1876600] Re: cookie overruns can cause org.freedesktop.systemd1 dbus to hang
** Attachment added: "test.gdb" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1876600/+attachment/5366780/+files/test.gdb ** Description changed: [Impact] Long-running services overflow the sd_bus->cookie counter, causing further communication with org.freedesktop.systemd1 to stall. [Description] Systemd dbus messages include a "cookie" value to uniquely identify them in their bus context. This value is obtained from the bus header, and incremented for each exchanged message in the same bus object. 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 fail. This can lead to these services becoming unresponsive, as they get stuck trying to communicate with invalid bus cookie values. This issue 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, ... + 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). Using GDB, we can construct an artificial test case to test the cookie overflow. The test case below performs the following steps: 1. Create a new system bus object through sd_bus_default_system() 2. Allocate and append a new method_call message to the bus 3. Send the message through sd_bus_call() 4. Handle the response message and free up the message objects - This is done continuously, to keep incrementing the bus cookie value. We step in with GDB when it reaches 0x1, and set its value to 0xff00 which then causes the test program to fail shortly afterwards. An example test run of an impacted system: + It's essentially the example code from the + sd_bus_message_new_method_call() manpage, with minor modifications: this + is done continuously, to keep incrementing the bus cookie value. We step + in with GDB when it reaches 0x1, and set its value to 0xff00 + which then causes the test program to fail shortly afterwards. An + example test run of an impacted system: + ubuntu@bionic:~$ gcc -Wall test.c -o cookie -lsystemd -g ubuntu@bionic:~$ gdb --batch --command=test.gdb --args ./cookie Breakpoint 1 at 0xe61: file test.c, line 38. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". (16s) cookie: 0x0001reply-cookie: 0x0001 Breakpoint 1, print_unit_path (bus=0x55757290) at test.c:38 38 r = sd_bus_message_new_method_call(bus, , $1 = 0x1 $2 = 0xff00 Call failed: Operation not supported Sleeping and retrying... Call failed: Invalid argument Assertion 'm->n_ref > 0' failed at ../src/libsystemd/sd-bus/bus-message.c:934, function sd_bus_message_unref(). Aborting. Program received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. u To compile and debug the test case above, libsystemd-dev and libsystemd0-dbgsym are required. Both test.c and test.gdb source code are attached to this LP bug. [Regression Potential] This fix introduces some changes in the way cookie incrementation is handled. We now have a reduced number of available values, since the patch makes use of a high order bit to indicate whether we have overflowed or not. Potential issues could arise from two distinct messages repeating the cookie value, or from us not
[Touch-packages] [Bug 1876600] Re: cookie overruns cause org.freedesktop.systemd1 dbus to hang
** Description changed: [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. + Systemd dbus messages include a "cookie" value to uniquely identify them in their bus context. This value is obtained from the bus header, and incremented for each exchanged message in the same bus object. 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 fail. This can lead to these services becoming unresponsive, as they get stuck trying to communicate with invalid bus cookie values. - This has been fixed upstream by the commit below: + This issue 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). + Using GDB, we can construct an artificial test case to test the cookie overflow. The test case below performs the following steps: + + 1. Create a new system bus object through sd_bus_default_system() + 2. Allocate and append a new method_call message to the bus + 3. Send the message through sd_bus_call() + 4. Handle the response message and free up the message objects + + This is done continuously, to keep incrementing the bus cookie value. We step in with GDB when it reaches 0x1, and set its value to 0xff00 which then causes the test program to fail shortly afterwards. An example test run of an impacted system: + ubuntu@bionic:~$ gcc -Wall test.c -o cookie -lsystemd -g + ubuntu@bionic:~$ gdb --batch --command=test.gdb --args ./cookie + Breakpoint 1 at 0xe61: file test.c, line 38. + [Thread debugging using libthread_db enabled] + Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". + (16s) cookie: 0x0001reply-cookie: 0x0001 + + Breakpoint 1, print_unit_path (bus=0x55757290) at test.c:38 + 38 r = sd_bus_message_new_method_call(bus, , + $1 = 0x1 + $2 = 0xff00 + Call failed: Operation not supported + Sleeping and retrying... + Call failed: Invalid argument + Assertion 'm->n_ref > 0' failed at ../src/libsystemd/sd-bus/bus-message.c:934, function sd_bus_message_unref(). Aborting. + + Program received signal SIGABRT, Aborted. + __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51 + 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. + u + + To compile and debug the test case above, libsystemd-dev and libsystemd0-dbgsym are required. + Both test.c and test.gdb source code are attached to this LP bug. + + [Regression Potential] + This fix introduces some changes in the way cookie incrementation is handled. We now have a reduced number of available values, since the patch makes use of a high order bit to indicate whether we have overflowed or not. Potential issues could arise from two distinct messages repeating the cookie value, or from us not handling the cookie reuse properly. In practice, this shouldn't cause serious problems as most dbus messages should not stall long enough for a possible overlap in the 2^31 space. The patch has been present in other stable Ubuntu Series and upstream, and has been validated and tested through the systemd test suite and autopkgtests. ** Summary changed: - cookie overruns cause org.freedesktop.systemd1 dbus to hang + cookie overruns can cause org.freedesktop.systemd1 dbus to hang ** Attachment added: "test.c" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1876600/+attachment/5366779/+files/test.c -- You received this bug notification because you are a member of Ubuntu Touch seeded packages,
[Touch-packages] [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 Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. 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/~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 1876600] [NEW] cookie overruns cause org.freedesktop.systemd1 dbus to hang
Public bug reported: [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). ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Tags: sts -- 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/1876600 Title: cookie overruns cause org.freedesktop.systemd1 dbus to hang Status in systemd package in Ubuntu: New 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/~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 1410558] Re: ps doesn't support "thcount" format specifier on Xenial
Given this is an extremely simple fix to the procps output flags, none of the
autopkgtest regressions seem to be a result of this patch.
More details on each reported regression:
* apport/2.20.1-0ubuntu2.21 (amd64/i386)
- has failed since 2.20.1-0ubuntu2.18 according to [0]
- test_sandbox_cache_options: fails due to "ERROR: Package download error, try
again later: Untrusted packages:"
- test_get_logind_session: fails due to a systemd-logind error
- test_core_dump_packaged, test_core_dump_unpackaged: fail with "leaves
unexpected core file behind"
- test_crash_setuid_drop, test_crash_setuid_keep,
test_crash_setuid_nonwritable_cwd, test_lock_symlink: fail to generate reports
- test_run_crash_kernel: fails due to an URL mismatch
(http://linux-signed.bugs.example.com/5 vs http://linux.bugs.example.com/5)
* cmake/3.5.1-1ubuntu3 (armhf)
- retest could fix the proxy error
- CTestTestUpload: fails due to resolve error ("squid.internal" proxy)
* livecd-rootfs/2.408.57 (amd64/i386)
- tests timed out, a re-test should clear this regression
* openssh/1:7.2p2-4ubuntu2.8 (amd64/arm64/i386)
- failed due to host key certification, re-test should also clear this one
[0] http://autopkgtest.ubuntu.com/packages/a/apport/xenial/amd64
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to procps in Ubuntu.
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:
Fix Committed
Bug description:
[Impact]
ps -o thcount prints 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
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
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).
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1410558/+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 1410558] Re: ps doesn't support "thcount" format specifier on Xenial
Verified according to test case from description: ubuntu@xenial:~$ dpkg -l | grep procps ii procps 2:3.3.10-4ubuntu2.5 amd64/proc file system utilities ubuntu@xenial:~$ ps -o thcount THCNT 1 1 ** Tags removed: verification-needed verification-needed-xenial ** Tags added: verification-done verification-done-xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. 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: Fix Committed Bug description: [Impact] ps -o thcount prints 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 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 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). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1410558/+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 1410558] Re: ps doesn't support "thcount" format specifier on Xenial
** Description changed: [Impact] - ps -o thcount doesn't print out an error (error: unknown user-defined format specifier "thcount") + ps -o thcount prints 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, ... + 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] + ps [options] - Try 'ps --help ' - or 'ps --help ' - for additional help text. + 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 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 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). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. 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 prints 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
[Touch-packages] [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 Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. 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, ... procps | 2:3.3.12-3ubun
[Touch-packages] [Bug 1846787] Re: systemd-logind leaves leftover sessions and scope files
** Description changed:
[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)
$ git describe --contains d8fdc62037b5
v230~71^2~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 & 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.
+ As the patches change the communication socket between dbus and systemd,
possible regressions could cause systemd to not be notified of dbus events and
vice-versa. We could see units not getting started properly, and communication
between different services break down (e.g. between systemd-logind and other
processes).
+
+ In this case, the regression potential should be low as these patches
+ have seen extensive testing both upstream and in more recent releases of
+ Ubuntu.
[Touch-packages] [Bug 1846787] Re: systemd-logind leaves leftover sessions and scope files
** Description changed:
[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
+ $ git describe --contains d8fdc62037b5
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 & 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.
** Tags added: sts-sponsor
** Patch added: "lp1846787-dbus-xenial.debdiff"
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1846787/+attachment/5295136/+files/lp1846787-dbus-xenial.debdiff
--
You received this bug notification
[Touch-packages] [Bug 1846787] Re: systemd-logind leaves leftover sessions and scope files
** Patch added: "lp1846787-systemd-xenial.debdiff"
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1846787/+attachment/5295137/+files/lp1846787-systemd-xenial.debdiff
--
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/1846787
Title:
systemd-logind leaves leftover sessions and scope files
Status in dbus package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Fix Released
Status in dbus source package in Xenial:
In Progress
Status in systemd source package in Xenial:
In Progress
Bug description:
[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)
$ git describe --contains d8fdc62037b5
v230~71^2~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 & 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.
[Touch-packages] [Bug 1846787] Re: systemd-logind leaves leftover sessions and scope files
** Changed in: dbus (Ubuntu Xenial)
Status: New => In Progress
** Changed in: systemd (Ubuntu Xenial)
Status: New => In Progress
** Description changed:
[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
+ multipass@xenial-logind:~$ for i in {1..1000}; do sleep 0.1; ssh localhost
sleep 1 & 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.
--
You received this bug
[Touch-packages] [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
[Touch-packages] [Bug 1818527] Re: Stub resolver cache is corrupted
Some comments on the Autopkgtest regressions:
- lxc (armhf) fails due to the ftpmaster.internal mirror failing
- libvirt (armhf) fails for the same reason ("Unable to connect to
ftpmaster.internal:http")
- systemd (ppc64el) has been failing since before this patch was
introduced, and looking at the test logs it doesn't seem to be related
to the stub resolver
- network-manager (arm64) has been failing since previous systemd
versions (since systemd/237-3ubuntu10.21)
- gvfs (arm64) fails due to a permission error that should be unrelated
to the stub resolver ("GLib.Error('Not authorized to perform ope[83
chars]', 0) != True")
- gvfs (i386) has been failing since before this patch was introduced
After going through the autopkgtest logs for the above, it seems that
the failures are either due to autopkgtest infra, or have been
introduced by something other than the systemd upload.
** 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 systemd in Ubuntu.
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:
Fix Committed
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
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:
#1
On a Bionic host:
$ systemd-resolve --flush-caches
$ dig github.com CNAME
;; QUESTION SECTION:
;github.com. IN CNAME
;; Query time: 47 msec
.
$ dig github.com A
;; QUESTION SECTION:
;github.com. IN A
;; Query time: 0 msec
While in reality, if no non-existent CNAME result query has been made
first:
$ systemd-resolve --flush-caches
$ dig github.com
; QUESTION SECTION:
;github.com. IN A
;; ANSWER SECTION:
github.com. 59 IN A 192.30.253.112
;; Query time: 51 msec
#2
On a Bionic host:
$ systemd-resolve --flush-caches
$ dig github.com CNAME
$ dig github.com A
Build a lxd container with Cosmic/Disco/Eoan (systemd-240):
$ lxc launch ubuntu:cosmic cosmiclxd
$ lxd exec cosmiclxd bash
$ dig github.com A
;; QUESTION SECTION:
;github.com. IN A
;; Query time: 0 msec
Despite the fact that Cosmic and late has the proper systemd fix,
Cosmic/Disco/Eoan container can suffer from the bug too if the host is
Bionic (container uses the host as a DNS resolver).
So you may face the problem inside Cosmic/Disco/Eoan container, but
it's still the same Bionic systemd bug.
[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
[Touch-packages] [Bug 1818527] Re: Stub resolver cache is corrupted
Verified for Bionic: ubuntu@bionic:~$ dpkg -l | grep systemd ii systemd 237-3ubuntu10.23 amd64system and service manager ubuntu@bionic:~$ systemd-resolve --flush-caches ubuntu@bionic:~$ dig +noall +answer github.com CNAME ubuntu@bionic:~$ dig +noall +answer github.com A github.com. 18 IN A 140.82.118.4 ** Tags removed: verification-needed-bionic ** Tags added: verification-done-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/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: Fix Committed 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 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: #1 On a Bionic host: $ systemd-resolve --flush-caches $ dig github.com CNAME ;; QUESTION SECTION: ;github.com. IN CNAME ;; Query time: 47 msec . $ dig github.com A ;; QUESTION SECTION: ;github.com. IN A ;; Query time: 0 msec While in reality, if no non-existent CNAME result query has been made first: $ systemd-resolve --flush-caches $ dig github.com ; QUESTION SECTION: ;github.com. IN A ;; ANSWER SECTION: github.com. 59 IN A 192.30.253.112 ;; Query time: 51 msec #2 On a Bionic host: $ systemd-resolve --flush-caches $ dig github.com CNAME $ dig github.com A Build a lxd container with Cosmic/Disco/Eoan (systemd-240): $ lxc launch ubuntu:cosmic cosmiclxd $ lxd exec cosmiclxd bash $ dig github.com A ;; QUESTION SECTION: ;github.com. IN A ;; Query time: 0 msec Despite the fact that Cosmic and late has the proper systemd fix, Cosmic/Disco/Eoan container can suffer from the bug too if the host is Bionic (container uses the host as a DNS resolver). So you may face the problem inside Cosmic/Disco/Eoan container, but it's still the same Bionic systemd bug. [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
[Touch-packages] [Bug 1803203] Re: Support preferred_lft for IPv6 addresses
@rlaager I've started a PR discussion on Netplan.io's Github with your proposed changes as they seemed the best way forward for now. I don't expect this to get merged right away, as the maintainers might want to discuss the changes to the schema in further detail. In any case, this should at least start a discussion on getting this fixed in upstream netplan. https://github.com/CanonicalLtd/netplan/pull/89 -- 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/1803203 Title: Support preferred_lft for IPv6 addresses Status in netplan: New Status in netplan.io package in Ubuntu: In Progress Status in systemd package in Ubuntu: Fix Released Bug description: There doesn't currently seem to be any way to set the preferred_lft of an IPv6 address. With the "ip" command it might be, for example: # ip address add 2001:db8::2/32 dev eth0 preferred_lft 0 In a systemd unit file it might be: [Match] Name=eth0 [Network] Address=2001:db8::2/32 Gateway=2001:db8::1/32 PreferredLifetime=0 but I can't find any way to express this with netplan. This is commonly used for per-service IP addresses that should never be used as source addresses for outgoing traffic. To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1803203/+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 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 Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. 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 systemd | 229-4ubuntu4 | xe
[Touch-packages] [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 Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. 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/~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 1803203] Re: Support preferred_lft for IPv6 addresses
Some notes for reference: We might actually have some trouble in expressing the Lifetime of an Address in the Netplan schema. From the Netplan Reference [0] we can see that the 'addresses:' field accepts a list of mixed IPv4 and IPv6 addresses. We can't just add a 'lifetime:' field to the schema, because then we wouldn't have a way to link that value to one of the addresses in the mixed list. I can see a few different ways to change the configuration to accommodate the lifetime change: 1) Implement a list of lifetimes, which would "follow" the list of addresses (i.e. lifetime[0] corresponds to addresses[0] and so on) 2) Modify the address syntax inside the list to allow an optional lifetime, e.g.: addresses: [127.0.0.1 (forever), "2001:1::1/64 (0)"] 3) Allow the definition of an address+lifetime mapping and use that in the 'addresses' field, e.g.: myaddr: value: 127.0.0.1 lifetime: 0 ... addresses: [ myaddr, 2001:1::1/64 ] Option 1 has the obvious problem of matching one lifetime to a list of multiple addresses. Say we want to specify a lifetime to address number K in the list, would we need to specify a lifetime for all of them? How would we "skip" default lifetimes with this approach? Option 2 has the benefit of being somewhat compatible with the current schema in the sense that if no lifetime is specified, we can keep the current behavior. I feel like it would introduce a lot of complexity in the schema parsing code to sort the addresses from the lifetime though, and this might not be something that we want in a sensitive code section. Option 3 looks very flexible, but I'm not familiar enough with the schema and its parsing code to estimate the impact that would have. I think we would need quite a few significant changes, and I'm not really sure where we would place the 'myaddr' definition in the schema either. None of the above options feel like a good way to solve the lifetime problem, but I'm not sure we have an easy way to integrate that into the current netplan schema. Perhaps someone more experienced with the Netplan schema/codebase might offer better insight on how to tackle this issue. [0] https://netplan.io/reference -- 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/1803203 Title: Support preferred_lft for IPv6 addresses Status in netplan: New Status in netplan.io package in Ubuntu: In Progress Status in systemd package in Ubuntu: Fix Released Bug description: There doesn't currently seem to be any way to set the preferred_lft of an IPv6 address. With the "ip" command it might be, for example: # ip address add 2001:db8::2/32 dev eth0 preferred_lft 0 In a systemd unit file it might be: [Match] Name=eth0 [Network] Address=2001:db8::2/32 Gateway=2001:db8::1/32 PreferredLifetime=0 but I can't find any way to express this with netplan. This is commonly used for per-service IP addresses that should never be used as source addresses for outgoing traffic. To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1803203/+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 1822270] Re: Debconf readline frontend does not show options
Some comments on the autopkgtest regressions: # Disco - prometheus-blackbox-exporter and open-isns fail due to package dependency problems, unrelated to debconf - makedumpfile fails with "sudo: /tmp/autopkgtest-run-wrapper: command not found", which has happened in other previous autopkgtests (perl/5.28.1-6, file/1:5.35-4, elfutils/0.176-1). This does not seem to be related to the debconf update # Cosmic - murano seems to fail due to a syntax error in python3-murano, preventing dpkg from successfully configuring it. It has been failing since before the debconf change was introduced - cacti fails due to "ERROR PHP WARNING: A non-numeric value encountered in file: /usr/share/cacti/site/poller.php on line: 652", which is not related to the debconf changes - pbuilder is failing due to a missing Eoan script, might be related to LP: #1825994 - glibc fails due to a timeout on the test suite, and doesn't look related to our debconf changes # Bionic - pbuilder is still failing due to a missing Eoan script, might be related to LP: #1825994 - redmine is failing due to not being able to pull some packages for the test setup - makedumpfile has been failing since before the debconf changes with "makedumpfile: ERROR: crash test: kdump is not ready" - cacti fails due to "Unexpected output in /var/log/cacti/cacti.log: 05/08/2019 19:45:00 - AUTOM8 WARNING: The Network ID: 1 is disabled. You must use the 'force' option to force it's execution." - open-iscsi is failing since debconf/1.5.66, so it doesn't look to be caused by our changes ** 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 debconf in Ubuntu. https://bugs.launchpad.net/bugs/1822270 Title: Debconf readline frontend does not show options Status in debconf package in Ubuntu: Fix Released Status in debconf source package in Xenial: Fix Committed Status in debconf source package in Bionic: Fix Committed Status in debconf source package in Cosmic: Fix Committed Status in debconf source package in Disco: Fix Committed Status in debconf source package in Eoan: Fix Released Status in debconf package in Debian: Fix Released 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. Upstream commit: https://salsa.debian.org/pkg- debconf/debconf/commit/48c5ce38cfd5 [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
[Touch-packages] [Bug 1822270] Re: Debconf readline frontend does not show options
Validated debconf from bionic-proposed according to test case from description: root@bionic:~# dpkg -l | grep debconf ii debconf 1.5.66ubuntu1 all Debian configuration management system root@bionic:~# 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 ... A new version of /boot/grub/menu.lst is available, but the version installed currently has been locally modified. 1. install the package maintainer's version3. show the differences between the versions5. show a 3-way difference between available versions 7. start a new shell to examine the situation 2. keep the local version currently installed 4. show a side-by-side difference between the versions 6. do a 3-way merge between available versions (experimental) What would you like to do about menu.lst? ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to debconf in Ubuntu. https://bugs.launchpad.net/bugs/1822270 Title: Debconf readline frontend does not show options Status in debconf package in Ubuntu: Fix Released Status in debconf source package in Xenial: Fix Committed Status in debconf source package in Bionic: Fix Committed Status in debconf source package in Cosmic: Fix Committed Status in debconf source package in Disco: Fix Committed Status in debconf source package in Eoan: Fix Released Status in debconf package in Debian: Fix Released 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. Upstream commit: https://salsa.debian.org/pkg- debconf/debconf/commit/48c5ce38cfd5 [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
[Touch-packages] [Bug 1822270] Re: Debconf readline frontend does not show options
Validated debconf from xenial-proposed according to test case from description: root@xenial:~# dpkg -l | grep debconf ii debconf 1.5.58ubuntu2 all Debian configuration management system root@xenial:~# 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 ... A new version of /boot/grub/menu.lst is available, but the version installed currently has been locally modified. 1. install the package maintainer's version3. show the differences between the versions5. show a 3-way difference between available versions 7. start a new shell to examine the situation 2. keep the local version currently installed 4. show a side-by-side difference between the versions 6. do a 3-way merge between available versions (experimental) What would you like to do about menu.lst? ** Tags removed: verification-needed-xenial ** Tags added: verification-done-xenial -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to debconf in Ubuntu. https://bugs.launchpad.net/bugs/1822270 Title: Debconf readline frontend does not show options Status in debconf package in Ubuntu: Fix Released Status in debconf source package in Xenial: Fix Committed Status in debconf source package in Bionic: Fix Committed Status in debconf source package in Cosmic: Fix Committed Status in debconf source package in Disco: Fix Committed Status in debconf source package in Eoan: Fix Released Status in debconf package in Debian: Fix Released 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. Upstream commit: https://salsa.debian.org/pkg- debconf/debconf/commit/48c5ce38cfd5 [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
[Touch-packages] [Bug 1822270] Re: Debconf readline frontend does not show options
Validated debconf from cosmic-proposed according to test case from description: root@cosmic:~# dpkg -l | grep debconf ii debconf 1.5.69ubuntu1 all Debian configuration management system root@cosmic:~# 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 ... A new version of /boot/grub/menu.lst is available, but the version installed currently has been locally modified. 1. install the package maintainer's version3. show the differences between the versions5. show a 3-way difference between available versions 7. start a new shell to examine the situation 2. keep the local version currently installed 4. show a side-by-side difference between the versions 6. do a 3-way merge between available versions (experimental) What would you like to do about menu.lst? ** Tags removed: verification-needed-cosmic ** Tags added: verification-done-cosmic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to debconf in Ubuntu. https://bugs.launchpad.net/bugs/1822270 Title: Debconf readline frontend does not show options Status in debconf package in Ubuntu: Fix Released Status in debconf source package in Xenial: Fix Committed Status in debconf source package in Bionic: Fix Committed Status in debconf source package in Cosmic: Fix Committed Status in debconf source package in Disco: Fix Committed Status in debconf source package in Eoan: Fix Released Status in debconf package in Debian: Fix Released 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. Upstream commit: https://salsa.debian.org/pkg- debconf/debconf/commit/48c5ce38cfd5 [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.
[Touch-packages] [Bug 1822270] Re: Debconf readline frontend does not show options
Validated debconf from disco-proposed according to test case from description: root@disco:~# dpkg -l | grep debconf ii debconf 1.5.71ubuntu1 all Debian configuration management system 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 ... A new version of /boot/grub/menu.lst is available, but the version installed currently has been locally modified. 1. install the package maintainer's version3. show the differences between the versions5. show a 3-way difference between available versions 7. start a new shell to examine the situation 2. keep the local version currently installed 4. show a side-by-side difference between the versions 6. do a 3-way merge between available versions (experimental) What would you like to do about menu.lst? ** Tags removed: verification-needed-disco ** Tags added: verification-done-disco -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to debconf in Ubuntu. https://bugs.launchpad.net/bugs/1822270 Title: Debconf readline frontend does not show options Status in debconf package in Ubuntu: Fix Released Status in debconf source package in Xenial: Fix Committed Status in debconf source package in Bionic: Fix Committed Status in debconf source package in Cosmic: Fix Committed Status in debconf source package in Disco: Fix Committed Status in debconf source package in Eoan: Fix Released Status in debconf package in Debian: Fix Released 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. Upstream commit: https://salsa.debian.org/pkg- debconf/debconf/commit/48c5ce38cfd5 [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.
[Touch-packages] [Bug 1822270] Re: Debconf readline frontend does not show options
** Patch added: "lp1822270-cosmic.debdiff" https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1822270/+attachment/5262099/+files/lp1822270-cosmic.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to debconf in Ubuntu. https://bugs.launchpad.net/bugs/1822270 Title: Debconf readline frontend does not show options Status in debconf package in Ubuntu: Fix Released 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: Fix Released Status in debconf package in Debian: Fix Released 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. Upstream commit: https://salsa.debian.org/pkg- debconf/debconf/commit/48c5ce38cfd5 [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/~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 1822270] Re: Debconf readline frontend does not show options
** Patch added: "lp1822270-bionic.debdiff" https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1822270/+attachment/5262100/+files/lp1822270-bionic.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to debconf in Ubuntu. https://bugs.launchpad.net/bugs/1822270 Title: Debconf readline frontend does not show options Status in debconf package in Ubuntu: Fix Released 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: Fix Released Status in debconf package in Debian: Fix Released 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. Upstream commit: https://salsa.debian.org/pkg- debconf/debconf/commit/48c5ce38cfd5 [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/~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 1822270] Re: Debconf readline frontend does not show options
** Patch added: "lp1822270-xenial.debdiff" https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1822270/+attachment/5262101/+files/lp1822270-xenial.debdiff ** Tags added: sts-sponsor -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to debconf in Ubuntu. https://bugs.launchpad.net/bugs/1822270 Title: Debconf readline frontend does not show options Status in debconf package in Ubuntu: Fix Released 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: Fix Released Status in debconf package in Debian: Fix Released 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. Upstream commit: https://salsa.debian.org/pkg- debconf/debconf/commit/48c5ce38cfd5 [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/~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 1822270] Re: Debconf readline frontend does not show options
** Patch added: "lp1822270-disco.debdiff" https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1822270/+attachment/5262098/+files/lp1822270-disco.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to debconf in Ubuntu. https://bugs.launchpad.net/bugs/1822270 Title: Debconf readline frontend does not show options Status in debconf package in Ubuntu: Fix Released 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: Fix Released Status in debconf package in Debian: Fix Released 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. Upstream commit: https://salsa.debian.org/pkg- debconf/debconf/commit/48c5ce38cfd5 [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/~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 1822270] Re: Debconf readline frontend does not show options
** Description changed: [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. + + Upstream commit: https://salsa.debian.org/pkg- + debconf/debconf/commit/48c5ce38cfd5 [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? + 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`. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to debconf in Ubuntu. 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: Fix Committed 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. Upstream commit: https://salsa.debian.org/pkg- debconf/debconf/commit/48c5ce38cfd5 [Test Case] 1) Deploy a VM through e.g. uvt-kvm $ uvt-kvm create
[Touch-packages] [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 Ubuntu Touch seeded packages, which is subscribed to debconf in Ubuntu. 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/~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 1822270] Re: Debconf readline frontend does not show options
** Tags added: sts -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to debconf in Ubuntu. 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 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/~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 1822270] Re: Debconf readline frontend does not show options
** Description changed: - AFFECTED RELEASE: + [Impact] + debconf prompts the user for input before displaying options - Bionic + [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. - PACKAGE VERSION: + 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. - debconf - 1.5.66 + [Test Case] + 1) Deploy a VM through e.g. uvt-kvm + $ uvt-kvm create disco release=disco - DESCRIPTION: + 2) Remove the whiptail package to force the readline frontend in debconf + root@disco:~# apt remove --purge whiptail -y - 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. + 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`. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to debconf in Ubuntu. 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 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
[Touch-packages] [Bug 1822270] Re: Debconf readline frontend does not show options
** Changed in: debconf (Ubuntu Xenial) Status: New => Confirmed ** Changed in: debconf (Ubuntu Disco) Importance: Undecided => Medium ** Changed in: debconf (Ubuntu Disco) Importance: Medium => High ** Changed in: debconf (Ubuntu Bionic) Importance: Undecided => High ** Changed in: debconf (Ubuntu Cosmic) Importance: Undecided => High ** Changed in: debconf (Ubuntu Xenial) Importance: Undecided => High ** Changed in: debconf (Ubuntu Eoan) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: debconf (Ubuntu Disco) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: debconf (Ubuntu Cosmic) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: debconf (Ubuntu Bionic) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) ** Changed in: debconf (Ubuntu Xenial) Assignee: (unassigned) => Heitor Alves de Siqueira (halves) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to debconf in Ubuntu. 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 Bug description: AFFECTED RELEASE: Bionic PACKAGE VERSION: debconf - 1.5.66 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/~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 1822270] Re: Debconf readline frontend does not show options
** Also affects: debconf (Ubuntu Eoan) Importance: High Status: Confirmed ** Also affects: debconf (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: debconf (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: debconf (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: debconf (Ubuntu Disco) Importance: Undecided Status: New ** Changed in: debconf (Ubuntu Disco) Status: New => Confirmed ** Changed in: debconf (Ubuntu Cosmic) Status: New => Confirmed ** Changed in: debconf (Ubuntu Bionic) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to debconf in Ubuntu. 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: New 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 Bug description: AFFECTED RELEASE: Bionic PACKAGE VERSION: debconf - 1.5.66 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/~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 1821343] Re: slapd process failure is not detected by systemd
There's a failing autopkgtest for gnupg2 that flagged this openldap update for cosmic, but openldap looks fine. Checking autopkgtest logs for gnupg2 [0], the tests were failing before the openldap update, and it's not related to this fix. The culprit seems to be a dependency problem with wine/libwine [1]. [0] http://autopkgtest.ubuntu.com/packages/g/gnupg2/cosmic/amd64 [1] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/amd64/g/gnupg2/20190416_135202_50915@/log.gz -- 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/1821343 Title: slapd process failure is not detected by systemd Status in openldap package in Ubuntu: Fix Released Status in openldap source package in Xenial: Fix Committed Status in openldap source package in Bionic: Fix Committed Status in openldap source package in Cosmic: Fix Committed Status in openldap package in Debian: New Bug description: [Impact] Systemd service reports slapd as active, even though it may have failed [Description] The slapd package for OpenLDAP is shipped with a SysV-style init script (/etc/init.d/slapd). Systemd automatically converts this to a systemd service by generating the unit file using the systemd-sysv-generator(8) utility. The generated unit file contains Type=forking and RemainAfterExit=yes directives. If the slapd daemon process exits due to some failure (e.g., it receives a SIGTERM or SIGKILL), the failure is not detected properly by systemd. The service is still reported as active even though the child (daemon) process has exited with a signal. We can easily fix this by including a proper systemd service file for slapd in the openldap package. Since the init.d script already does most of the necessary work (parsing configs, setting up PID files, etc.), we don't need anything complicated for the systemd unit file. Just making sure that RemainAfterExit is set to "no" makes the systemd service behave in the expected way. [Test Case] 1) Deploy a disco container $ lxc launch images:ubuntu/disco disco 2) Install slapd ubuntu@disco:~$ sudo apt update && sudo apt install slapd -y 3) Verify that slapd is running with the auto-generated service ubuntu@disco:~$ systemctl status slapd ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol) Loaded: loaded (/etc/init.d/slapd; generated) Active: active (running) since Fri 2019-03-22 11:51:22 UTC; 40min ago Docs: man:systemd-sysv-generator(8) Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS) Tasks: 3 (limit: 4915) Memory: 712.6M CGroup: /system.slice/slapd.service └─1109 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d 4) SIGKILL the slapd process (PID is displayed in systemctl status output) ubuntu@disco:~$ sudo kill -9 1109 5) Check if systemd service lists slapd as still active, even though it was terminated ubuntu@disco:~$ systemctl status slapd ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol) Loaded: loaded (/etc/init.d/slapd; generated) Active: active (exited) since Fri 2019-03-22 11:51:22 UTC; 42min ago Docs: man:systemd-sysv-generator(8) Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS) 6) Check if systemd has loaded both /run/systemd/generator.late/slapd.service & /usr/lib/systemd/system/slapd.service.d/slapd-remain-after-exit.conf $ systemctl cat slapd [Regression Potential] The regression potential for this fix should be very low, if we keep the new systemd unit file close to the one generated by systemd-sysv-generator(8). The only significant change would be the RemainAfterExit directive, and this should make the slapd service behave like a "normal" forking service. Nonetheless, we'll perform scripted test runs to make sure no regressions arise. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+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 1821343] Re: slapd process failure is not detected by systemd
Verified according to test case in description for xenial: root@xenial:~# dpkg -l | grep slapd ii slapd2.4.42+dfsg-2ubuntu3.5 amd64OpenLDAP server (slapd) root@xenial:~# systemctl status slapd ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol) Loaded: loaded (/etc/init.d/slapd; bad; vendor preset: enabled) Drop-In: /lib/systemd/system/slapd.service.d └─slapd-remain-after-exit.conf Active: active (running) since Mon 2019-04-22 20:23:10 UTC; 14s ago Docs: man:systemd-sysv-generator(8) CGroup: /system.slice/slapd.service └─5920 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d root@xenial:~# kill -9 5920 root@xenial:~# systemctl status slapd ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol) Loaded: loaded (/etc/init.d/slapd; bad; vendor preset: enabled) Drop-In: /lib/systemd/system/slapd.service.d └─slapd-remain-after-exit.conf Active: inactive (dead) since Mon 2019-04-22 20:23:30 UTC; 1s ago Docs: man:systemd-sysv-generator(8) Process: 5989 ExecStop=/etc/init.d/slapd stop (code=exited, status=0/SUCCESS) root@xenial:~# systemctl cat slapd # /run/systemd/generator.late/slapd.service # Automatically generated by systemd-sysv-generator [Unit] Documentation=man:systemd-sysv-generator(8) SourcePath=/etc/init.d/slapd Description=LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol) Before=multi-user.target Before=multi-user.target Before=multi-user.target Before=graphical.target Before=shutdown.target After=remote-fs.target After=network-online.target After=systemd-journald-dev-log.socket Wants=network-online.target Conflicts=shutdown.target [Service] Type=forking Restart=no TimeoutSec=5min IgnoreSIGPIPE=no KillMode=process GuessMainPID=no RemainAfterExit=yes ExecStart=/etc/init.d/slapd start ExecStop=/etc/init.d/slapd stop # /lib/systemd/system/slapd.service.d/slapd-remain-after-exit.conf [Service] Type=forking RemainAfterExit=no ** Tags removed: verification-needed verification-needed-xenial ** Tags added: verification-done verification-done-xenial -- 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/1821343 Title: slapd process failure is not detected by systemd Status in openldap package in Ubuntu: Fix Released Status in openldap source package in Xenial: Fix Committed Status in openldap source package in Bionic: Fix Committed Status in openldap source package in Cosmic: Fix Committed Status in openldap package in Debian: New Bug description: [Impact] Systemd service reports slapd as active, even though it may have failed [Description] The slapd package for OpenLDAP is shipped with a SysV-style init script (/etc/init.d/slapd). Systemd automatically converts this to a systemd service by generating the unit file using the systemd-sysv-generator(8) utility. The generated unit file contains Type=forking and RemainAfterExit=yes directives. If the slapd daemon process exits due to some failure (e.g., it receives a SIGTERM or SIGKILL), the failure is not detected properly by systemd. The service is still reported as active even though the child (daemon) process has exited with a signal. We can easily fix this by including a proper systemd service file for slapd in the openldap package. Since the init.d script already does most of the necessary work (parsing configs, setting up PID files, etc.), we don't need anything complicated for the systemd unit file. Just making sure that RemainAfterExit is set to "no" makes the systemd service behave in the expected way. [Test Case] 1) Deploy a disco container $ lxc launch images:ubuntu/disco disco 2) Install slapd ubuntu@disco:~$ sudo apt update && sudo apt install slapd -y 3) Verify that slapd is running with the auto-generated service ubuntu@disco:~$ systemctl status slapd ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol) Loaded: loaded (/etc/init.d/slapd; generated) Active: active (running) since Fri 2019-03-22 11:51:22 UTC; 40min ago Docs: man:systemd-sysv-generator(8) Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS) Tasks: 3 (limit: 4915) Memory: 712.6M CGroup: /system.slice/slapd.service └─1109 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d 4) SIGKILL the slapd process (PID is displayed in systemctl status output) ubuntu@disco:~$ sudo kill -9 1109 5) Check if systemd service lists slapd as still active, even though it was terminated ubuntu@disco:~$ systemctl status slapd ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access
[Touch-packages] [Bug 1821343] Re: slapd process failure is not detected by systemd
Verified according to test case in description for bionic: root@bionic:~# dpkg -l | grep slapd ii slapd2.4.45+dfsg-1ubuntu1.2amd64 OpenLDAP server (slapd) root@bionic:~# systemctl status slapd ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol) Loaded: loaded (/etc/init.d/slapd; generated) Drop-In: /lib/systemd/system/slapd.service.d └─slapd-remain-after-exit.conf Active: active (running) since Mon 2019-04-22 20:15:10 UTC; 4min 23s ago Docs: man:systemd-sysv-generator(8) Tasks: 3 (limit: 4915) CGroup: /system.slice/slapd.service └─907 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d root@bionic:~# kill -9 907 root@bionic:~# systemctl status slapd ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol) Loaded: loaded (/etc/init.d/slapd; generated) Drop-In: /lib/systemd/system/slapd.service.d └─slapd-remain-after-exit.conf Active: inactive (dead) since Mon 2019-04-22 20:19:40 UTC; 1s ago Docs: man:systemd-sysv-generator(8) Process: 1011 ExecStop=/etc/init.d/slapd stop (code=exited, status=0/SUCCESS) root@bionic:~# systemctl cat slapd # /run/systemd/generator.late/slapd.service # Automatically generated by systemd-sysv-generator [Unit] Documentation=man:systemd-sysv-generator(8) SourcePath=/etc/init.d/slapd Description=LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol) Before=multi-user.target Before=multi-user.target Before=multi-user.target Before=graphical.target After=remote-fs.target After=network-online.target Wants=network-online.target [Service] Type=forking Restart=no TimeoutSec=5min IgnoreSIGPIPE=no KillMode=process GuessMainPID=no RemainAfterExit=yes SuccessExitStatus=5 6 ExecStart=/etc/init.d/slapd start ExecStop=/etc/init.d/slapd stop # /lib/systemd/system/slapd.service.d/slapd-remain-after-exit.conf [Service] Type=forking RemainAfterExit=no ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- 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/1821343 Title: slapd process failure is not detected by systemd Status in openldap package in Ubuntu: Fix Released Status in openldap source package in Xenial: Fix Committed Status in openldap source package in Bionic: Fix Committed Status in openldap source package in Cosmic: Fix Committed Status in openldap package in Debian: New Bug description: [Impact] Systemd service reports slapd as active, even though it may have failed [Description] The slapd package for OpenLDAP is shipped with a SysV-style init script (/etc/init.d/slapd). Systemd automatically converts this to a systemd service by generating the unit file using the systemd-sysv-generator(8) utility. The generated unit file contains Type=forking and RemainAfterExit=yes directives. If the slapd daemon process exits due to some failure (e.g., it receives a SIGTERM or SIGKILL), the failure is not detected properly by systemd. The service is still reported as active even though the child (daemon) process has exited with a signal. We can easily fix this by including a proper systemd service file for slapd in the openldap package. Since the init.d script already does most of the necessary work (parsing configs, setting up PID files, etc.), we don't need anything complicated for the systemd unit file. Just making sure that RemainAfterExit is set to "no" makes the systemd service behave in the expected way. [Test Case] 1) Deploy a disco container $ lxc launch images:ubuntu/disco disco 2) Install slapd ubuntu@disco:~$ sudo apt update && sudo apt install slapd -y 3) Verify that slapd is running with the auto-generated service ubuntu@disco:~$ systemctl status slapd ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol) Loaded: loaded (/etc/init.d/slapd; generated) Active: active (running) since Fri 2019-03-22 11:51:22 UTC; 40min ago Docs: man:systemd-sysv-generator(8) Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS) Tasks: 3 (limit: 4915) Memory: 712.6M CGroup: /system.slice/slapd.service └─1109 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d 4) SIGKILL the slapd process (PID is displayed in systemctl status output) ubuntu@disco:~$ sudo kill -9 1109 5) Check if systemd service lists slapd as still active, even though it was terminated ubuntu@disco:~$ systemctl status slapd ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol) Loaded: loaded (/etc/init.d/slapd; generated) Active: active (exited) since Fri 2019-03-22 11:51:22 UTC;
[Touch-packages] [Bug 1821343] Re: slapd process failure is not detected by systemd
Verified according to test case in description for cosmic: root@cosmic:~# dpkg -l | grep slapd ii slapd 2.4.46+dfsg-5ubuntu1.2 amd64 OpenLDAP server (slapd) root@cosmic:~# systemctl status slapd ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol) Loaded: loaded (/etc/init.d/slapd; generated) Drop-In: /lib/systemd/system/slapd.service.d └─slapd-remain-after-exit.conf Active: active (running) since Mon 2019-04-22 20:15:01 UTC; 19s ago Docs: man:systemd-sysv-generator(8) Tasks: 3 (limit: 4915) Memory: 612.7M CGroup: /system.slice/slapd.service └─2061 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d root@cosmic:~# kill -9 2061 root@cosmic:~# systemctl status slapd ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol) Loaded: loaded (/etc/init.d/slapd; generated) Drop-In: /lib/systemd/system/slapd.service.d └─slapd-remain-after-exit.conf Active: inactive (dead) since Mon 2019-04-22 20:15:40 UTC; 4s ago Docs: man:systemd-sysv-generator(8) Process: 2145 ExecStop=/etc/init.d/slapd stop (code=exited, status=0/SUCCESS) root@cosmic:~# systemctl cat slapd # /run/systemd/generator.late/slapd.service # Automatically generated by systemd-sysv-generator [Unit] Documentation=man:systemd-sysv-generator(8) SourcePath=/etc/init.d/slapd Description=LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol) Before=multi-user.target Before=multi-user.target Before=multi-user.target Before=graphical.target After=remote-fs.target After=network-online.target Wants=network-online.target [Service] Type=forking Restart=no TimeoutSec=5min IgnoreSIGPIPE=no KillMode=process GuessMainPID=no RemainAfterExit=yes SuccessExitStatus=5 6 ExecStart=/etc/init.d/slapd start ExecStop=/etc/init.d/slapd stop # /lib/systemd/system/slapd.service.d/slapd-remain-after-exit.conf [Service] Type=forking RemainAfterExit=no ** Tags removed: verification-needed-cosmic ** Tags added: verification-done-cosmic -- 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/1821343 Title: slapd process failure is not detected by systemd Status in openldap package in Ubuntu: Fix Released Status in openldap source package in Xenial: Fix Committed Status in openldap source package in Bionic: Fix Committed Status in openldap source package in Cosmic: Fix Committed Status in openldap package in Debian: New Bug description: [Impact] Systemd service reports slapd as active, even though it may have failed [Description] The slapd package for OpenLDAP is shipped with a SysV-style init script (/etc/init.d/slapd). Systemd automatically converts this to a systemd service by generating the unit file using the systemd-sysv-generator(8) utility. The generated unit file contains Type=forking and RemainAfterExit=yes directives. If the slapd daemon process exits due to some failure (e.g., it receives a SIGTERM or SIGKILL), the failure is not detected properly by systemd. The service is still reported as active even though the child (daemon) process has exited with a signal. We can easily fix this by including a proper systemd service file for slapd in the openldap package. Since the init.d script already does most of the necessary work (parsing configs, setting up PID files, etc.), we don't need anything complicated for the systemd unit file. Just making sure that RemainAfterExit is set to "no" makes the systemd service behave in the expected way. [Test Case] 1) Deploy a disco container $ lxc launch images:ubuntu/disco disco 2) Install slapd ubuntu@disco:~$ sudo apt update && sudo apt install slapd -y 3) Verify that slapd is running with the auto-generated service ubuntu@disco:~$ systemctl status slapd ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol) Loaded: loaded (/etc/init.d/slapd; generated) Active: active (running) since Fri 2019-03-22 11:51:22 UTC; 40min ago Docs: man:systemd-sysv-generator(8) Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS) Tasks: 3 (limit: 4915) Memory: 712.6M CGroup: /system.slice/slapd.service └─1109 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d 4) SIGKILL the slapd process (PID is displayed in systemctl status output) ubuntu@disco:~$ sudo kill -9 1109 5) Check if systemd service lists slapd as still active, even though it was terminated ubuntu@disco:~$ systemctl status slapd ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol) Loaded: loaded (/etc/init.d/slapd; generated) Active: active (exited) since Fri
[Touch-packages] [Bug 1821343] Re: slapd process failure is not detected by systemd
** Patch added: "lp1821343-bionic.debdiff" https://bugs.launchpad.net/debian/+source/openldap/+bug/1821343/+attachment/5254687/+files/lp1821343-bionic.debdiff -- 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/1821343 Title: slapd process failure is not detected by systemd Status in openldap package in Ubuntu: Fix Released Status in openldap source package in Xenial: Confirmed Status in openldap source package in Bionic: Confirmed Status in openldap source package in Cosmic: Confirmed Status in openldap package in Debian: New Bug description: [Impact] Systemd service reports slapd as active, even though it may have failed [Description] The slapd package for OpenLDAP is shipped with a SysV-style init script (/etc/init.d/slapd). Systemd automatically converts this to a systemd service by generating the unit file using the systemd-sysv-generator(8) utility. The generated unit file contains Type=forking and RemainAfterExit=yes directives. If the slapd daemon process exits due to some failure (e.g., it receives a SIGTERM or SIGKILL), the failure is not detected properly by systemd. The service is still reported as active even though the child (daemon) process has exited with a signal. We can easily fix this by including a proper systemd service file for slapd in the openldap package. Since the init.d script already does most of the necessary work (parsing configs, setting up PID files, etc.), we don't need anything complicated for the systemd unit file. Just making sure that RemainAfterExit is set to "no" makes the systemd service behave in the expected way. [Test Case] 1) Deploy a disco container $ lxc launch images:ubuntu/disco disco 2) Install slapd ubuntu@disco:~$ sudo apt update && sudo apt install slapd -y 3) Verify that slapd is running with the auto-generated service ubuntu@disco:~$ systemctl status slapd ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol) Loaded: loaded (/etc/init.d/slapd; generated) Active: active (running) since Fri 2019-03-22 11:51:22 UTC; 40min ago Docs: man:systemd-sysv-generator(8) Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS) Tasks: 3 (limit: 4915) Memory: 712.6M CGroup: /system.slice/slapd.service └─1109 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d 4) SIGKILL the slapd process (PID is displayed in systemctl status output) ubuntu@disco:~$ sudo kill -9 1109 5) Check if systemd service lists slapd as still active, even though it was terminated ubuntu@disco:~$ systemctl status slapd ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol) Loaded: loaded (/etc/init.d/slapd; generated) Active: active (exited) since Fri 2019-03-22 11:51:22 UTC; 42min ago Docs: man:systemd-sysv-generator(8) Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS) 6) Check if systemd has loaded both /run/systemd/generator.late/slapd.service & /usr/lib/systemd/system/slapd.service.d/slapd-remain-after-exit.conf $ systemctl cat slapd [Regression Potential] The regression potential for this fix should be very low, if we keep the new systemd unit file close to the one generated by systemd-sysv-generator(8). The only significant change would be the RemainAfterExit directive, and this should make the slapd service behave like a "normal" forking service. Nonetheless, we'll perform scripted test runs to make sure no regressions arise. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+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 1821343] Re: slapd process failure is not detected by systemd
** Patch added: "lp1821343-cosmic.debdiff" https://bugs.launchpad.net/debian/+source/openldap/+bug/1821343/+attachment/5254686/+files/lp1821343-cosmic.debdiff -- 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/1821343 Title: slapd process failure is not detected by systemd Status in openldap package in Ubuntu: Fix Released Status in openldap source package in Xenial: Confirmed Status in openldap source package in Bionic: Confirmed Status in openldap source package in Cosmic: Confirmed Status in openldap package in Debian: New Bug description: [Impact] Systemd service reports slapd as active, even though it may have failed [Description] The slapd package for OpenLDAP is shipped with a SysV-style init script (/etc/init.d/slapd). Systemd automatically converts this to a systemd service by generating the unit file using the systemd-sysv-generator(8) utility. The generated unit file contains Type=forking and RemainAfterExit=yes directives. If the slapd daemon process exits due to some failure (e.g., it receives a SIGTERM or SIGKILL), the failure is not detected properly by systemd. The service is still reported as active even though the child (daemon) process has exited with a signal. We can easily fix this by including a proper systemd service file for slapd in the openldap package. Since the init.d script already does most of the necessary work (parsing configs, setting up PID files, etc.), we don't need anything complicated for the systemd unit file. Just making sure that RemainAfterExit is set to "no" makes the systemd service behave in the expected way. [Test Case] 1) Deploy a disco container $ lxc launch images:ubuntu/disco disco 2) Install slapd ubuntu@disco:~$ sudo apt update && sudo apt install slapd -y 3) Verify that slapd is running with the auto-generated service ubuntu@disco:~$ systemctl status slapd ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol) Loaded: loaded (/etc/init.d/slapd; generated) Active: active (running) since Fri 2019-03-22 11:51:22 UTC; 40min ago Docs: man:systemd-sysv-generator(8) Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS) Tasks: 3 (limit: 4915) Memory: 712.6M CGroup: /system.slice/slapd.service └─1109 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d 4) SIGKILL the slapd process (PID is displayed in systemctl status output) ubuntu@disco:~$ sudo kill -9 1109 5) Check if systemd service lists slapd as still active, even though it was terminated ubuntu@disco:~$ systemctl status slapd ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol) Loaded: loaded (/etc/init.d/slapd; generated) Active: active (exited) since Fri 2019-03-22 11:51:22 UTC; 42min ago Docs: man:systemd-sysv-generator(8) Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS) 6) Check if systemd has loaded both /run/systemd/generator.late/slapd.service & /usr/lib/systemd/system/slapd.service.d/slapd-remain-after-exit.conf $ systemctl cat slapd [Regression Potential] The regression potential for this fix should be very low, if we keep the new systemd unit file close to the one generated by systemd-sysv-generator(8). The only significant change would be the RemainAfterExit directive, and this should make the slapd service behave like a "normal" forking service. Nonetheless, we'll perform scripted test runs to make sure no regressions arise. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+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 1821343] Re: slapd process failure is not detected by systemd
** Patch added: "lp1821343-xenial.debdiff" https://bugs.launchpad.net/debian/+source/openldap/+bug/1821343/+attachment/5254688/+files/lp1821343-xenial.debdiff ** Patch removed: "lp1821343-disco.debdiff" https://bugs.launchpad.net/debian/+source/openldap/+bug/1821343/+attachment/5254240/+files/lp1821343-disco.debdiff -- 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/1821343 Title: slapd process failure is not detected by systemd Status in openldap package in Ubuntu: Fix Released Status in openldap source package in Xenial: Confirmed Status in openldap source package in Bionic: Confirmed Status in openldap source package in Cosmic: Confirmed Status in openldap package in Debian: New Bug description: [Impact] Systemd service reports slapd as active, even though it may have failed [Description] The slapd package for OpenLDAP is shipped with a SysV-style init script (/etc/init.d/slapd). Systemd automatically converts this to a systemd service by generating the unit file using the systemd-sysv-generator(8) utility. The generated unit file contains Type=forking and RemainAfterExit=yes directives. If the slapd daemon process exits due to some failure (e.g., it receives a SIGTERM or SIGKILL), the failure is not detected properly by systemd. The service is still reported as active even though the child (daemon) process has exited with a signal. We can easily fix this by including a proper systemd service file for slapd in the openldap package. Since the init.d script already does most of the necessary work (parsing configs, setting up PID files, etc.), we don't need anything complicated for the systemd unit file. Just making sure that RemainAfterExit is set to "no" makes the systemd service behave in the expected way. [Test Case] 1) Deploy a disco container $ lxc launch images:ubuntu/disco disco 2) Install slapd ubuntu@disco:~$ sudo apt update && sudo apt install slapd -y 3) Verify that slapd is running with the auto-generated service ubuntu@disco:~$ systemctl status slapd ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol) Loaded: loaded (/etc/init.d/slapd; generated) Active: active (running) since Fri 2019-03-22 11:51:22 UTC; 40min ago Docs: man:systemd-sysv-generator(8) Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS) Tasks: 3 (limit: 4915) Memory: 712.6M CGroup: /system.slice/slapd.service └─1109 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d 4) SIGKILL the slapd process (PID is displayed in systemctl status output) ubuntu@disco:~$ sudo kill -9 1109 5) Check if systemd service lists slapd as still active, even though it was terminated ubuntu@disco:~$ systemctl status slapd ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol) Loaded: loaded (/etc/init.d/slapd; generated) Active: active (exited) since Fri 2019-03-22 11:51:22 UTC; 42min ago Docs: man:systemd-sysv-generator(8) Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS) 6) Check if systemd has loaded both /run/systemd/generator.late/slapd.service & /usr/lib/systemd/system/slapd.service.d/slapd-remain-after-exit.conf $ systemctl cat slapd [Regression Potential] The regression potential for this fix should be very low, if we keep the new systemd unit file close to the one generated by systemd-sysv-generator(8). The only significant change would be the RemainAfterExit directive, and this should make the slapd service behave like a "normal" forking service. Nonetheless, we'll perform scripted test runs to make sure no regressions arise. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+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 1821343] Re: slapd process failure is not detected by systemd
debdiff v2 with fixed author information ** Patch added: "v2-lp1821343-disco.debdiff" https://bugs.launchpad.net/debian/+source/openldap/+bug/1821343/+attachment/5254440/+files/v2-lp1821343-disco.debdiff -- 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/1821343 Title: slapd process failure is not detected by systemd Status in openldap package in Ubuntu: Confirmed Status in openldap source package in Xenial: Confirmed Status in openldap source package in Bionic: Confirmed Status in openldap source package in Cosmic: Confirmed Status in openldap package in Debian: New Bug description: [Impact] Systemd service reports slapd as active, even though it may have failed [Description] The slapd package for OpenLDAP is shipped with a SysV-style init script (/etc/init.d/slapd). Systemd automatically converts this to a systemd service by generating the unit file using the systemd-sysv-generator(8) utility. The generated unit file contains Type=forking and RemainAfterExit=yes directives. If the slapd daemon process exits due to some failure (e.g., it receives a SIGTERM or SIGKILL), the failure is not detected properly by systemd. The service is still reported as active even though the child (daemon) process has exited with a signal. We can easily fix this by including a proper systemd service file for slapd in the openldap package. Since the init.d script already does most of the necessary work (parsing configs, setting up PID files, etc.), we don't need anything complicated for the systemd unit file. Just making sure that RemainAfterExit is set to "no" makes the systemd service behave in the expected way. [Test Case] 1) Deploy a disco container $ lxc launch images:ubuntu/disco disco 2) Install slapd ubuntu@disco:~$ sudo apt update && sudo apt install slapd -y 3) Verify that slapd is running with the auto-generated service ubuntu@disco:~$ systemctl status slapd ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol) Loaded: loaded (/etc/init.d/slapd; generated) Active: active (running) since Fri 2019-03-22 11:51:22 UTC; 40min ago Docs: man:systemd-sysv-generator(8) Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS) Tasks: 3 (limit: 4915) Memory: 712.6M CGroup: /system.slice/slapd.service └─1109 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d 4) SIGKILL the slapd process (PID is displayed in systemctl status output) ubuntu@disco:~$ sudo kill -9 1109 5) Check if systemd service lists slapd as still active, even though it was terminated ubuntu@disco:~$ systemctl status slapd ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol) Loaded: loaded (/etc/init.d/slapd; generated) Active: active (exited) since Fri 2019-03-22 11:51:22 UTC; 42min ago Docs: man:systemd-sysv-generator(8) Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS) 6) Check if systemd has loaded both /run/systemd/generator.late/slapd.service & /usr/lib/systemd/system/slapd.service.d/slapd-remain-after-exit.conf $ systemctl cat slapd [Regression Potential] The regression potential for this fix should be very low, if we keep the new systemd unit file close to the one generated by systemd-sysv-generator(8). The only significant change would be the RemainAfterExit directive, and this should make the slapd service behave like a "normal" forking service. Nonetheless, we'll perform scripted test runs to make sure no regressions arise. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+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
