[Touch-packages] [Bug 1906364] Re: unattended-upgrade still restarts blacklisted daemons
I'd like to give you all an update and outline our plans for this. The Canonical server team has made analysis of this issue a top priority. We've identified and tested out several possible theories. Our findings suggest that the breakage involves two distinct issues, one the BindTo= issue mentioned above, the other caused by a bug in the docker.io package causing the service to stop on package upgrade; see specifically the service stop command at the end of /var/lib/dpkg/info/docker.io.prerm. We'll use LP: #1870514 to track the former issue, and #1906364 the latter. LP: #1658691 gives some past background for reference. The tricky part is that unfortunately any change we make to docker.io requires the running of the prerm script (the version of the script already present on your system, not the one we'd be installing), and thus triggers the bug. In other words, updating your system to prevent the bug will cause one more docker stop. Thereafter, the upgrade will not restart the service when rolling out CVE fixes to either containerd or docker.io; it may prompt to do so if running interactively (e.g. https://imgur.com/2Za5dbQ.png), otherwise it should respect the debconf setting. We would appreciate feedback, testing and/or review of the proposed fix, available in this PPA: https://launchpad.net/~bryce/+archive/ubuntu/containerd-sru-lp1870514 -docker-dh/ ** Also affects: unattended-upgrades (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: docker.io (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: containerd (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: unattended-upgrades (Ubuntu Hirsute) Importance: Undecided Status: Won't Fix ** Also affects: docker.io (Ubuntu Hirsute) Importance: Undecided Status: Confirmed ** Also affects: containerd (Ubuntu Hirsute) Importance: Undecided Status: Confirmed ** Also affects: unattended-upgrades (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: docker.io (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: containerd (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: unattended-upgrades (Ubuntu Groovy) Importance: Undecided Status: New ** Also affects: docker.io (Ubuntu Groovy) Importance: Undecided Status: New ** Also affects: containerd (Ubuntu Groovy) Importance: Undecided Status: New ** Also affects: unattended-upgrades (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: docker.io (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: containerd (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: unattended-upgrades (Ubuntu Groovy) Status: New => Won't Fix ** No longer affects: containerd (Ubuntu) ** Changed in: unattended-upgrades (Ubuntu Focal) Status: New => Won't Fix ** Changed in: unattended-upgrades (Ubuntu Bionic) Status: New => Won't Fix ** Changed in: unattended-upgrades (Ubuntu Xenial) Status: New => Won't Fix ** Changed in: docker.io (Ubuntu Xenial) Importance: Undecided => High ** Changed in: docker.io (Ubuntu Xenial) Status: New => In Progress ** Changed in: docker.io (Ubuntu Xenial) Assignee: (unassigned) => Bryce Harrington (bryce) ** Changed in: docker.io (Ubuntu Xenial) Importance: High => Critical ** Changed in: docker.io (Ubuntu Bionic) Importance: Undecided => Critical ** Changed in: docker.io (Ubuntu Bionic) Status: New => In Progress ** Changed in: docker.io (Ubuntu Focal) Importance: Undecided => Critical ** Changed in: docker.io (Ubuntu Focal) Status: New => In Progress ** Changed in: docker.io (Ubuntu Groovy) Importance: Undecided => Critical ** Changed in: docker.io (Ubuntu Groovy) Status: New => In Progress ** Changed in: docker.io (Ubuntu Hirsute) Importance: Undecided => Critical ** Changed in: docker.io (Ubuntu Hirsute) Status: Confirmed => In Progress ** Changed in: docker.io (Ubuntu Hirsute) Assignee: (unassigned) => Bryce Harrington (bryce) ** No longer affects: containerd (Ubuntu Xenial) ** No longer affects: containerd (Ubuntu Bionic) ** No longer affects: containerd (Ubuntu Focal) ** No longer affects: containerd (Ubuntu Groovy) ** No longer affects: containerd (Ubuntu Hirsute) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1906364 Title: unattended-upgrade still restarts blacklisted daemons Status in docker.io package in Ubuntu: In Progress Status in unattended-upgrades package in Ubuntu: Won't Fix Status in docker.io source package in Xenial: In Progress Status in unattended-upgrades source package in Xen
[Touch-packages] [Bug 1906364] Re: unattended-upgrade still restarts blacklisted daemons
This sounds like another dupe of https://bugs.launchpad.net/ubuntu/+source/containerd/+bug/1870514 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/1906364 Title: unattended-upgrade still restarts blacklisted daemons Status in containerd package in Ubuntu: Confirmed Status in docker.io package in Ubuntu: Confirmed Status in unattended-upgrades package in Ubuntu: Won't Fix Bug description: Hello, Today plenty of our systems running ubuntu 20.04 were restarting the docker daemon, even if i blacklisted the docker package. Since docker has an dependency on containerd thats the reason why it was restarted. IMO the blacklist should also check the full tree of dependencies... This should NOT happen! From the log you find: 2020-12-01 06:40:13,881 INFO Starting unattended upgrades script 2020-12-01 06:40:13,882 INFO Allowed origins are: o=Ubuntu,a=focal, o=Ubuntu,a=focal-security, o=UbuntuESMApps,a=focal-apps-security, o=UbuntuESM,a=focal-infra-security 2020-12-01 06:40:13,882 INFO Initial blacklist: docker docker.io 2020-12-01 06:40:13,882 INFO Initial whitelist (not strict): 2020-12-01 06:40:19,139 INFO Packages that will be upgraded: containerd qemu-block-extra qemu-kvm qemu-system-common qemu-system-data qemu-system-gui qemu-system-x86 qemu-utils 2020-12-01 06:40:19,140 INFO Writing dpkg log to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log 2020-12-01 06:40:46,996 INFO All upgrades installed 2020-12-01 06:40:50,732 INFO Starting unattended upgrades script 2020-12-01 06:40:50,732 INFO Allowed origins are: o=Ubuntu,a=focal, o=Ubuntu,a=focal-security, o=UbuntuESMApps,a=focal-apps-security, o=UbuntuESM,a=focal-infra-security 2020-12-01 06:40:50,733 INFO Initial blacklist: docker docker.io 2020-12-01 06:40:50,733 INFO Initial whitelist (not strict): Also this happened for us on plenty of our servers almost at the same (why the unattended updates are not spread over time?), which destroyed the second time an production environment. This is not how unattended-upgraded should be, sadly this package lost our trust and we disable it and schedule the 'unattended updates' now on our own. PS: Not to say that on some servers the docker daemon did not even restart.. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/containerd/+bug/1906364/+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 1905088] Re: failed to install/upgrade: sshd_config: line 13: Bad configuration option
Hi Huy, The bug report appears to indicate some sort of syntax error in your /etc/ssh/sshd_config file. What's on line 13 of that file? SSHDConfig: Error: command ['/usr/sbin/sshd', '-T'] failed with exit code 255: /etc/ssh/sshd_config: line 13: Bad configuration option: Include /etc/ssh/sshd_config: terminating, 1 bad configuration options If you're uncertain, then can you please attach your /etc/ssh/sshd_config for us to review? If that file contains any information that is security sensitive or personally identifying please change this bug report from "Public" to "Private". Thanks ahead of time. ** Summary changed: - package openssh-server 1:7.6p1-4ubuntu0.3 failed to install/upgrade: installed openssh-server package post-installation script subprocess returned error exit status 1 + failed to install/upgrade: sshd_config: line 13: Bad configuration option ** Changed in: openssh (Ubuntu) Status: New => Incomplete -- 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/1905088 Title: failed to install/upgrade: sshd_config: line 13: Bad configuration option Status in openssh package in Ubuntu: Incomplete Bug description: Unpacking openssh-server (1:7.6p1-4ubuntu0.3) ... Setting up openssh-server (1:7.6p1-4ubuntu0.3) ... Job for ssh.service failed because the control process exited with error code. See "systemctl status ssh.service" and "journalctl -xe" for details. invoke-rc.d: initscript ssh, action "restart" failed. ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled) Active: activating (auto-restart) (Result: exit-code) since Fri 2020-11-20 22:09:42 CET; 20ms ago Process: 2918 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=255) dpkg: error processing package openssh-server (--configure): installed openssh-server package post-installation script subprocess returned error exit status 1 Processing triggers for man-db (2.8.3-2ubuntu0.1) ... Processing triggers for ufw (0.36-0ubuntu0.18.04.1) ... Rules updated for profile 'OpenSSH' Firewall reloaded Processing triggers for ureadahead (0.100.0-21) ... ureadahead will be reprofiled on next reboot Processing triggers for systemd (237-3ubuntu10.43) ... Errors were encountered while processing: openssh-server ProblemType: Package DistroRelease: Ubuntu 18.04 Package: openssh-server 1:7.6p1-4ubuntu0.3 ProcVersionSignature: Ubuntu 4.15.0-124.127-generic 4.15.18 Uname: Linux 4.15.0-124-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.20 Architecture: amd64 Date: Fri Nov 20 22:00:10 2020 ErrorMessage: installed openssh-server package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2018-12-27 (694 days ago) InstallationMedia: Ubuntu 16.04.4 LTS "Xenial Xerus" - Release amd64 (20180228) Python3Details: /usr/bin/python3.6, Python 3.6.9, python3-minimal, 3.6.7-1~18.04 PythonDetails: /usr/bin/python2.7, Python 2.7.17, python-minimal, 2.7.15~rc1-1 RelatedPackageVersions: dpkg 1.19.0.5ubuntu2.3 apt 1.6.12ubuntu0.1 SSHDConfig: Error: command ['/usr/sbin/sshd', '-T'] failed with exit code 255: /etc/ssh/sshd_config: line 13: Bad configuration option: Include /etc/ssh/sshd_config: terminating, 1 bad configuration options SourcePackage: openssh Title: package openssh-server 1:7.6p1-4ubuntu0.3 failed to install/upgrade: installed openssh-server package post-installation script subprocess returned error exit status 1 UpgradeStatus: Upgraded to bionic on 2020-06-16 (157 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1905088/+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 1890332] Re: apt update fails on unprivileged docker arm container due to invalid gpg signature
For the privileged/unprivileged issue mentioned in comment #6, these upstream comments appears to be pertinent, suggesting patches that may be worth backporting: https://github.com/moby/moby/issues/40734#issuecomment-614259072 https://github.com/moby/moby/issues/40734#issuecomment-680250761 As to the gpg errors in comment #8, I suspect those are unrelated. Those types of errors can crop up for a wide variety of reasons, including insufficient disk space, networking glitches, gpg problems, etc. all mostly unrelated to the package itself, so I would suggest looking to regular support channels for help there, for example see https://superuser.com/questions/1059346/apt-get-update-not-working- signing-verification-errors which suggests several solutions. If not, let us know. However, it's possible that the gpg error is hiding the earlier error, and potentially once its resolved the earlier error will come back. So I'll leave this issue open for now. ** Changed in: libseccomp (Ubuntu) Status: Confirmed => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1890332 Title: apt update fails on unprivileged docker arm container due to invalid gpg signature Status in libseccomp package in Ubuntu: Incomplete Bug description: Running `apt update` in a ubuntu:20.04 docker container on raspberry pi fails with GPG errors. Expected behaviour: Successfully update the system through `apt update` What happens instead: `Err:1 http://ports.ubuntu.com/ubuntu-ports focal InRelease At least one invalid signature was encountered.` Complete log: https://pastebin.com/sggGJcY1 How to reproduce: On a Raspberry Pi 3b or 4b (and maybe others ?), run the following command: `docker run ubuntu:latest apt update` or more specifically: `docker run arm32v7/ubuntu:20.04 apt update` More information: I can reproduce the bug on the following host systems: * Raspberry Pi 3b running HypriotOS * Raspberry Pi 4b running Raspbian GNU/Linux 10 (buster) The problem does not happens on the following host system: * Raspberry Pi 3b running Arch Linux Arm To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1890332/+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 1890332] Re: apt update fails on unprivileged docker arm container due to inaccessible clock
** Summary changed: - apt update fails on docker arm container 20.04 + apt update fails on unprivileged docker arm container due to inaccessible clock ** Summary changed: - apt update fails on unprivileged docker arm container due to inaccessible clock + apt update fails on unprivileged docker arm container due to invalid gpg signature -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1890332 Title: apt update fails on unprivileged docker arm container due to invalid gpg signature Status in libseccomp package in Ubuntu: Confirmed Bug description: Running `apt update` in a ubuntu:20.04 docker container on raspberry pi fails with GPG errors. Expected behaviour: Successfully update the system through `apt update` What happens instead: `Err:1 http://ports.ubuntu.com/ubuntu-ports focal InRelease At least one invalid signature was encountered.` Complete log: https://pastebin.com/sggGJcY1 How to reproduce: On a Raspberry Pi 3b or 4b (and maybe others ?), run the following command: `docker run ubuntu:latest apt update` or more specifically: `docker run arm32v7/ubuntu:20.04 apt update` More information: I can reproduce the bug on the following host systems: * Raspberry Pi 3b running HypriotOS * Raspberry Pi 4b running Raspbian GNU/Linux 10 (buster) The problem does not happens on the following host system: * Raspberry Pi 3b running Arch Linux Arm To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1890332/+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 1902540] Re: hirsute fails on add-apt-repository
I'm able to reproduce this in a hirsute lxc container I created today. Interestingly, another hirsute container I created Friday doesn't reproduce this issue even when updated to current. -- 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/1902540 Title: hirsute fails on add-apt-repository Status in software-properties package in Ubuntu: Confirmed Bug description: On a fully updated hirsute add-apt-repository fails, example: root@h:~# sudo add-apt-repository ppa:ci-train-ppa-service/4321 Traceback (most recent call last): File "/usr/bin/add-apt-repository", line 330, in addaptrepo = AddAptRepository() File "/usr/bin/add-apt-repository", line 35, in __init__ self.distro.get_sources(self.sourceslist) File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 91, in get_sources raise NoDistroTemplateException( aptsources.distro.NoDistroTemplateException: Error: could not find a distribution template for Ubuntu/hirsute The PPA seems not to matter (all trigger it) and if I manually add PPA sources list and GPG key it works. So maybe software-properties just needs to learn about hirsute? Or is there another components (like distro-info or such) that needs a bump for this to work? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1902540/+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 1857036] Re: `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE): Operation not permitted` error when run inside a container.
** Changed in: sudo (Ubuntu Focal) Status: In Progress => Fix Committed -- 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/1857036 Title: `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE): Operation not permitted` error when run inside a container. Status in sudo package in Ubuntu: Fix Released Status in sudo source package in Focal: Fix Committed Status in sudo source package in Groovy: Fix Released Bug description: [Impact] Logging in as a sudo user in a Ubuntu Focal Linux container displays a warning: sudo: setrlimit(RLIMIT_CORE): Operation not permitted The warning is entirely unnecessary - the container is trying to adjust RLIMIT_CORE, but this isn't allowed inside a container anyway. While this is "just" a warning, logging into a container as sudo is a very common practice, so this warning risks creating confusion for LTS users. [Test Case] $ lxc launch ubuntu:20.04/amd64 sudo-sru-lp1857036-test $ lxc shell sudo-sru-lp1857036-test # sudo --login --user ubuntu sudo: setrlimit(RLIMIT_CORE): Operation not permitted To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. $ logout Install the PPA # apt-add-repository -yus ppa:bryce/sudo-sru-lp1857036-setrlimit-in-lxc # apt-get install sudo # sudo --login --user ubuntu $ [Regression Potential] As this only affects printing of a couple warnings, the only behavioral change is in stderr output. [Discussion] This changes a couple warnings into equivalent debug printfs, which brings the sudo behavior in-line with the behavior in groovy, bionic, etc. and should cause no troubles. This patch originates from upstream, and is already in groovy's sudo package (which thus can be seen not to exhibit the issue). The upstream patch includes some new debug prints which should be harmless but are unnecessary to the fix so they've been removed. [Original Report] When using `sudo --login --user USERNAME` with Ubuntu Focal currently, it will correctly operate but it will also throw the following error before continuing with the logon process (which completes successfully except for the stated error): sudo: setrlimit(RLIMIT_CORE): Operation not permitted A full run of this was tested in a Focal LXD container after dropping to a root shell to reproduce (arstotzka is the host system, focal-test is the test container): teward@arstotzka:~$ lxc shell focal-test root@focal-test:~# sudo --login --user ubuntu sudo: setrlimit(RLIMIT_CORE): Operation not permitted To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. ubuntu@focal-test:~$ This appears to be similar to this issue identified on RedHat's tracker: https://bugzilla.redhat.com/show_bug.cgi?id=1773148 ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: sudo 1.8.29-1ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-72.81-generic 4.15.18 Uname: Linux 4.15.0-72-generic x86_64 ApportVersion: 2.20.11-0ubuntu14 Architecture: amd64 Date: Thu Dec 19 17:16:31 2019 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash SourcePackage: sudo UpgradeStatus: No upgrade log present (probably fresh install) VisudoCheck: /etc/sudoers: parsed OK /etc/sudoers.d/90-cloud-init-users: parsed OK /etc/sudoers.d/README: parsed OK To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1857036/+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 1857036] Re: `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE): Operation not permitted` error when run inside a container.
** Changed in: sudo (Ubuntu Focal) Status: Triaged => In Progress -- 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/1857036 Title: `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE): Operation not permitted` error when run inside a container. Status in sudo package in Ubuntu: Fix Released Status in sudo source package in Focal: In Progress Status in sudo source package in Groovy: Fix Released Bug description: [Impact] Logging in as a sudo user in a Ubuntu Focal Linux container displays a warning: sudo: setrlimit(RLIMIT_CORE): Operation not permitted The warning is entirely unnecessary - the container is trying to adjust RLIMIT_CORE, but this isn't allowed inside a container anyway. While this is "just" a warning, logging into a container as sudo is a very common practice, so this warning risks creating confusion for LTS users. [Test Case] $ lxc launch ubuntu:20.04/amd64 sudo-sru-lp1857036-test $ lxc shell sudo-sru-lp1857036-test # sudo --login --user ubuntu sudo: setrlimit(RLIMIT_CORE): Operation not permitted To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. $ logout Install the PPA # apt-add-repository -yus ppa:bryce/sudo-sru-lp1857036-setrlimit-in-lxc # apt-get install sudo # sudo --login --user ubuntu $ [Regression Potential] As this only affects printing of a couple warnings, the only behavioral change is in stderr output. [Discussion] This changes a couple warnings into equivalent debug printfs, which brings the sudo behavior in-line with the behavior in groovy, bionic, etc. and should cause no troubles. This patch originates from upstream, and is already in groovy's sudo package (which thus can be seen not to exhibit the issue). The upstream patch includes some new debug prints which should be harmless but are unnecessary to the fix so they've been removed. [Original Report] When using `sudo --login --user USERNAME` with Ubuntu Focal currently, it will correctly operate but it will also throw the following error before continuing with the logon process (which completes successfully except for the stated error): sudo: setrlimit(RLIMIT_CORE): Operation not permitted A full run of this was tested in a Focal LXD container after dropping to a root shell to reproduce (arstotzka is the host system, focal-test is the test container): teward@arstotzka:~$ lxc shell focal-test root@focal-test:~# sudo --login --user ubuntu sudo: setrlimit(RLIMIT_CORE): Operation not permitted To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. ubuntu@focal-test:~$ This appears to be similar to this issue identified on RedHat's tracker: https://bugzilla.redhat.com/show_bug.cgi?id=1773148 ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: sudo 1.8.29-1ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-72.81-generic 4.15.18 Uname: Linux 4.15.0-72-generic x86_64 ApportVersion: 2.20.11-0ubuntu14 Architecture: amd64 Date: Thu Dec 19 17:16:31 2019 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash SourcePackage: sudo UpgradeStatus: No upgrade log present (probably fresh install) VisudoCheck: /etc/sudoers: parsed OK /etc/sudoers.d/90-cloud-init-users: parsed OK /etc/sudoers.d/README: parsed OK To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1857036/+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 1857036] Re: `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE): Operation not permitted` error when run inside a container.
** Description changed: [Impact] Logging in as a sudo user in a Ubuntu Focal Linux container displays a warning: - sudo: setrlimit(RLIMIT_CORE): Operation not permitted + sudo: setrlimit(RLIMIT_CORE): Operation not permitted The warning is entirely unnecessary - the container is trying to adjust RLIMIT_CORE, but this isn't allowed inside a container anyway. While this is "just" a warning, logging into a container as sudo is a very common practice, so this warning risks creating confusion for LTS users. [Test Case] $ lxc launch ubuntu:20.04/amd64 sudo-sru-lp1857036-test $ lxc shell sudo-sru-lp1857036-test # sudo --login --user ubuntu sudo: setrlimit(RLIMIT_CORE): Operation not permitted To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. $ logout Install the PPA # apt-add-repository -yus ppa:bryce/sudo-sru-lp1857036-setrlimit-in-lxc # apt-get install sudo # sudo --login --user ubuntu - To run a command as administrator (user "root"), use "sudo ". - See "man sudo_root" for details. $ [Regression Potential] As this only affects printing of a couple warnings, the only behavioral change is in stderr output. [Discussion] This changes a couple warnings into equivalent debug printfs, which brings the sudo behavior in-line with the behavior in groovy, bionic, etc. and should cause no troubles. This patch originates from upstream, and is already in groovy's sudo package (which thus can be seen not to exhibit the issue). The upstream patch includes some new debug prints which should be harmless but are unnecessary to the fix so they've been removed. - [Original Report] When using `sudo --login --user USERNAME` with Ubuntu Focal currently, it will correctly operate but it will also throw the following error before continuing with the logon process (which completes successfully except for the stated error): sudo: setrlimit(RLIMIT_CORE): Operation not permitted A full run of this was tested in a Focal LXD container after dropping to a root shell to reproduce (arstotzka is the host system, focal-test is the test container): teward@arstotzka:~$ lxc shell focal-test root@focal-test:~# sudo --login --user ubuntu sudo: setrlimit(RLIMIT_CORE): Operation not permitted To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. ubuntu@focal-test:~$ This appears to be similar to this issue identified on RedHat's tracker: https://bugzilla.redhat.com/show_bug.cgi?id=1773148 ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: sudo 1.8.29-1ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-72.81-generic 4.15.18 Uname: Linux 4.15.0-72-generic x86_64 ApportVersion: 2.20.11-0ubuntu14 Architecture: amd64 Date: Thu Dec 19 17:16:31 2019 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash SourcePackage: sudo UpgradeStatus: No upgrade log present (probably fresh install) VisudoCheck: /etc/sudoers: parsed OK /etc/sudoers.d/90-cloud-init-users: parsed OK /etc/sudoers.d/README: parsed OK -- 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/1857036 Title: `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE): Operation not permitted` error when run inside a container. Status in sudo package in Ubuntu: Fix Released Status in sudo source package in Focal: Triaged Status in sudo source package in Groovy: Fix Released Bug description: [Impact] Logging in as a sudo user in a Ubuntu Focal Linux container displays a warning: sudo: setrlimit(RLIMIT_CORE): Operation not permitted The warning is entirely unnecessary - the container is trying to adjust RLIMIT_CORE, but this isn't allowed inside a container anyway. While this is "just" a warning, logging into a container as sudo is a very common practice, so this warning risks creating confusion for LTS users. [Test Case] $ lxc launch ubuntu:20.04/amd64 sudo-sru-lp1857036-test $ lxc shell sudo-sru-lp1857036-test # sudo --login --user ubuntu sudo: setrlimit(RLIMIT_CORE): Operation not permitted To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. $ logout Install the PPA # apt-add-repository -yus ppa:bryce/sudo-sru-lp1857036-setrlimit-in-lxc # apt-get install sudo # sudo --login --user ubuntu $ [Regression Potential] As this only affects printing of a couple warnings, the only behavioral change is in stderr output. [Discussion] This changes a couple warnings into equivalent debug printfs, which brings the sudo behavior in-line with the behavior in groovy, bionic, etc. and should cause no troubles. This patch originates from upstream, and is already in groovy's
[Touch-packages] [Bug 1857036] Re: `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE): Operation not permitted` error when run inside a container.
** Description changed: - When using `sudo --login --user USERNAME` with Ubuntu Focal currently, - it will correctly operate but it will also throw the following error - before continuing with the logon process (which completes successfully - except for the stated error): + [Impact] + Logging in as a sudo user in a Ubuntu Focal Linux container displays a + warning: + + sudo: setrlimit(RLIMIT_CORE): Operation not permitted + + The warning is entirely unnecessary - the container is trying to adjust + RLIMIT_CORE, but this isn't allowed inside a container anyway. + + While this is "just" a warning, logging into a container as sudo is a + very common practice, so this warning risks creating confusion for LTS + users. + + [Test Case] + $ lxc launch ubuntu:20.04/amd64 sudo-sru-lp1857036-test + $ lxc shell sudo-sru-lp1857036-test + + # sudo --login --user ubuntu + sudo: setrlimit(RLIMIT_CORE): Operation not permitted + To run a command as administrator (user "root"), use "sudo ". + See "man sudo_root" for details. + $ logout + + Install the PPA + # apt-add-repository -yus ppa:bryce/sudo-sru-lp1857036-setrlimit-in-lxc + # apt-get install sudo + + # sudo --login --user ubuntu + To run a command as administrator (user "root"), use "sudo ". + See "man sudo_root" for details. + $ + + [Regression Potential] + As this only affects printing of a couple warnings, the only behavioral + change is in stderr output. + + [Discussion] + This changes a couple warnings into equivalent debug printfs, which + brings the sudo behavior in-line with the behavior in groovy, bionic, + etc. and should cause no troubles. + + This patch originates from upstream, and is already in groovy's sudo + package (which thus can be seen not to exhibit the issue). + + The upstream patch includes some new debug prints which should be + harmless but are unnecessary to the fix so they've been removed. + + + [Original Report] + When using `sudo --login --user USERNAME` with Ubuntu Focal currently, it will correctly operate but it will also throw the following error before continuing with the logon process (which completes successfully except for the stated error): sudo: setrlimit(RLIMIT_CORE): Operation not permitted A full run of this was tested in a Focal LXD container after dropping to a root shell to reproduce (arstotzka is the host system, focal-test is the test container): teward@arstotzka:~$ lxc shell focal-test root@focal-test:~# sudo --login --user ubuntu sudo: setrlimit(RLIMIT_CORE): Operation not permitted To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. ubuntu@focal-test:~$ This appears to be similar to this issue identified on RedHat's tracker: https://bugzilla.redhat.com/show_bug.cgi?id=1773148 ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: sudo 1.8.29-1ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-72.81-generic 4.15.18 Uname: Linux 4.15.0-72-generic x86_64 ApportVersion: 2.20.11-0ubuntu14 Architecture: amd64 Date: Thu Dec 19 17:16:31 2019 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash SourcePackage: sudo UpgradeStatus: No upgrade log present (probably fresh install) VisudoCheck: /etc/sudoers: parsed OK /etc/sudoers.d/90-cloud-init-users: parsed OK /etc/sudoers.d/README: parsed OK ** Changed in: sudo (Ubuntu Focal) Assignee: (unassigned) => Bryce Harrington (bryce) ** Changed in: sudo (Ubuntu Focal) Importance: Undecided => High -- 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/1857036 Title: `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE): Operation not permitted` error when run inside a container. Status in sudo package in Ubuntu: Fix Released Status in sudo source package in Focal: Triaged Status in sudo source package in Groovy: Fix Released Bug description: [Impact] Logging in as a sudo user in a Ubuntu Focal Linux container displays a warning: sudo: setrlimit(RLIMIT_CORE): Operation not permitted The warning is entirely unnecessary - the container is trying to adjust RLIMIT_CORE, but this isn't allowed inside a container anyway. While this is "just" a warning, logging into a container as sudo is a very common practice, so this warning risks creating confusion for LTS users. [Test Case] $ lxc launch ubuntu:20.04/amd64 sudo-sru-lp1857036-test $ lxc shell sudo-sru-lp1857036-test # sudo --login --user ubuntu sudo: setrlimit(RLIMIT_CORE): Operation not permitted To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. $ logout Install the PPA # apt-add-repository -yu
[Touch-packages] [Bug 1827159] Re: check_all_disks includes squashfs /snap/* which are 100%
df no longer shows squashfs mounts by default, as of today's coreutils update ** Changed in: coreutils (Ubuntu) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/1827159 Title: check_all_disks includes squashfs /snap/* which are 100% Status in Nagios Charm: Fix Released Status in coreutils package in Ubuntu: Fix Released Status in monitoring-plugins package in Ubuntu: Fix Released Bug description: [Impact] False positive reports are generated in monitoring tools when artificial filesystems are mounted, since they show 100% disk utilization, and thus add unnecessary (but dire sounding) "DISK CRITICAL" noise. [Test Case] $ lxc create ubuntu-daily:19.10/amd64 lp1827159 $ lxc exec lp1827159 bash # apt-get -y update # apt-get install monitoring-plugins # snap install gnome-calculator [...] # /usr/lib/nagios/plugins/check_disk -w 10 -c 10 DISK CRITICAL - free space: / 1903 MB (1% inode=78%); /dev 0 MB (100% inode=99%); /dev/full 16018 MB (100% inode=99%); /dev/null 16018 MB (100% inode=99%); /dev/random 16018 MB (100% inode=99%); /dev/tty 16018 MB (100% inode=99%); /dev/urandom 16018 MB (100% inode=99%); /dev/zero 16018 MB (100% inode=99%); /dev/fuse 16018 MB (100% inode=99%); /dev/net/tun 16018 MB (100% inode=99%); /dev/lxd 0 MB (100% inode=99%); /dev/.lxd-mounts 0 MB (100% inode=99%); /dev/shm 16041 MB (100% inode=99%); /run 3208 MB (99% inode=99%); /run/lock 5 MB (100% inode=99%); /sys/fs/cgroup 16041 MB (100% inode=99%); /snap 1903 MB (1% inode=78%); /run/snapd/ns 3208 MB (99% inode=99%);| /=71MB;119160;119160;0;119170 /dev=0MB;-10;-10;0;0 /dev/full=0MB;16008;16008;0;16018 /dev/null=0MB;16008;16008;0;16018 /dev/random=0MB;16008;16008;0;16018 /dev/tty=0MB;16008;16008;0;16018 /dev/urandom=0MB;16008;16008;0;16018 /dev/zero=0MB;16008;16008;0;16018 /dev/fuse=0MB;16008;16008;0;16018 /dev/net/tun=0MB;16008;16008;0;16018 /dev/lxd=0MB;-10;-10;0;0 /dev/.lxd-mounts=0MB;-10;-10;0;0 /dev/shm=0MB;16031;16031;0;16041 /run=0MB;3198;3198;0;3208 /run/lock=0MB;-5;-5;0;5 /sys/fs/cgroup=0MB;16031;16031;0;16041 /snap=71MB;119160;119160;0;119170 /run/snapd/ns=0MB;3198;3198;0;3208 # /usr/lib/nagios/plugins/check_disk -w 10 -c 10 -e -X squashfs DISK CRITICAL - free space: /dev 0 MB (100% inode=99%); /dev/lxd 0 MB (100% inode=99%); /dev/.lxd-mounts 0 MB (100% inode=99%); /run/lock 5 MB (100% inode=99%);| /=111392MB;119160;119160;0;119170 /dev=0MB;-10;-10;0;0 /dev/full=0MB;16008;16008;0;16018 /dev/null=0MB;16008;16008;0;16018 /dev/random=0MB;16008;16008;0;16018 /dev/tty=0MB;16008;16008;0;16018 /dev/urandom=0MB;16008;16008;0;16018 /dev/zero=0MB;16008;16008;0;16018 /dev/fuse=0MB;16008;16008;0;16018 /dev/net/tun=0MB;16008;16008;0;16018 /dev/lxd=0MB;-10;-10;0;0 /dev/.lxd-mounts=0MB;-10;-10;0;0 /dev/shm=0MB;16031;16031;0;16041 /run=0MB;3198;3198;0;3208 /run/lock=0MB;-5;-5;0;5 /sys/fs/cgroup=0MB;16031;16031;0;16041 /snap=111392MB;119160;119160;0;119170 /run/snapd/ns=0MB;3198;3198;0;3208 # /usr/lib/nagios/plugins/check_disk -w 10 -c 10 -e -X tmpfs DISK OK| /=71MB;119160;119160;0;119170 /dev/full=0MB;16008;16008;0;16018 /dev/null=0MB;16008;16008;0;16018 /dev/random=0MB;16008;16008;0;16018 /dev/tty=0MB;16008;16008;0;16018 /dev/urandom=0MB;16008;16008;0;16018 /dev/zero=0MB;16008;16008;0;16018 /dev/fuse=0MB;16008;16008;0;16018 /dev/net/tun=0MB;16008;16008;0;16018 /snap=71MB;119160;119160;0;119170 [Regression Potential] As this alters the logic of how out-of-space checks are handled, relevant issues to keep an eye out for would relate to filesystem checks reporting improperly. These tools underlay a few different front-ends, so regression bugs may get filed in a few different places, however they will tend to display error messages involving check_disk, nagios, and either tmpfs or tracefs. Note that there are likely other synthetic filesystems beyond tmpfs and tracefs (e.g. udev, usbfs, devtmpfs, fuse.*, ...) which might also cause similar false positives; these should be handled as separate bugs, although they can likely be fixed the same way. [Fix] monitoring-plugins is modified to exclude the unwanted filesystems by default, in check_disk.c (see patch). [Discussion] There have been several bug reports filed about false positives with different synthetic file systems (see Dupes), including tracefs, squashfs, and tmpfs. The commonly discussed workaround is to exclude these when running the tools (e.g. using the '-X ' parameter for check_all_disks). Since wrappers are typically used for running the underlying tools, it is possible to add a string of -X... parameters. However, a cleaner solution is possible. monitoring-plugins' check_disk.c maintains an internal exclusion list, fs_exclude_list, which already excludes iso9660, and can be
[Touch-packages] [Bug 1219529] Re: df -x tmpfs fails to exclude udev (/dev)
** Changed in: coreutils (Ubuntu) Status: Triaged => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/1219529 Title: df -x tmpfs fails to exclude udev (/dev) Status in coreutils: New Status in coreutils package in Ubuntu: Fix Committed Bug description: The command: $ /bin/df -x tmpfs should exclude all filesystems of type tmpfs. The udev filesystem mounted at /dev is of this type: $ stat -f /dev File: "/dev" ID: 0Namelen: 255 Type: tmpfs Block size: 4096 Fundamental block size: 4096 Blocks: Total: 4109101Free: 4109098Available: 4109098 Inodes: Total: 4109101Free: 4108501 However, df still displays this filesystem: $ df -l -x tmpfs Filesystem 1K-blocks Used Available Use% Mounted on ... udev 1643640412 16436392 1% /dev ... ProblemType: Bug DistroRelease: Ubuntu 13.04 Package: coreutils 8.20-3ubuntu5 ProcVersionSignature: Ubuntu 3.8.0-29.42-generic 3.8.13.5 Uname: Linux 3.8.0-29-generic x86_64 ApportVersion: 2.9.2-0ubuntu8.3 Architecture: amd64 Date: Sun Sep 1 15:05:40 2013 InstallationDate: Installed on 2013-08-31 (0 days ago) InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424) MarkForUpload: True ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: coreutils UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/coreutils/+bug/1219529/+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 1756595] Re: disk space info inadvertently provides all installed snaps
** Changed in: coreutils (Ubuntu) Status: New => Fix Committed -- 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/1756595 Title: disk space info inadvertently provides all installed snaps Status in apt package in Ubuntu: Fix Released Status in coreutils package in Ubuntu: Fix Committed Status in apt source package in Bionic: Fix Released Status in apt source package in Disco: Fix Released Status in apt source package in Eoan: Fix Released Bug description: [Impact] When apport is reporting a crash, it includes the output of the "df" utility, to list the free disk space information per mount point. That output nowadays will inadvertently include all snaps that the user may have installed, including their revision numbers. Here is a simple df output: andreas@nsn7:~$ df Filesystem 1K-blocksUsed Available Use% Mounted on udev 8119680 0 8119680 0% /dev tmpfs 16301561828 1628328 1% /run nsn7/ROOT/ubuntu433084288 2500608 430583680 1% / tmpfs 8150776 1 8131888 1% /dev/shm tmpfs5120 4 5116 1% /run/lock tmpfs 8150776 0 8150776 0% /sys/fs/cgroup nsn7/var/log430763136 179456 430583680 1% /var/log nsn7/var/tmp430583808 128 430583680 1% /var/tmp /dev/sda2 1032088 160336871752 16% /boot /dev/sda1 5232482720520528 1% /boot/efi nsn7/home 430651264 67584 430583680 1% /home nsn7/var/cache 430653312 69632 430583680 1% /var/cache nsn7/var/mail 430583808 128 430583680 1% /var/mail nsn7/var/spool 430583808 128 430583680 1% /var/spool tmpfs 1630152 16 1630136 1% /run/user/120 tmpfs 100 0 100 0% /var/lib/lxd/shmounts tmpfs 100 0 100 0% /var/lib/lxd/devlxd tmpfs 1630152 36 1630116 1% /run/user/1000 nsn7/lxd/containers/squid-ds216 431444096 860416 430583680 1% /var/lib/lxd/storage-pools/default/containers/squid-ds216 /dev/loop0 83712 83712 0 100% /snap/core/4206 /dev/loop1 102144 102144 0 100% /snap/git-ubuntu/402 You can see I have the core snap at revision 4206, and git-ubuntu at revision 402. There are already many bug reports in launchpad where one can see this information. Granted, the user can review it, refuse to send this data, etc. This bug is about the unexpectedness of having that information in the disk space data. If the user sees a prompt like "Would you like to include disk free space information in your report?", or "Would you like to include the output of the df(1) command in your report?", that doesn't immediately translate to "Would you like to include disk free space information and a list of all installed snaps and their revision numbers in your report?". [Test case] Do something that triggers the apport hook and make sure you don't see snaps in there. For example, install xterm, then add exit 1 to the start of the prerm, then run apt remove xterm, and investigate /var/crash/xterm.0.crash after that (delete before running apt). [Regression potential] Fix consists of adding -x squashfs to df output, so might hide other non-snap squashfs images. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1756595/+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 1827159] Re: check_all_disks includes squashfs /snap/* which are 100%
** Changed in: coreutils (Ubuntu) Status: New => Fix Committed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/1827159 Title: check_all_disks includes squashfs /snap/* which are 100% Status in Nagios Charm: Fix Released Status in coreutils package in Ubuntu: Fix Committed Status in monitoring-plugins package in Ubuntu: Fix Released Bug description: [Impact] False positive reports are generated in monitoring tools when artificial filesystems are mounted, since they show 100% disk utilization, and thus add unnecessary (but dire sounding) "DISK CRITICAL" noise. [Test Case] $ lxc create ubuntu-daily:19.10/amd64 lp1827159 $ lxc exec lp1827159 bash # apt-get -y update # apt-get install monitoring-plugins # snap install gnome-calculator [...] # /usr/lib/nagios/plugins/check_disk -w 10 -c 10 DISK CRITICAL - free space: / 1903 MB (1% inode=78%); /dev 0 MB (100% inode=99%); /dev/full 16018 MB (100% inode=99%); /dev/null 16018 MB (100% inode=99%); /dev/random 16018 MB (100% inode=99%); /dev/tty 16018 MB (100% inode=99%); /dev/urandom 16018 MB (100% inode=99%); /dev/zero 16018 MB (100% inode=99%); /dev/fuse 16018 MB (100% inode=99%); /dev/net/tun 16018 MB (100% inode=99%); /dev/lxd 0 MB (100% inode=99%); /dev/.lxd-mounts 0 MB (100% inode=99%); /dev/shm 16041 MB (100% inode=99%); /run 3208 MB (99% inode=99%); /run/lock 5 MB (100% inode=99%); /sys/fs/cgroup 16041 MB (100% inode=99%); /snap 1903 MB (1% inode=78%); /run/snapd/ns 3208 MB (99% inode=99%);| /=71MB;119160;119160;0;119170 /dev=0MB;-10;-10;0;0 /dev/full=0MB;16008;16008;0;16018 /dev/null=0MB;16008;16008;0;16018 /dev/random=0MB;16008;16008;0;16018 /dev/tty=0MB;16008;16008;0;16018 /dev/urandom=0MB;16008;16008;0;16018 /dev/zero=0MB;16008;16008;0;16018 /dev/fuse=0MB;16008;16008;0;16018 /dev/net/tun=0MB;16008;16008;0;16018 /dev/lxd=0MB;-10;-10;0;0 /dev/.lxd-mounts=0MB;-10;-10;0;0 /dev/shm=0MB;16031;16031;0;16041 /run=0MB;3198;3198;0;3208 /run/lock=0MB;-5;-5;0;5 /sys/fs/cgroup=0MB;16031;16031;0;16041 /snap=71MB;119160;119160;0;119170 /run/snapd/ns=0MB;3198;3198;0;3208 # /usr/lib/nagios/plugins/check_disk -w 10 -c 10 -e -X squashfs DISK CRITICAL - free space: /dev 0 MB (100% inode=99%); /dev/lxd 0 MB (100% inode=99%); /dev/.lxd-mounts 0 MB (100% inode=99%); /run/lock 5 MB (100% inode=99%);| /=111392MB;119160;119160;0;119170 /dev=0MB;-10;-10;0;0 /dev/full=0MB;16008;16008;0;16018 /dev/null=0MB;16008;16008;0;16018 /dev/random=0MB;16008;16008;0;16018 /dev/tty=0MB;16008;16008;0;16018 /dev/urandom=0MB;16008;16008;0;16018 /dev/zero=0MB;16008;16008;0;16018 /dev/fuse=0MB;16008;16008;0;16018 /dev/net/tun=0MB;16008;16008;0;16018 /dev/lxd=0MB;-10;-10;0;0 /dev/.lxd-mounts=0MB;-10;-10;0;0 /dev/shm=0MB;16031;16031;0;16041 /run=0MB;3198;3198;0;3208 /run/lock=0MB;-5;-5;0;5 /sys/fs/cgroup=0MB;16031;16031;0;16041 /snap=111392MB;119160;119160;0;119170 /run/snapd/ns=0MB;3198;3198;0;3208 # /usr/lib/nagios/plugins/check_disk -w 10 -c 10 -e -X tmpfs DISK OK| /=71MB;119160;119160;0;119170 /dev/full=0MB;16008;16008;0;16018 /dev/null=0MB;16008;16008;0;16018 /dev/random=0MB;16008;16008;0;16018 /dev/tty=0MB;16008;16008;0;16018 /dev/urandom=0MB;16008;16008;0;16018 /dev/zero=0MB;16008;16008;0;16018 /dev/fuse=0MB;16008;16008;0;16018 /dev/net/tun=0MB;16008;16008;0;16018 /snap=71MB;119160;119160;0;119170 [Regression Potential] As this alters the logic of how out-of-space checks are handled, relevant issues to keep an eye out for would relate to filesystem checks reporting improperly. These tools underlay a few different front-ends, so regression bugs may get filed in a few different places, however they will tend to display error messages involving check_disk, nagios, and either tmpfs or tracefs. Note that there are likely other synthetic filesystems beyond tmpfs and tracefs (e.g. udev, usbfs, devtmpfs, fuse.*, ...) which might also cause similar false positives; these should be handled as separate bugs, although they can likely be fixed the same way. [Fix] monitoring-plugins is modified to exclude the unwanted filesystems by default, in check_disk.c (see patch). [Discussion] There have been several bug reports filed about false positives with different synthetic file systems (see Dupes), including tracefs, squashfs, and tmpfs. The commonly discussed workaround is to exclude these when running the tools (e.g. using the '-X ' parameter for check_all_disks). Since wrappers are typically used for running the underlying tools, it is possible to add a string of -X... parameters. However, a cleaner solution is possible. monitoring-plugins' check_disk.c maintains an internal exclusion list, fs_exclude_list, which already excludes iso9660, and can be modified to add other filesystems to exclude by default. In other words, check_disk.c is
[Touch-packages] [Bug 1756595] Re: disk space info inadvertently provides all installed snaps
** Also affects: coreutils (Ubuntu) Importance: Undecided Status: New -- 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/1756595 Title: disk space info inadvertently provides all installed snaps Status in apt package in Ubuntu: Fix Released Status in coreutils package in Ubuntu: New Status in apt source package in Bionic: Fix Released Status in apt source package in Disco: Fix Released Status in apt source package in Eoan: Fix Released Bug description: [Impact] When apport is reporting a crash, it includes the output of the "df" utility, to list the free disk space information per mount point. That output nowadays will inadvertently include all snaps that the user may have installed, including their revision numbers. Here is a simple df output: andreas@nsn7:~$ df Filesystem 1K-blocksUsed Available Use% Mounted on udev 8119680 0 8119680 0% /dev tmpfs 16301561828 1628328 1% /run nsn7/ROOT/ubuntu433084288 2500608 430583680 1% / tmpfs 8150776 1 8131888 1% /dev/shm tmpfs5120 4 5116 1% /run/lock tmpfs 8150776 0 8150776 0% /sys/fs/cgroup nsn7/var/log430763136 179456 430583680 1% /var/log nsn7/var/tmp430583808 128 430583680 1% /var/tmp /dev/sda2 1032088 160336871752 16% /boot /dev/sda1 5232482720520528 1% /boot/efi nsn7/home 430651264 67584 430583680 1% /home nsn7/var/cache 430653312 69632 430583680 1% /var/cache nsn7/var/mail 430583808 128 430583680 1% /var/mail nsn7/var/spool 430583808 128 430583680 1% /var/spool tmpfs 1630152 16 1630136 1% /run/user/120 tmpfs 100 0 100 0% /var/lib/lxd/shmounts tmpfs 100 0 100 0% /var/lib/lxd/devlxd tmpfs 1630152 36 1630116 1% /run/user/1000 nsn7/lxd/containers/squid-ds216 431444096 860416 430583680 1% /var/lib/lxd/storage-pools/default/containers/squid-ds216 /dev/loop0 83712 83712 0 100% /snap/core/4206 /dev/loop1 102144 102144 0 100% /snap/git-ubuntu/402 You can see I have the core snap at revision 4206, and git-ubuntu at revision 402. There are already many bug reports in launchpad where one can see this information. Granted, the user can review it, refuse to send this data, etc. This bug is about the unexpectedness of having that information in the disk space data. If the user sees a prompt like "Would you like to include disk free space information in your report?", or "Would you like to include the output of the df(1) command in your report?", that doesn't immediately translate to "Would you like to include disk free space information and a list of all installed snaps and their revision numbers in your report?". [Test case] Do something that triggers the apport hook and make sure you don't see snaps in there. For example, install xterm, then add exit 1 to the start of the prerm, then run apt remove xterm, and investigate /var/crash/xterm.0.crash after that (delete before running apt). [Regression potential] Fix consists of adding -x squashfs to df output, so might hide other non-snap squashfs images. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1756595/+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 1827159] Re: check_all_disks includes squashfs /snap/* which are 100%
** Also affects: coreutils (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/1827159 Title: check_all_disks includes squashfs /snap/* which are 100% Status in Nagios Charm: Fix Released Status in coreutils package in Ubuntu: New Status in monitoring-plugins package in Ubuntu: Fix Released Bug description: [Impact] False positive reports are generated in monitoring tools when artificial filesystems are mounted, since they show 100% disk utilization, and thus add unnecessary (but dire sounding) "DISK CRITICAL" noise. [Test Case] $ lxc create ubuntu-daily:19.10/amd64 lp1827159 $ lxc exec lp1827159 bash # apt-get -y update # apt-get install monitoring-plugins # snap install gnome-calculator [...] # /usr/lib/nagios/plugins/check_disk -w 10 -c 10 DISK CRITICAL - free space: / 1903 MB (1% inode=78%); /dev 0 MB (100% inode=99%); /dev/full 16018 MB (100% inode=99%); /dev/null 16018 MB (100% inode=99%); /dev/random 16018 MB (100% inode=99%); /dev/tty 16018 MB (100% inode=99%); /dev/urandom 16018 MB (100% inode=99%); /dev/zero 16018 MB (100% inode=99%); /dev/fuse 16018 MB (100% inode=99%); /dev/net/tun 16018 MB (100% inode=99%); /dev/lxd 0 MB (100% inode=99%); /dev/.lxd-mounts 0 MB (100% inode=99%); /dev/shm 16041 MB (100% inode=99%); /run 3208 MB (99% inode=99%); /run/lock 5 MB (100% inode=99%); /sys/fs/cgroup 16041 MB (100% inode=99%); /snap 1903 MB (1% inode=78%); /run/snapd/ns 3208 MB (99% inode=99%);| /=71MB;119160;119160;0;119170 /dev=0MB;-10;-10;0;0 /dev/full=0MB;16008;16008;0;16018 /dev/null=0MB;16008;16008;0;16018 /dev/random=0MB;16008;16008;0;16018 /dev/tty=0MB;16008;16008;0;16018 /dev/urandom=0MB;16008;16008;0;16018 /dev/zero=0MB;16008;16008;0;16018 /dev/fuse=0MB;16008;16008;0;16018 /dev/net/tun=0MB;16008;16008;0;16018 /dev/lxd=0MB;-10;-10;0;0 /dev/.lxd-mounts=0MB;-10;-10;0;0 /dev/shm=0MB;16031;16031;0;16041 /run=0MB;3198;3198;0;3208 /run/lock=0MB;-5;-5;0;5 /sys/fs/cgroup=0MB;16031;16031;0;16041 /snap=71MB;119160;119160;0;119170 /run/snapd/ns=0MB;3198;3198;0;3208 # /usr/lib/nagios/plugins/check_disk -w 10 -c 10 -e -X squashfs DISK CRITICAL - free space: /dev 0 MB (100% inode=99%); /dev/lxd 0 MB (100% inode=99%); /dev/.lxd-mounts 0 MB (100% inode=99%); /run/lock 5 MB (100% inode=99%);| /=111392MB;119160;119160;0;119170 /dev=0MB;-10;-10;0;0 /dev/full=0MB;16008;16008;0;16018 /dev/null=0MB;16008;16008;0;16018 /dev/random=0MB;16008;16008;0;16018 /dev/tty=0MB;16008;16008;0;16018 /dev/urandom=0MB;16008;16008;0;16018 /dev/zero=0MB;16008;16008;0;16018 /dev/fuse=0MB;16008;16008;0;16018 /dev/net/tun=0MB;16008;16008;0;16018 /dev/lxd=0MB;-10;-10;0;0 /dev/.lxd-mounts=0MB;-10;-10;0;0 /dev/shm=0MB;16031;16031;0;16041 /run=0MB;3198;3198;0;3208 /run/lock=0MB;-5;-5;0;5 /sys/fs/cgroup=0MB;16031;16031;0;16041 /snap=111392MB;119160;119160;0;119170 /run/snapd/ns=0MB;3198;3198;0;3208 # /usr/lib/nagios/plugins/check_disk -w 10 -c 10 -e -X tmpfs DISK OK| /=71MB;119160;119160;0;119170 /dev/full=0MB;16008;16008;0;16018 /dev/null=0MB;16008;16008;0;16018 /dev/random=0MB;16008;16008;0;16018 /dev/tty=0MB;16008;16008;0;16018 /dev/urandom=0MB;16008;16008;0;16018 /dev/zero=0MB;16008;16008;0;16018 /dev/fuse=0MB;16008;16008;0;16018 /dev/net/tun=0MB;16008;16008;0;16018 /snap=71MB;119160;119160;0;119170 [Regression Potential] As this alters the logic of how out-of-space checks are handled, relevant issues to keep an eye out for would relate to filesystem checks reporting improperly. These tools underlay a few different front-ends, so regression bugs may get filed in a few different places, however they will tend to display error messages involving check_disk, nagios, and either tmpfs or tracefs. Note that there are likely other synthetic filesystems beyond tmpfs and tracefs (e.g. udev, usbfs, devtmpfs, fuse.*, ...) which might also cause similar false positives; these should be handled as separate bugs, although they can likely be fixed the same way. [Fix] monitoring-plugins is modified to exclude the unwanted filesystems by default, in check_disk.c (see patch). [Discussion] There have been several bug reports filed about false positives with different synthetic file systems (see Dupes), including tracefs, squashfs, and tmpfs. The commonly discussed workaround is to exclude these when running the tools (e.g. using the '-X ' parameter for check_all_disks). Since wrappers are typically used for running the underlying tools, it is possible to add a string of -X... parameters. However, a cleaner solution is possible. monitoring-plugins' check_disk.c maintains an internal exclusion list, fs_exclude_list, which already excludes iso9660, and can be modified to add other filesystems to exclude by default. In other words, check_disk.c is
[Touch-packages] [Bug 1787225] Re: systemctl disable apache2 does nothing
Closing as expired. ** Changed in: apache2 (Ubuntu) Status: Incomplete => Invalid ** Changed in: systemd (Ubuntu) Status: Confirmed => Invalid -- 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/1787225 Title: systemctl disable apache2 does nothing Status in apache2 package in Ubuntu: Invalid Status in systemd package in Ubuntu: Invalid Bug description: I installed apache2 on Ubuntu 16.04, and out of the box it was enabled as a service, meaning it would automatically start at every boot. That is not what I want as this is my personal computer, not a server. $ systemctl is-enabled apache2.service enabled So I ran: $ sudo systemctl disable apache2 and this was the output: apache2.service is not a native service, redirecting to systemd-sysv-install Executing /lib/systemd/systemd-sysv-install disable apache2 insserv: warning: current start runlevel(s) (empty) of script `apache2' overrides LSB defaults (2 3 4 5). insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `apache2' overrides LSB defaults (0 1 6). insserv: warning: current start runlevel(s) (empty) of script `apache2' overrides LSB defaults (2 3 4 5). insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `apache2' overrides LSB defaults (0 1 6). Then I rebooted. I expected to find apache2 not running. Instead, it was running. Surprisingly: $ systemctl is-enabled apache2.service apache2.service is not a native service, redirecting to systemd-sysv-install Executing /lib/systemd/systemd-sysv-install is-enabled apache2 disabled so, it shows up as disabled, yet it is started at startup. I wonder if this is what those warnings were about. Those messages are unclear as fuck, I have no f***ing clue what they are supposed to mean. I read that the CURRENT runlevel overrides a DEFAULT. I guess that should be fine, unless what systemctl actually changes are the defaults, and those are overwritten by something else, which means that "sysctl disable" will have no effect. If that is the case, then the warning should be more explicit: - be specific about the fact that "LSB defaults" are what the command is changing - tell me that as a result, the services will not be disabled - tell me WHAT is overriding the defaults that I'm attempting to change - and/or tell me what I am supposed to do to fix the issue ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: systemd 229-4ubuntu21.4 ProcVersionSignature: Ubuntu 4.4.0-133.159-generic 4.4.134 Uname: Linux 4.4.0-133-generic x86_64 NonfreeKernelModules: nvidia_uvm nvidia ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 CurrentDesktop: Unity Date: Wed Aug 15 16:26:28 2018 InstallationDate: Installed on 2013-10-11 (1768 days ago) InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424) MachineType: Acer Aspire V3-571G ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-133-generic.efi.signed root=UUID=5830b30e-69e8-4bb4-8a2b-bc2b43c7414a ro quiet splash vt.handoff=7 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 10/15/2012 dmi.bios.vendor: Acer dmi.bios.version: V2.07 dmi.board.asset.tag: Type2 - Board Asset Tag dmi.board.name: VA50_HC_CR dmi.board.vendor: Acer dmi.board.version: Type2 - Board Version dmi.chassis.type: 10 dmi.chassis.vendor: Acer dmi.chassis.version: V2.07 dmi.modalias: dmi:bvnAcer:bvrV2.07:bd10/15/2012:svnAcer:pnAspireV3-571G:pvrV2.07:rvnAcer:rnVA50_HC_CR:rvrType2-BoardVersion:cvnAcer:ct10:cvrV2.07: dmi.product.name: Aspire V3-571G dmi.product.version: V2.07 dmi.sys.vendor: Acer To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1787225/+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 1857036] Re: `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE): Operation not permitted` error when run inside a container.
Confirmed, I still was able to reproduce this on groovy with sudo 1.8.31-1ubuntu1, but groovy is now updated to 1.9.0-1ubuntu1 and now the behavior is correct. >From the bug report mentioned in comment #3, I found the commit with the corresponding patch. I've added a focal bug task and marked the groovy one fixed. Although it's just a warning, it's pretty noticeable and could cause confusion so I think an SRU may be warranted. ** Patch added: "712afe03195e9747a442cac633b03dc5c8bfa54c.patch" https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1857036/+attachment/5383102/+files/712afe03195e9747a442cac633b03dc5c8bfa54c.patch ** Changed in: sudo (Ubuntu Groovy) Status: Confirmed => Fix Released ** Changed in: sudo (Ubuntu Focal) Status: New => Triaged -- 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/1857036 Title: `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE): Operation not permitted` error when run inside a container. Status in sudo package in Ubuntu: Fix Released Status in sudo source package in Focal: Triaged Status in sudo source package in Groovy: Fix Released Bug description: When using `sudo --login --user USERNAME` with Ubuntu Focal currently, it will correctly operate but it will also throw the following error before continuing with the logon process (which completes successfully except for the stated error): sudo: setrlimit(RLIMIT_CORE): Operation not permitted A full run of this was tested in a Focal LXD container after dropping to a root shell to reproduce (arstotzka is the host system, focal-test is the test container): teward@arstotzka:~$ lxc shell focal-test root@focal-test:~# sudo --login --user ubuntu sudo: setrlimit(RLIMIT_CORE): Operation not permitted To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. ubuntu@focal-test:~$ This appears to be similar to this issue identified on RedHat's tracker: https://bugzilla.redhat.com/show_bug.cgi?id=1773148 ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: sudo 1.8.29-1ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-72.81-generic 4.15.18 Uname: Linux 4.15.0-72-generic x86_64 ApportVersion: 2.20.11-0ubuntu14 Architecture: amd64 Date: Thu Dec 19 17:16:31 2019 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash SourcePackage: sudo UpgradeStatus: No upgrade log present (probably fresh install) VisudoCheck: /etc/sudoers: parsed OK /etc/sudoers.d/90-cloud-init-users: parsed OK /etc/sudoers.d/README: parsed OK To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1857036/+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 1857036] Re: `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE): Operation not permitted` error when run inside a container.
** Also affects: sudo (Ubuntu Groovy) Importance: Undecided Status: Confirmed ** Also affects: sudo (Ubuntu Focal) Importance: Undecided Status: New -- 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/1857036 Title: `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE): Operation not permitted` error when run inside a container. Status in sudo package in Ubuntu: Confirmed Status in sudo source package in Focal: New Status in sudo source package in Groovy: Confirmed Bug description: When using `sudo --login --user USERNAME` with Ubuntu Focal currently, it will correctly operate but it will also throw the following error before continuing with the logon process (which completes successfully except for the stated error): sudo: setrlimit(RLIMIT_CORE): Operation not permitted A full run of this was tested in a Focal LXD container after dropping to a root shell to reproduce (arstotzka is the host system, focal-test is the test container): teward@arstotzka:~$ lxc shell focal-test root@focal-test:~# sudo --login --user ubuntu sudo: setrlimit(RLIMIT_CORE): Operation not permitted To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. ubuntu@focal-test:~$ This appears to be similar to this issue identified on RedHat's tracker: https://bugzilla.redhat.com/show_bug.cgi?id=1773148 ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: sudo 1.8.29-1ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-72.81-generic 4.15.18 Uname: Linux 4.15.0-72-generic x86_64 ApportVersion: 2.20.11-0ubuntu14 Architecture: amd64 Date: Thu Dec 19 17:16:31 2019 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash SourcePackage: sudo UpgradeStatus: No upgrade log present (probably fresh install) VisudoCheck: /etc/sudoers: parsed OK /etc/sudoers.d/90-cloud-init-users: parsed OK /etc/sudoers.d/README: parsed OK To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1857036/+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 1557157] Re: apparmor profile denied for saslauthd: /run/saslauthd/mux
Can you explain the configuration process for saslauthd with slapd? Or
a copy of your config file would do.
** Changed in: openldap (Ubuntu)
Status: Confirmed => Incomplete
--
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/1557157
Title:
apparmor profile denied for saslauthd: /run/saslauthd/mux
Status in openldap package in Ubuntu:
Incomplete
Bug description:
When using slapd with saslauthd the processes communicate via the
{,/var}/run/saslauthd/mux socket (this is the default location for the
saslauthd server from the sasl2-bin package in the
/etc/default/saslauthd config), but the apparmor profile for
usr.sbin.slapd does not allow access to this socket/file.
Syslog message:
apparmor="DENIED" operation="connect" profile="/usr/sbin/slapd"
name="/run/saslauthd/mux" pid=1880
4 comm="slapd" requested_mask="r" denied_mask="r" fsuid=108 ouid=0
Please add the following line to /etc/apparmor.d/usr.sbin.slapd:
/{,var/}run/saslauthd/mux rw,
Ubuntu version: Ubuntu 14.04.4 LTS
slapd version: 2.4.31-1+nmu2ubu
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1557157/+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 1219529] Re: df -x tmpfs fails to exclude udev (/dev)
20.04's coreutils still has the behavior described in this bug. /dev is listed as type 'udev' by df but df -x udev does not exclude it; df -x devtmpfs does. I wonder if one way to at least resolve the confusion might be to make the code that prints the table display devtmpfs devices as 'devtmpfs'. An obvious alternative would be to make '-x udev' be handled like '-x udev -x devtmpfs'. Another alternative would be to overload '-x tmpfs' to exclude also udev and devtmpfs. It's not clear what the best solution would be. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/1219529 Title: df -x tmpfs fails to exclude udev (/dev) Status in coreutils: New Status in coreutils package in Ubuntu: Triaged Bug description: The command: $ /bin/df -x tmpfs should exclude all filesystems of type tmpfs. The udev filesystem mounted at /dev is of this type: $ stat -f /dev File: "/dev" ID: 0Namelen: 255 Type: tmpfs Block size: 4096 Fundamental block size: 4096 Blocks: Total: 4109101Free: 4109098Available: 4109098 Inodes: Total: 4109101Free: 4108501 However, df still displays this filesystem: $ df -l -x tmpfs Filesystem 1K-blocks Used Available Use% Mounted on ... udev 1643640412 16436392 1% /dev ... ProblemType: Bug DistroRelease: Ubuntu 13.04 Package: coreutils 8.20-3ubuntu5 ProcVersionSignature: Ubuntu 3.8.0-29.42-generic 3.8.13.5 Uname: Linux 3.8.0-29-generic x86_64 ApportVersion: 2.9.2-0ubuntu8.3 Architecture: amd64 Date: Sun Sep 1 15:05:40 2013 InstallationDate: Installed on 2013-08-31 (0 days ago) InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424) MarkForUpload: True ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: coreutils UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/coreutils/+bug/1219529/+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 843306] Re: df ignores fs type none in options
Modern df lists the actual fs types for those 'none' devices. E.g. udev, tmpfs, et al. I'm guessing the reason that '-x none' was not excluding them in this old df version was because the type wasn't literally 'none' but perhaps \0 or else was just not being displayed. In any case, I no longer am reproducing this very old bug, so am closing it out as fixed. ** Changed in: coreutils (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/843306 Title: df ignores fs type none in options Status in coreutils package in Ubuntu: Fix Released Bug description: df appears to ignore the filesystem type "none" when specifying options on the command line. Some example output: gecko@magina ~> df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda2 16018264 5669900 9534672 38% / none 2020908 652 2020256 1% /dev none 202863268 2028564 1% /dev/shm none 2028632 440 2028192 1% /var/run none 2028632 0 2028632 0% /var/lock /dev/sdb6457072296 42896024 390958336 10% /home [four different "none" systems] gecko@magina ~> df -x none Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda2 16018264 5669900 9534672 38% / none 2020908 652 2020256 1% /dev none 202863268 2028564 1% /dev/shm none 2028632 440 2028192 1% /var/run none 2028632 0 2028632 0% /var/lock /dev/sdb6457072296 42896032 390958328 10% /home [would expect "none" systems not to appear] gecko@magina ~> df -t none df: no file systems processed [would expect only "none" systems to appear] I have no idea on whether this behaviour is intentional, however I do know that it causes a minor bug to appear in the munin package - the df plugin is unable to ignore a bunch of filesystems even though it is configured to do so by default. ProblemType: Bug DistroRelease: Ubuntu 11.04 Package: coreutils 8.5-1ubuntu6 ProcVersionSignature: Ubuntu 2.6.38-10.46-generic 2.6.38.7 Uname: Linux 2.6.38-10-generic x86_64 Architecture: amd64 Date: Tue Sep 6 23:48:25 2011 EcryptfsInUse: Yes InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429) ProcEnviron: LANGUAGE=en_GB:en PATH=(custom, user) LANG=en_GB.UTF-8 SHELL=/usr/bin/fish SourcePackage: coreutils UpgradeStatus: Upgraded to natty on 2011-08-04 (33 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/843306/+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 1495711] Re: df only shows one mountpoint
I'm not able to reproduce this on focal, with multiple nfs mount points mounted. If it is still reproducible on newer versions of Ubuntu, can you provide the full output of df, as well as log files /etc/fstab and /etc/exports from the nfs server? The output of dmesg (from boot) from the client may also give clues. ** Changed in: coreutils (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/1495711 Title: df only shows one mountpoint Status in coreutils package in Ubuntu: Incomplete Bug description: Description: Ubuntu 14.04.3 LTS Release: 14.04 coreutils: Installed: 8.21-1ubuntu5.1 Candidate: 8.21-1ubuntu5.1 Version table: *** 8.21-1ubuntu5.1 0 500 http://nl.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages 100 /var/lib/dpkg/status 8.21-1ubuntu5 0 500 http://nl.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages It seems like df only shows one nfs mountpoint while more are mounted. root@klondike:~# mount | grep nfs 192.168.1.2:/volume1/test1 on /test1 type nfs (rw,vers=4,addr=192.168.1.2,clientaddr=192.168.1.10) 192.168.1.2:/volume1/test2 on /test2 type nfs (rw,vers=4,addr=192.168.1.2,clientaddr=192.168.1.10) 192.168.1.2:/volume1/test3 on /test3 type nfs (rw,vers=4,addr=192.168.1.2,clientaddr=192.168.1.10) 192.168.1.2:/volume1/test4 on /test4 type nfs (rw,vers=4,addr=192.168.1.2,clientaddr=192.168.1.10) root@klondike:~# df -h | grep ^192.168.1.2 192.168.1.2:/volume1/test2 8.1T 1.4T 6.8T 17% /test2 root@klondike:~# cat /etc/fstab | grep ^192.168.1.2 192.168.1.2:/volume1/test1 /test1 nfs vers=4,auto 0 0 192.168.1.2:/volume1/test2 /test2 nfs vers=4,auto 0 0 192.168.1.2:/volume1/test3 /test3 nfs vers=4,auto 0 0 192.168.1.2:/volume1/test4 /test4 nfs vers=4,auto 0 0 root@klondike:~# cat /proc/mounts | grep ^192.168.1.2 192.168.1.2:/volume1/test1 /test1 nfs4 rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.10,local_lock=none,addr=192.168.1.2 0 0 192.168.1.2:/volume1/test2 /test2 nfs4 rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.10,local_lock=none,addr=192.168.1.2 0 0 192.168.1.2:/volume1/test3 /test3 nfs4 rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.10,local_lock=none,addr=192.168.1.2 0 0 192.168.1.2:/volume1/test4 /test4 nfs4 rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.10,local_lock=none,addr=192.168.1.2 0 0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1495711/+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 1030519] Re: /proc/self/exe is not necessarily correct on overlayfs
While there was some discussion by the kernel community around this on the associated bug, it appears to remain unresolved there. But it looks to me that Robie's assessment still stands that it wouldn't be appropriate to change this in just the logwatch patch alone. Given the age of this bug, I'm going to mark the logwatch task closed as I don't think there's any further action we can take on it at this time. ** Changed in: logwatch (Ubuntu) Status: Incomplete => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to perl in Ubuntu. https://bugs.launchpad.net/bugs/1030519 Title: /proc/self/exe is not necessarily correct on overlayfs Status in logwatch package in Ubuntu: Invalid Status in perl package in Ubuntu: Confirmed Bug description: Perl should check the value from /proc/self/exe for correctness. I'll open a bug in logwatch also, however there are likely many more applications that make use of this and depend on it's correctness. Bug number 1007089 tracks the overlayfs bug. /etc/cron.daily/00logwatch: sh: 1: /bin/perl: not found sh: 1: /bin/perl: not found system 'cat '/var/log/mail.log' '/var/log/mail.log.1' | /bin/perl /usr/share/logwatch/scripts/shared/expandrepeats ''| /bin/perl /usr/share/logwatch/scripts/shared/applystddate ''>/tmp/logwatch.BMbdlb_J/maillog' failed: 32512 at /usr/sbin/logwatch line 871. run-parts: /etc/cron.daily/00logwatch exited with return code 2 ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: perl 5.14.2-6ubuntu2 ProcVersionSignature: Ubuntu 3.2.0-23.31-lowlatency-pae 3.2.14 Uname: Linux 3.2.0-23-lowlatency-pae i686 ApportVersion: 2.0.1-0ubuntu8 Architecture: i386 Date: Sun Jul 29 09:06:20 2012 SourcePackage: perl UpgradeStatus: Upgraded to precise on 2012-01-03 (208 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/logwatch/+bug/1030519/+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 1864869] Re: ICU returns unexpected length for string
Per the PHP bug, this appears not to be in php itself but rather higher up the stack. Reassigning to ICU for now. ** Also affects: icu (Ubuntu) Importance: Undecided Status: New ** Changed in: php7.4 (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to icu in Ubuntu. https://bugs.launchpad.net/bugs/1864869 Title: ICU returns unexpected length for string Status in icu package in Ubuntu: New Status in php7.4 package in Ubuntu: Invalid Bug description: Calculating the grapheme string length for the word 'नमस्ते' returns 3 instead of 4. This version returns unexpected result of 3: ICU version 65.1 ICU Data version 65.1 ICU TZData version2019c ICU Unicode version 12.1 This version returns the expected result of 4: ICU version => 63.1 ICU Data version => 63.1 ICU TZData version => 2018e ICU Unicode version => 11.0 PHP says this is an upstream issue: https://bugs.php.net/bug.php?id=79308 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/icu/+bug/1864869/+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 1866303] Re: slapd crash with pwdAccountLockedTime and stacked overlays
We're no longer looking at backporting fixes for disco. This looks suitable for SRU so the other proposed series tasks are valid, and this is already in the server-next queue. ** Changed in: openldap (Ubuntu Disco) Status: New => Won't Fix -- 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/1866303 Title: slapd crash with pwdAccountLockedTime and stacked overlays Status in openldap package in Ubuntu: Fix Released Status in openldap source package in Xenial: New Status in openldap source package in Bionic: New Status in openldap source package in Disco: Won't Fix Status in openldap source package in Eoan: New Status in openldap package in Debian: Unknown Bug description: Hello, Please merge openldap 2.4.49+dfsg-2 from Debian unstable to fix an issue in the ppolicy overlay that can crash slapd. Please also consider SRUing the patch after it has had some testing time. Upstream: https://openldap.org/its/?findid=9171 Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953150 The ingredients for the crash are: 1: ppolicy overlay configured with pwdLockout: TRUE 2. smbk5pwd overlay stacked after ppolicy 3. an account locked out via pwdAccountLockedTime 4. a client binding to the locked-out account and also requesting the ppolicy control The buggy code is not as specific as the above steps, so I suspect there are probably other configurations or steps that can trigger the same crash. I will attach my test script and data for reproducing the crash. Expected output (last lines): [ ok ] Starting OpenLDAP: slapd. slapd running ldap_bind: Invalid credentials (49) slapd running Actual output (last lines): [ ok ] Starting OpenLDAP: slapd. slapd running ldap_bind: Invalid credentials (49) slapd dead To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1866303/+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 1689833] Re: OpenVPN server does not start properly on boot
** Changed in: openvpn (Ubuntu) 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/1689833 Title: OpenVPN server does not start properly on boot Status in openvpn package in Ubuntu: Triaged Status in systemd package in Ubuntu: Invalid Bug description: OpenVPN intermittently fails to bind to local address during boot on Ubuntu Server 16.04.2 LTS. Sometimes it succeeds, sometimes it does not. /var/log/openvpn.log Wed May 10 15:42:02 2017 OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Feb 2 2016 Wed May 10 15:42:02 2017 library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08 Wed May 10 15:42:02 2017 Diffie-Hellman initialized with 2048 bit key Wed May 10 15:42:02 2017 Control Channel Authentication: using './easy-rsa/keys/ta.key' as a OpenVPN static key file Wed May 10 15:42:02 2017 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Wed May 10 15:42:02 2017 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Wed May 10 15:42:02 2017 Socket Buffers: R=[212992->212992] S=[212992->212992] Wed May 10 15:42:02 2017 TCP/UDP: Socket bind failed on local address [AF_INET]192.168.4.254:1194: Cannot assign requested address Wed May 10 15:42:02 2017 Exiting due to fatal error In case it does not start, running 'sudo service openvpn start' fixes that problem. /var/log/openvpn.log Wed May 10 15:42:43 2017 OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Feb 2 2016 Wed May 10 15:42:43 2017 library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08 Wed May 10 15:42:43 2017 Diffie-Hellman initialized with 2048 bit key Wed May 10 15:42:43 2017 Control Channel Authentication: using './easy-rsa/keys/ta.key' as a OpenVPN static key file Wed May 10 15:42:43 2017 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Wed May 10 15:42:43 2017 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Wed May 10 15:42:43 2017 Socket Buffers: R=[212992->212992] S=[212992->212992] Wed May 10 15:42:43 2017 ROUTE_GATEWAY 192.168.4.1/255.255.255.0 IFACE=ens4 HWADDR=52:54:00:f0:26:0c Wed May 10 15:42:43 2017 TUN/TAP device tun0 opened Wed May 10 15:42:43 2017 TUN/TAP TX queue length set to 100 Wed May 10 15:42:43 2017 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 Wed May 10 15:42:43 2017 /sbin/ip link set dev tun0 up mtu 1500 Wed May 10 15:42:43 2017 /sbin/ip addr add dev tun0 local 172.16.1.1 peer 172.16.1.2 Wed May 10 15:42:43 2017 /sbin/ip route add 172.16.1.0/24 via 172.16.1.2 Wed May 10 15:42:43 2017 GID set to nogroup Wed May 10 15:42:43 2017 UID set to nobody Wed May 10 15:42:43 2017 UDPv4 link local (bound): [AF_INET]192.168.4.254:1194 Wed May 10 15:42:43 2017 UDPv4 link remote: [undef] Wed May 10 15:42:43 2017 MULTI: multi_init called, r=256 v=256 Wed May 10 15:42:43 2017 IFCONFIG POOL: base=172.16.1.4 size=62, ipv6=0 Wed May 10 15:42:43 2017 IFCONFIG POOL LIST Wed May 10 15:42:43 2017 Initialization Sequence Completed My guess is that systemd starts OpenVPN too early before the network is brought up sufficiently. Running 'sudo systemctl edit --full openvpn' and adding 'Wants=network-online.target' does not change that behaviour. user@server:~$ sudo systemd-analyze critical-chain graphical.target @2.160s └─multi-user.target @2.159s └─ntp.service @2.054s +104ms └─remote-fs.target @2.052s └─remote-fs-pre.target @2.052s └─open-iscsi.service @1.993s +57ms └─iscsid.service @1.942s +47ms └─network-online.target @1.941s └─network.target @1.929s └─networking.service @1.793s +134ms └─apparmor.service @1.140s +395ms └─local-fs.target @1.140s └─local-fs-pre.target @1.139s └─lvm2-monitor.service @602ms +536ms └─lvm2-lvmetad.service @773ms └─systemd-journald.socket @574ms └─-.slice @500ms The boot time is quite short. Clean install with the additional packages ntp and openssh-server. This happens both on bare metal and as a Virtual Machine (KVM) as well. /etc/openvpn/server.conf local 192.168.4.254 port 1194 proto udp dev tun ca ./easy-rsa/keys/ca.crt cert ./easy-rsa/keys/crt.crt key ./easy-rsa/keys/key.key dh ./easy-rsa/keys/dh2048.pem tls-auth ./easy-rsa/keys/ta.key 0 server 172.16.1.0 255.255.255.0 ifconfig-pool-persist ipp.txt push "route 192.168.0.0 255.255.255.0" push "route 192.168.4.0
[Touch-packages] [Bug 1861472] Re: upgrade from fresh bionic to focal needlessly prompts user
** Bug watch added: Debian Bug tracker #951220 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951220 ** Also affects: openssh (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951220 Importance: Unknown Status: Unknown -- 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/1861472 Title: upgrade from fresh bionic to focal needlessly prompts user Status in openssh package in Ubuntu: Triaged Status in openssh package in Debian: Unknown Bug description: Upgrading from a fresh 18.04 LTS install to focal unexpectedly prompts for how to handle a change to /etc/ssh/sshd_config To reproduce the issue: lxc launch ubuntu:18.04 u18 lxc exec u18 -- bash # within container do-release-upgrade -d # select restart services when prompted Eventually you'll be prompted to accept changes to /etc/ssh/sshd_config or not because of "local changes". Thanks ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: openssh-server 1:8.1p1-5 ProcVersionSignature: Ubuntu 4.15.0-62.69-generic 4.15.18 Uname: Linux 4.15.0-62-generic x86_64 ApportVersion: 2.20.11-0ubuntu16 Architecture: amd64 Date: Fri Jan 31 03:37:55 2020 ProcEnviron: TERM=rxvt-unicode-256color PATH=(custom, no user) LANG=C.UTF-8 SourcePackage: openssh UpgradeStatus: Upgraded to focal on 2020-01-31 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1861472/+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 1862770] Re: MySQL autopkgtest regressed in Focal release pocket
*** This bug is a duplicate of bug 1862364 *** https://bugs.launchpad.net/bugs/1862364 ** This bug has been marked a duplicate of bug 1862364 mysql-8.0 FTBFS (focal) because of hardcoded date in test -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to shadow in Ubuntu. https://bugs.launchpad.net/bugs/1862770 Title: MySQL autopkgtest regressed in Focal release pocket Status in mysql-8.0 package in Ubuntu: New Status in shadow package in Ubuntu: New Bug description: http://autopkgtest.ubuntu.com/packages/m/mysql-8.0/focal/amd64 https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/amd64/m/mysql-8.0/20200211_122839_60bab@/log.gz ... 63%] main.events_1 [ fail ] Test ended at 2020-02-11 12:06:00 CURRENT_TEST: main.events_1 mysqltest: At line 69: Query 'ALTER EVENT event_starts_test ON SCHEDULE AT '2020-02-02 20:00:02'' failed. ERROR 1589 (HY000): Event execution time is in the past and ON COMPLETION NOT PRESERVE is set. The event was not changed. Specify a time in the future. The result from queries just before the failure was: drop event if exists event1; Warnings: Note 1305Event event1 does not exist create event event1 on schedule every 15 minute starts now() ends date_add(now(), interval 5 hour) DO begin end; alter event event1 rename to event2 enable; alter event event2 disable; alter event event2 enable; alter event event2 on completion not preserve; alter event event2 on schedule every 1 year on completion preserve rename to event3 comment "new comment" do begin select 1; end__ alter event event3 rename to event2; drop event event2; create event event2 on schedule every 2 second starts now() ends date_add(now(), interval 5 hour) comment "some" DO begin end; drop event event2; CREATE EVENT event_starts_test ON SCHEDULE EVERY 10 SECOND COMMENT "" DO SELECT 1; SELECT interval_field, interval_value, event_definition FROM information_schema.events WHERE event_name='event_starts_test'; INTERVAL_FIELDINTERVAL_VALUE EVENT_DEFINITION SECOND10 SELECT 1 SELECT execute_at IS NULL, starts IS NULL, ends IS NULL, event_comment FROM information_schema.events WHERE event_schema='events_test' AND event_name='event_starts_test'; execute_at IS NULLstarts IS NULL ends IS NULLEVENT_COMMENT 1 0 1 safe_process[25029]: Child process: 25030, exit: 1 - the logfile can be found in '/tmp/tmp.YL1y5O4jCj/var/log/main.events_1/events_1.log' ... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mysql-8.0/+bug/1862770/+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 1861472] Re: upgrade from fresh bionic to focal needlessly prompts user
So, the trivial fix is to simply append 203e9b92fe3623aeba277ee44297f7dd to openssh-server.ucf-md5sum, as Marc had suggested above. I can proceed with that as the fix. --- But this suggests a few direct questions/thoughts: 0. Does the installer use the openssh-server.ucf-md5sum from the new package, or the previously installed one? If the latter, then the md5sum will need added via SRU. 1. Where in the process did the md5sum get out of sync? I'm not spotting conf changes from the CVE patches by our security team, so looks like this got to us via debian? 2. Our merge review processes need to account for conf file changes with ucf packages. Although, in this case openssh presumably got sync'd so Ubuntu-side process changes would not have caught it. 3. There have been other reports of similar misbehavior with wrongly detected conf file changes (Robie's LP #1747464 mentioned above may be one, there's likely others). Is ucf also being used in these cases, and are those problems likewise caused by missing md5sums in their packages? 4. Is this failure mode something that can be caught in autopkgtests? If so, then per-package checks seem warranted to prevent this in the future. 5. Even better than #3 would be a distro-wide CI check for all packages using ucf, to ensure all distro-default installed conf files (from all pockets) have their conf file md5sums registered. In addition, some broader scoped / philosophical / "dumb" questions: 1. Are md5sums the best way to identify config file changes? E.g. if the change is just a timestamp and commented out line (such as in this case) that shouldn't count as a "change". What about like filtering out commented lines, and checksumming that? 2. Why are commented out lines included in distro-provided conf files? Is it just for documentation, in which case those would be better kept elsewhere and just referenced? (Yes, this is more a debian/upstream policy question which we probably don't have say on...) 3. Is upgrade the right time to be prompting users about config file changes, even if they have legitimate local config changes? With cloud instances, unattended-upgrades, etc. it's not so safe to assume a human is babysitting the dist-upgrade, and breakages during dist-upgrades can be pretty catastrophic for users. It's also a frequently seen pattern in our own bug triaging workloads. Are there any other ways to solve this need? (Yes, much of the above is better fodder for blogs, and no need to discuss it in depth here...) -- 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/1861472 Title: upgrade from fresh bionic to focal needlessly prompts user Status in openssh package in Ubuntu: Triaged Bug description: Upgrading from a fresh 18.04 LTS install to focal unexpectedly prompts for how to handle a change to /etc/ssh/sshd_config To reproduce the issue: lxc launch ubuntu:18.04 u18 lxc exec u18 -- bash # within container do-release-upgrade -d # select restart services when prompted Eventually you'll be prompted to accept changes to /etc/ssh/sshd_config or not because of "local changes". Thanks ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: openssh-server 1:8.1p1-5 ProcVersionSignature: Ubuntu 4.15.0-62.69-generic 4.15.18 Uname: Linux 4.15.0-62-generic x86_64 ApportVersion: 2.20.11-0ubuntu16 Architecture: amd64 Date: Fri Jan 31 03:37:55 2020 ProcEnviron: TERM=rxvt-unicode-256color PATH=(custom, no user) LANG=C.UTF-8 SourcePackage: openssh UpgradeStatus: Upgraded to focal on 2020-01-31 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1861472/+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 1861472] Re: upgrade from fresh bionic to focal needlessly prompts user
Marc's comment #3 seems plausible: stirling:~/ubuntu/Openssh$ lxc exec u18 -- bash root@u18:~# md5sum /etc/ssh/sshd_config 203e9b92fe3623aeba277ee44297f7dd /etc/ssh/sshd_config root@u18:~# grep -c 203e9b92fe3623aeba277ee44297f7dd /usr/share/openssh/sshd_config.md5sum 0 root@u18:~# Looking at sshd_config on a fresh installed 18.04 lxc and a fresh 20.04, the sshd_config files do indeed differ by exactly the diff shown during upgrade (and provided in comment #2). The md5sum checking was introduced in Debian on Dec 2016 with openssh (1:7.4p1-1) * Start handling /etc/ssh/sshd_config using ucf. The immediate motivation for this is to deal with deprecations of options related to protocol 1, but something like this has been needed for a long time (closes: #419574, #848089): - sshd_config is now a slightly-patched version of upstream's, and only contains non-default settings (closes: #147201). - I've included as many historical md5sums of default versions of sshd_config as I could reconstruct from version control, but I'm sure I've missed some. - Explicitly synchronise the debconf database with the current configuration file state in openssh-server.config, to ensure that the PermitRootLogin setting is properly preserved. - UsePrivilegeSeparation now defaults to the stronger "sandbox" rather than "yes", per upstream. It's implemented in openssh-server.postinst: ... ... sed statements to customize $new_config from upstream for debian ... mkdir -p /etc/ssh ucf --three-way --debconf-ok \ --sum-file /usr/share/openssh/sshd_config.md5sum \ "$new_config" /etc/ssh/sshd_config ucfr openssh-server /etc/ssh/sshd_config AFAICT the /usr/share/openssh/sshd_config.md5sum is identical on freshly lxc'd 18.04 and 20.04. Running the ucf command on a focal lxc container with the 18.04 and 20.04 sshd_config files captured from fresh lxc installs reproduces the same debconf prompt about the changed config, and then issues this output: stirling:~/ubuntu/Openssh/fix-apt-misprompt$ sudo ucf --no-action --three-way --debconf-ok --sum-file /usr/share/openssh/sshd_config.md5sum ./sshd_config.20.04 ./sshd_config.18.04 [sudo] password for bryce: Replacing config file /home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.18.04 with new version cp -pf /home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.18.04 /home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.18.04.ucf-old cp -pf /home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.20.04 /home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.18.04 cp -pf /var/lib/ucf/hashfile.6 /var/lib/ucf/hashfile.7 cp -pf /var/lib/ucf/hashfile.5 /var/lib/ucf/hashfile.6 cp -pf /var/lib/ucf/hashfile.4 /var/lib/ucf/hashfile.5 cp -pf /var/lib/ucf/hashfile.3 /var/lib/ucf/hashfile.4 cp -pf /var/lib/ucf/hashfile.2 /var/lib/ucf/hashfile.3 cp -pf /var/lib/ucf/hashfile.1 /var/lib/ucf/hashfile.2 cp -pf /var/lib/ucf/hashfile.0 /var/lib/ucf/hashfile.1 cp -pf /var/lib/ucf/hashfile /var/lib/ucf/hashfile.0 (egrep -v "[[:space:]]\/home\/bryce\/ubuntu\/Openssh\/fix\-apt\-misprompt\/sshd_config\.18\.04$" "/var/lib/ucf/hashfile" md5sum "/home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.20.04" | sed "s|/home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.20.04|/home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.18.04|"; ) | sort > "/var/lib/ucf/hashfile" cp -pf /home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.20.04 /var/lib/ucf/cache/:home:bryce:ubuntu:Openssh:fix-apt-misprompt:sshd_config.18.04 If I append the bionic sshd_config md5sum to the list and then check against that, no prompt is displayed, with the following output: $ (cat /usr/share/openssh/sshd_config.md5sum; sudo md5sum sshd_config.18.04 | cut -d' ' -f1) > /tmp/sshd_config.md5sum $ sudo ucf --no-action --three-way --debconf-ok --sum-file /tmp/sshd_config.md5sum ./sshd_config.20.04 ./sshd_config.18.04 cp -pf /home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.20.04 /home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.18.04 cp -pf /var/lib/ucf/hashfile.6 /var/lib/ucf/hashfile.7 cp -pf /var/lib/ucf/hashfile.5 /var/lib/ucf/hashfile.6 cp -pf /var/lib/ucf/hashfile.4 /var/lib/ucf/hashfile.5 cp -pf /var/lib/ucf/hashfile.3 /var/lib/ucf/hashfile.4 cp -pf /var/lib/ucf/hashfile.2 /var/lib/ucf/hashfile.3 cp -pf /var/lib/ucf/hashfile.1 /var/lib/ucf/hashfile.2 cp -pf /var/lib/ucf/hashfile.0 /var/lib/ucf/hashfile.1 cp -pf /var/lib/ucf/hashfile /var/lib/ucf/hashfile.0 (egrep -v "[[:space:]]\/home\/bryce\/ubuntu\/Openssh\/fix\-apt\-misprompt\/sshd_config\.18\.04$" "/var/lib/ucf/hashfile" md5sum "/home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.20.04" | sed "s|/home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.20.04|/home/bryce/ubuntu/Openssh/fix-apt-misprompt/sshd_config.18.04|"; ) | sort > "/var/lib/ucf/hashfile" cp -pf
[Touch-packages] [Bug 1861615] Re: package libldap-2.4-2:amd64 2.4.45+dfsg-1ubuntu1.4 failed to install/upgrade: package is in a very bad inconsistent state; you should reinstall it before attempting
Thank you for taking the time to file a bug report. Unfortunately the collected logs don't indicate what the issue with ldap is. There don't seem to be other reports of this issue, so it appears not to be a systemic problem. Best guess, lacking better information, is that there was a local config or other problem previously when updating libldab, that's only been revealed now. I would probably attempt what the error message suggests, and remove the ldap package and reinstall it. Then watch for any errors or warnings that are issued, which may give better clues what's wrong. Since it seems likely to me that this is a local configuration problem, rather than a bug in Ubuntu, I am marking this bug as 'Incomplete'. However, if you believe that this is really a bug in ubuntu, then we would be grateful if you would provide a more complete description of the problem with steps to reproduce, explain why you believe this is a bug in ubuntu rather than a problem specific to your system, and then change the bug status back to 'New'. For local configuration issues, you can find assistance here: http://www.ubuntu.com/support/community ** Changed in: openldap (Ubuntu) Status: New => Incomplete -- 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/1861615 Title: package libldap-2.4-2:amd64 2.4.45+dfsg-1ubuntu1.4 failed to install/upgrade: package is in a very bad inconsistent state; you should reinstall it before attempting configuration Status in openldap package in Ubuntu: Incomplete Bug description: didnt work ProblemType: Package DistroRelease: Ubuntu 18.04 Package: libldap-2.4-2:amd64 2.4.45+dfsg-1ubuntu1.4 ProcVersionSignature: Ubuntu 4.15.0-29.31-generic 4.15.18 Uname: Linux 4.15.0-29-generic x86_64 NonfreeKernelModules: kpatch_livepatch_Ubuntu_4_15_0_29_31_generic_42 ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 Date: Sun Feb 2 08:12:58 2020 DuplicateSignature: package:libldap-2.4-2:amd64:2.4.45+dfsg-1ubuntu1.4 Setting up libkf5notifications-data (5.44.0-0ubuntu1) ... dpkg: error processing package libldap-2.4-2:amd64 (--configure): package is in a very bad inconsistent state; you should ErrorMessage: package is in a very bad inconsistent state; you should reinstall it before attempting configuration InstallationDate: Installed on 2020-02-02 (0 days ago) InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725) Python3Details: /usr/bin/python3.6, Python 3.6.9, python3-minimal, 3.6.7-1~18.04 PythonDetails: N/A RelatedPackageVersions: dpkg 1.19.0.5ubuntu2.3 apt 1.6.3 SourcePackage: openldap Title: package libldap-2.4-2:amd64 2.4.45+dfsg-1ubuntu1.4 failed to install/upgrade: package is in a very bad inconsistent state; you should reinstall it before attempting configuration UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1861615/+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 1861472] Re: upgrade from fresh bionic to focal needlessly prompts user
I'm able to easily reproduce this in lxc using the steps provided. ** Changed in: openssh (Ubuntu) Importance: Undecided => High ** Changed in: openssh (Ubuntu) Status: New => Triaged ** Tags added: server-next -- 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/1861472 Title: upgrade from fresh bionic to focal needlessly prompts user Status in openssh package in Ubuntu: Triaged Bug description: Upgrading from a fresh 18.04 LTS install to focal unexpectedly prompts for how to handle a change to /etc/ssh/sshd_config To reproduce the issue: lxc launch ubuntu:18.04 u18 lxc exec u18 -- bash # within container do-release-upgrade -d # select restart services when prompted Eventually you'll be prompted to accept changes to /etc/ssh/sshd_config or not because of "local changes". Thanks ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: openssh-server 1:8.1p1-5 ProcVersionSignature: Ubuntu 4.15.0-62.69-generic 4.15.18 Uname: Linux 4.15.0-62-generic x86_64 ApportVersion: 2.20.11-0ubuntu16 Architecture: amd64 Date: Fri Jan 31 03:37:55 2020 ProcEnviron: TERM=rxvt-unicode-256color PATH=(custom, no user) LANG=C.UTF-8 SourcePackage: openssh UpgradeStatus: Upgraded to focal on 2020-01-31 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1861472/+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 1861177] Re: seccomp_rule_add is very slow
** Tags added: server-next -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1861177 Title: seccomp_rule_add is very slow Status in snapd: New Status in libseccomp package in Ubuntu: Triaged Bug description: There is a known and patched issue with version 2.4 of libseccomp where certain operations have a large performance regression. This is causing some packages that use libseccomp such as container orchestration systems to occasionally time out or otherwise fail under certain workloads. Please consider porting the patch into the various Ubuntu versions that have version 2.4 of libseccomp and into the backports. The performance patch from version 2.5 (yet to be released) applies cleanly on top of the 2.4 branch of libseccomp. For more information, and for a copy of the patch (which can also be cherry picked from the upstream libseccomp repos) see the similar Debian issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913 To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1861177/+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 1861177] Re: seccomp_rule_add is very slow
2.4.1 is currently available from xenial, bionic, disco, eoan; focal carries 2.4.2. None of these carry the patches for this bug report yet. ** Changed in: libseccomp (Ubuntu) Importance: Undecided => High ** Changed in: libseccomp (Ubuntu) Status: New => Triaged -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1861177 Title: seccomp_rule_add is very slow Status in snapd: New Status in libseccomp package in Ubuntu: Triaged Bug description: There is a known and patched issue with version 2.4 of libseccomp where certain operations have a large performance regression. This is causing some packages that use libseccomp such as container orchestration systems to occasionally time out or otherwise fail under certain workloads. Please consider porting the patch into the various Ubuntu versions that have version 2.4 of libseccomp and into the backports. The performance patch from version 2.5 (yet to be released) applies cleanly on top of the 2.4 branch of libseccomp. For more information, and for a copy of the patch (which can also be cherry picked from the upstream libseccomp repos) see the similar Debian issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913 To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1861177/+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 1861177] Re: seccomp_rule_add is very slow
The patch mentioned in the OP is attached for reference. Per [1] it was proposed for inclusion in Debian last November as patches db- consolidate-some-of-the-code-which-adds-rules-to-.patch and db-add- shadow-transactions.patch. The corresponding bug report upstream is [2]. 1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913 2: https://github.com/seccomp/libseccomp/issues/153 ** Bug watch added: Debian Bug tracker #943913 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913 ** Bug watch added: github.com/seccomp/libseccomp/issues #153 https://github.com/seccomp/libseccomp/issues/153 ** Patch added: "0001-Cherry-pick-upstream-commits-21b98d8-and-19af04d.patch" https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1861177/+attachment/5323922/+files/0001-Cherry-pick-upstream-commits-21b98d8-and-19af04d.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1861177 Title: seccomp_rule_add is very slow Status in snapd: New Status in libseccomp package in Ubuntu: Triaged Bug description: There is a known and patched issue with version 2.4 of libseccomp where certain operations have a large performance regression. This is causing some packages that use libseccomp such as container orchestration systems to occasionally time out or otherwise fail under certain workloads. Please consider porting the patch into the various Ubuntu versions that have version 2.4 of libseccomp and into the backports. The performance patch from version 2.5 (yet to be released) applies cleanly on top of the 2.4 branch of libseccomp. For more information, and for a copy of the patch (which can also be cherry picked from the upstream libseccomp repos) see the similar Debian issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913 To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1861177/+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 1860686] Re: package dnsmasq-base 2.75-1ubuntu0.16.04.5 failed to install/upgrade: package is in a very bad inconsistent state; you should reinstall it before attempting configu
While the error message mentions dnsmasq, the only errors I'm spotting in the log file involve corefonts: Err:1 http://downloads.sourceforge.net/corefonts/impact32.exe Protocol "http" not supported or disabled in libcurl 0% [Working] E: Failed to fetch https://managedway.dl.sourceforge.net/project/corefonts/the fonts/final/impact32.exe Protocol "http" not supported or disabled in libcurl Perhaps this relates to upstream bug https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=912956 ? ** Bug watch added: Debian Bug tracker #912956 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912956 ** Changed in: dnsmasq (Ubuntu) Status: New => Incomplete ** Package changed: dnsmasq (Ubuntu) => msttcorefonts (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1860686 Title: package dnsmasq-base 2.75-1ubuntu0.16.04.5 failed to install/upgrade: package is in a very bad inconsistent state; you should reinstall it before attempting configuration Status in msttcorefonts package in Ubuntu: Incomplete Bug description: Continues throwing errors ProblemType: Package DistroRelease: Ubuntu 16.04 Package: dnsmasq-base 2.75-1ubuntu0.16.04.5 ProcVersionSignature: Ubuntu 4.4.0-171.200-generic 4.4.203 Uname: Linux 4.4.0-171-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.21 Architecture: amd64 Date: Thu Jan 23 10:48:05 2020 DuplicateSignature: package:dnsmasq-base:2.75-1ubuntu0.16.04.5 Processing triggers for systemd (229-4ubuntu21.23) ... dpkg: error processing package dnsmasq-base (--configure): package is in a very bad inconsistent state; you should ErrorMessage: package is in a very bad inconsistent state; you should reinstall it before attempting configuration InstallationDate: Installed on 2015-01-19 (1829 days ago) InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.2) RelatedPackageVersions: dpkg 1.18.4ubuntu1.6 apt 1.2.32 SourcePackage: dnsmasq Title: package dnsmasq-base 2.75-1ubuntu0.16.04.5 failed to install/upgrade: package is in a very bad inconsistent state; you should reinstall it before attempting configuration UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/msttcorefonts/+bug/1860686/+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 1857036] Re: `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE): Operation not permitted` error when run inside a container.
The suggested workaround to put "Set disable_coredump false" into /etc/sudo.conf appears to work for me for suppressing the warning in focal lxc containers. -- 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/1857036 Title: `sudo --login --user USERNAME` throws `setrlimit(RLIMIT_CORE): Operation not permitted` error when run inside a container. Status in sudo package in Ubuntu: Confirmed Bug description: When using `sudo --login --user USERNAME` with Ubuntu Focal currently, it will correctly operate but it will also throw the following error before continuing with the logon process (which completes successfully except for the stated error): sudo: setrlimit(RLIMIT_CORE): Operation not permitted A full run of this was tested in a Focal LXD container after dropping to a root shell to reproduce (arstotzka is the host system, focal-test is the test container): teward@arstotzka:~$ lxc shell focal-test root@focal-test:~# sudo --login --user ubuntu sudo: setrlimit(RLIMIT_CORE): Operation not permitted To run a command as administrator (user "root"), use "sudo ". See "man sudo_root" for details. ubuntu@focal-test:~$ This appears to be similar to this issue identified on RedHat's tracker: https://bugzilla.redhat.com/show_bug.cgi?id=1773148 ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: sudo 1.8.29-1ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-72.81-generic 4.15.18 Uname: Linux 4.15.0-72-generic x86_64 ApportVersion: 2.20.11-0ubuntu14 Architecture: amd64 Date: Thu Dec 19 17:16:31 2019 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash SourcePackage: sudo UpgradeStatus: No upgrade log present (probably fresh install) VisudoCheck: /etc/sudoers: parsed OK /etc/sudoers.d/90-cloud-init-users: parsed OK /etc/sudoers.d/README: parsed OK To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1857036/+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 1785383] Re: missing EDNS0 record confuses systemd-resolved
** Tags added: server-next
--
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/1785383
Title:
missing EDNS0 record confuses systemd-resolved
Status in systemd:
Unknown
Status in dnsmasq package in Ubuntu:
Triaged
Status in systemd package in Ubuntu:
Triaged
Status in dnsmasq source package in Bionic:
Triaged
Status in systemd source package in Bionic:
New
Bug description:
[Impact]
dnsmasq 2.79 and below omits EDNS0 OPT records when returning an empty answer
for a domain it is authoritative for. systemd-resolved seems to get confused by
this in certain circumstances; when using the stub resolver and requesting an
address for which there are no records, there can sometimes be a five
second hang in resolution.
[Fix]
This is fixed by upstream commit
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78
Not sure if it is worth cherry picking? I imagine the most likely
trigger will be dnsmasq on routers which are not likely to be running
Ubuntu, but maybe just in case.
I also think there are some logic issues in systemd-resolved, upstream
bug filed:
https://github.com/systemd/systemd/issues/9785
[Test Case]
Simple-ish test case:
---
IFACE=dummy0
SUBNET=10.0.0
ip link add $IFACE type dummy
ifconfig $IFACE ${SUBNET}.1/24
dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo
--host-record=test.test,${SUBNET}.1 &
dig -t a test.test @10.0.0.1 | grep EDNS
# should return "; EDNS ..."
dig -t test.test @10.0.0.1 | grep EDNS
# again, should return "; EDNS ..." but doesn't
---
To reproduce the systemd-resolved side of the problem
---
# as above, but
# now configure systemd-resolved to look at only 10.0.0.1, then
systemd-resolve --reset-server-features
# should exhibit five second delay then connect, assuming sshd is running :)
ssh test.test
---
[Discussion]
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: dnsmasq-base 2.79-1
ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
Uname: Linux 4.15.0-23-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
Date: Sat Aug 4 11:33:56 2018
InstallationDate: Installed on 2018-05-31 (64 days ago)
InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Release amd64
(20180426)
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
LANG=en_GB.UTF-8
SHELL=/bin/bash
SourcePackage: dnsmasq
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1785383/+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 1785383] Re: missing EDNS0 record confuses systemd-resolved
I've linked to the upstream systemd bug report, although from comment #4
it sounds like it might be a regression caused by a security fix.
As to the dnsmasq patch mentioned in the issue description, what it
appears to be doing is checking if there is a pseudoheader in the
request, and if so adds the edns data structure to the response. I
can't speak to what potential regressions might be concerns here, but
the patch itself looks sensible to me. So, given adequate testing, I
don't see a reason against considering SRU for this.
** Changed in: systemd (Ubuntu)
Status: Confirmed => Triaged
** Also affects: dnsmasq (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: systemd (Ubuntu Bionic)
Importance: Undecided
Status: New
** Changed in: dnsmasq (Ubuntu Bionic)
Status: New => Triaged
--
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/1785383
Title:
missing EDNS0 record confuses systemd-resolved
Status in systemd:
Unknown
Status in dnsmasq package in Ubuntu:
Triaged
Status in systemd package in Ubuntu:
Triaged
Status in dnsmasq source package in Bionic:
Triaged
Status in systemd source package in Bionic:
New
Bug description:
[Impact]
dnsmasq 2.79 and below omits EDNS0 OPT records when returning an empty answer
for a domain it is authoritative for. systemd-resolved seems to get confused by
this in certain circumstances; when using the stub resolver and requesting an
address for which there are no records, there can sometimes be a five
second hang in resolution.
[Fix]
This is fixed by upstream commit
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78
Not sure if it is worth cherry picking? I imagine the most likely
trigger will be dnsmasq on routers which are not likely to be running
Ubuntu, but maybe just in case.
I also think there are some logic issues in systemd-resolved, upstream
bug filed:
https://github.com/systemd/systemd/issues/9785
[Test Case]
Simple-ish test case:
---
IFACE=dummy0
SUBNET=10.0.0
ip link add $IFACE type dummy
ifconfig $IFACE ${SUBNET}.1/24
dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo
--host-record=test.test,${SUBNET}.1 &
dig -t a test.test @10.0.0.1 | grep EDNS
# should return "; EDNS ..."
dig -t test.test @10.0.0.1 | grep EDNS
# again, should return "; EDNS ..." but doesn't
---
To reproduce the systemd-resolved side of the problem
---
# as above, but
# now configure systemd-resolved to look at only 10.0.0.1, then
systemd-resolve --reset-server-features
# should exhibit five second delay then connect, assuming sshd is running :)
ssh test.test
---
[Discussion]
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: dnsmasq-base 2.79-1
ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
Uname: Linux 4.15.0-23-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
Date: Sat Aug 4 11:33:56 2018
InstallationDate: Installed on 2018-05-31 (64 days ago)
InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Release amd64
(20180426)
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
LANG=en_GB.UTF-8
SHELL=/bin/bash
SourcePackage: dnsmasq
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1785383/+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 1785383] Re: missing EDNS0 record confuses systemd-resolved
Targeting to bionic, since disco/eoan/focal are on 2.80 which, per the
OP, should already be carrying the requested 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/1785383
Title:
missing EDNS0 record confuses systemd-resolved
Status in systemd:
Unknown
Status in dnsmasq package in Ubuntu:
Triaged
Status in systemd package in Ubuntu:
Triaged
Status in dnsmasq source package in Bionic:
Triaged
Status in systemd source package in Bionic:
New
Bug description:
[Impact]
dnsmasq 2.79 and below omits EDNS0 OPT records when returning an empty answer
for a domain it is authoritative for. systemd-resolved seems to get confused by
this in certain circumstances; when using the stub resolver and requesting an
address for which there are no records, there can sometimes be a five
second hang in resolution.
[Fix]
This is fixed by upstream commit
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78
Not sure if it is worth cherry picking? I imagine the most likely
trigger will be dnsmasq on routers which are not likely to be running
Ubuntu, but maybe just in case.
I also think there are some logic issues in systemd-resolved, upstream
bug filed:
https://github.com/systemd/systemd/issues/9785
[Test Case]
Simple-ish test case:
---
IFACE=dummy0
SUBNET=10.0.0
ip link add $IFACE type dummy
ifconfig $IFACE ${SUBNET}.1/24
dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo
--host-record=test.test,${SUBNET}.1 &
dig -t a test.test @10.0.0.1 | grep EDNS
# should return "; EDNS ..."
dig -t test.test @10.0.0.1 | grep EDNS
# again, should return "; EDNS ..." but doesn't
---
To reproduce the systemd-resolved side of the problem
---
# as above, but
# now configure systemd-resolved to look at only 10.0.0.1, then
systemd-resolve --reset-server-features
# should exhibit five second delay then connect, assuming sshd is running :)
ssh test.test
---
[Discussion]
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: dnsmasq-base 2.79-1
ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
Uname: Linux 4.15.0-23-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
Date: Sat Aug 4 11:33:56 2018
InstallationDate: Installed on 2018-05-31 (64 days ago)
InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Release amd64
(20180426)
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
LANG=en_GB.UTF-8
SHELL=/bin/bash
SourcePackage: dnsmasq
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1785383/+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 1785383] Re: missing EDNS0 record confuses systemd-resolved
** Bug watch added: github.com/systemd/systemd/issues #9785
https://github.com/systemd/systemd/issues/9785
** Also affects: systemd via
https://github.com/systemd/systemd/issues/9785
Importance: Unknown
Status: Unknown
** Description changed:
- dnsmasq 2.79 and below omits EDNS0 OPT records when returning an empty
- answer for a domain it is authoritative for. systemd-resolved seems to
- get confused by this in certain circumstances; when using the stub
- resolver and requesting an address for which there are no records,
- there can sometimes be a five second hang in resolution.
+ [Impact]
+ dnsmasq 2.79 and below omits EDNS0 OPT records when returning an empty answer
for a domain it is authoritative for. systemd-resolved seems to get confused by
this in certain circumstances; when using the stub resolver and requesting an
address for which there are no records, there can sometimes be a five
second hang in resolution.
- This is fixed by upstream commit
-
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78
+ [Fix]
+ This is fixed by upstream commit
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78
Not sure if it is worth cherry picking? I imagine the most likely
trigger will be dnsmasq on routers which are not likely to be running
Ubuntu, but maybe just in case.
I also think there are some logic issues in systemd-resolved, upstream
bug filed:
https://github.com/systemd/systemd/issues/9785
+ [Test Case]
Simple-ish test case:
---
IFACE=dummy0
SUBNET=10.0.0
ip link add $IFACE type dummy
ifconfig $IFACE ${SUBNET}.1/24
dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo
--host-record=test.test,${SUBNET}.1 &
dig -t a test.test @10.0.0.1 | grep EDNS
# should return "; EDNS ..."
dig -t test.test @10.0.0.1 | grep EDNS
# again, should return "; EDNS ..." but doesn't
---
To reproduce the systemd-resolved side of the problem
---
# as above, but
# now configure systemd-resolved to look at only 10.0.0.1, then
systemd-resolve --reset-server-features
# should exhibit five second delay then connect, assuming sshd is running :)
ssh test.test
---
+ [Discussion]
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: dnsmasq-base 2.79-1
ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
Uname: Linux 4.15.0-23-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
Date: Sat Aug 4 11:33:56 2018
InstallationDate: Installed on 2018-05-31 (64 days ago)
InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Release amd64
(20180426)
ProcEnviron:
- TERM=xterm
- PATH=(custom, no user)
- LANG=en_GB.UTF-8
- SHELL=/bin/bash
+ TERM=xterm
+ PATH=(custom, no user)
+ LANG=en_GB.UTF-8
+ SHELL=/bin/bash
SourcePackage: dnsmasq
UpgradeStatus: No upgrade log present (probably fresh install)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1785383
Title:
missing EDNS0 record confuses systemd-resolved
Status in systemd:
Unknown
Status in dnsmasq package in Ubuntu:
Triaged
Status in systemd package in Ubuntu:
Confirmed
Bug description:
[Impact]
dnsmasq 2.79 and below omits EDNS0 OPT records when returning an empty answer
for a domain it is authoritative for. systemd-resolved seems to get confused by
this in certain circumstances; when using the stub resolver and requesting an
address for which there are no records, there can sometimes be a five
second hang in resolution.
[Fix]
This is fixed by upstream commit
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78
Not sure if it is worth cherry picking? I imagine the most likely
trigger will be dnsmasq on routers which are not likely to be running
Ubuntu, but maybe just in case.
I also think there are some logic issues in systemd-resolved, upstream
bug filed:
https://github.com/systemd/systemd/issues/9785
[Test Case]
Simple-ish test case:
---
IFACE=dummy0
SUBNET=10.0.0
ip link add $IFACE type dummy
ifconfig $IFACE ${SUBNET}.1/24
dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo
--host-record=test.test,${SUBNET}.1 &
dig -t a test.test @10.0.0.1 | grep EDNS
# should return "; EDNS ..."
dig -t test.test @10.0.0.1 | grep EDNS
# again, should return "; EDNS ..." but doesn't
---
To reproduce the systemd-resolved side of the problem
---
# as above, but
# now configure systemd-resolved to look at only 10.0.0.1, then
systemd-resolve --reset-server-features
# should exhibit five second delay then connect, assuming sshd is running :)
ssh test.test
---
[Discussion]
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: dnsmasq-base 2.79-1
[Touch-packages] [Bug 1854023] Re: package openssh-client 1:7.2p2-4ubuntu2.8 failed to install/upgrade: package openssh-client is already installed and configured
Could you clarify the error you're encountering? The error message in the title of this bug suggests the package was already installed, so perhaps this is a non-bug? There are no error messages or indication of a fault being hit in any of the attached logs. ** Changed in: openssh (Ubuntu) Status: New => Incomplete -- 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/1854023 Title: package openssh-client 1:7.2p2-4ubuntu2.8 failed to install/upgrade: package openssh-client is already installed and configured Status in openssh package in Ubuntu: Incomplete Bug description: Report that problem ProblemType: Package DistroRelease: Ubuntu 16.04 Package: openssh-client 1:7.2p2-4ubuntu2.8 ProcVersionSignature: Ubuntu 4.15.0-45.48~16.04.1-generic 4.15.18 Uname: Linux 4.15.0-45-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.18 AptdaemonVersion: 1.1.1+bzr982-0ubuntu14 Architecture: amd64 CrashReports: 600:110:115:0:2019-11-26 16:03:39.894107818 +0530:2019-11-26 16:03:39.894107818 +0530:/var/crash/ncurses-term.0.uploaded 640:0:115:1269857:2019-11-26 16:02:43.810198545 +0530:2019-11-26 16:02:44.810198545 +0530:/var/crash/ncurses-term.0.crash 600:0:115:194068:2019-11-26 14:01:47.943607091 +0530:2019-11-26 14:01:48.943607091 +0530:/var/crash/openssh-client.0.crash 600:0:115:194078:2019-11-26 14:01:48.991607298 +0530:2019-11-26 14:01:48.967607161 +0530:/var/crash/openssh-sftp-server.0.crash 644:0:115:0:2019-11-26 16:03:05.783037835 +0530:2019-11-26 16:03:05.783037835 +0530:/var/crash/ncurses-term.0.upload Date: Tue Nov 26 14:01:48 2019 DuplicateSignature: package:openssh-client:1:7.2p2-4ubuntu2.8 Processing triggers for fontconfig (2.11.94-0ubuntu1.1) ... dpkg: error processing package openssh-client (--configure): package openssh-client is already installed and configured ErrorMessage: package openssh-client is already installed and configured InstallationDate: Installed on 2019-11-26 (0 days ago) InstallationMedia: Lubuntu 16.04.6 LTS "Xenial Xerus" - Release amd64 (20190227) RelatedPackageVersions: ssh-askpass N/A libpam-sshN/A keychain N/A ssh-askpass-gnome N/A SSHClientVersion: OpenSSH_7.2p2 Ubuntu-4ubuntu2.8, OpenSSL 1.0.2g 1 Mar 2016 SourcePackage: openssh Title: package openssh-client 1:7.2p2-4ubuntu2.8 failed to install/upgrade: package openssh-client is already installed and configured UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1854023/+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 1854038] Re: package openssh-sftp-server 1:7.2p2-4ubuntu2.8 failed to install/upgrade: package openssh-sftp-server is already installed and configured
*** This bug is a duplicate of bug 1854023 *** https://bugs.launchpad.net/bugs/1854023 ** This bug has been marked a duplicate of bug 1854023 package openssh-client 1:7.2p2-4ubuntu2.8 failed to install/upgrade: package openssh-client is already installed and configured -- 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/1854038 Title: package openssh-sftp-server 1:7.2p2-4ubuntu2.8 failed to install/upgrade: package openssh-sftp-server is already installed and configured Status in openssh package in Ubuntu: New Bug description: check and report ProblemType: Package DistroRelease: Ubuntu 16.04 Package: openssh-sftp-server 1:7.2p2-4ubuntu2.8 ProcVersionSignature: Ubuntu 4.15.0-45.48~16.04.1-generic 4.15.18 Uname: Linux 4.15.0-45-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.18 AptdaemonVersion: 1.1.1+bzr982-0ubuntu14 Architecture: amd64 Date: Tue Nov 26 14:01:48 2019 DuplicateSignature: package:openssh-sftp-server:1:7.2p2-4ubuntu2.8 Processing triggers for fontconfig (2.11.94-0ubuntu1.1) ... dpkg: error processing package openssh-client (--configure): package openssh-client is already installed and configured ErrorMessage: package openssh-sftp-server is already installed and configured InstallationDate: Installed on 2019-11-26 (0 days ago) InstallationMedia: Lubuntu 16.04.6 LTS "Xenial Xerus" - Release amd64 (20190227) RelatedPackageVersions: dpkg 1.18.4ubuntu1.5 apt 1.2.29ubuntu0.1 SourcePackage: openssh Title: package openssh-sftp-server 1:7.2p2-4ubuntu2.8 failed to install/upgrade: package openssh-sftp-server is already installed and configured UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1854038/+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 1851695] Re: DEP8 failure/regression in nspr on arm64 and armhf
Debian has a patch for the issue: https://salsa.debian.org/go- team/packages/notary/commit/b4f024c049b916c4b81fbd1199c86c8b5dfe2934 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to nspr in Ubuntu. https://bugs.launchpad.net/bugs/1851695 Title: DEP8 failure/regression in nspr on arm64 and armhf Status in notary package in Ubuntu: New Status in nspr package in Ubuntu: Invalid Status in notary package in Debian: Confirmed Bug description: nspr 0.6.1~ds1-4 is failing DEP8 test in arm64 and armhf: autopkgtest [09:46:25]: test command1: /usr/bin/dh_golang_autopkgtest autopkgtest [09:46:25]: test command1: [--- [info] Testing github.com/theupdateframework/notary... [info] Source code installed by binary package, overriding dh_auto_configure... [info] Disabling existing override_dh_auto_configure... dh build --builddirectory=/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build \ --buildsystem=golang \ --with=golang dh_update_autotools_config -O--builddirectory=/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build -O--buildsystem=golang dh_autoreconf -O--builddirectory=/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build -O--buildsystem=golang debian/rules override_dh_auto_configure make[1]: Entering directory '/tmp/autopkgtest.G91v24/autopkgtest_tmp' mkdir -p "_build" cp -a /usr/share/gocode/src "_build" make[1]: Leaving directory '/tmp/autopkgtest.G91v24/autopkgtest_tmp' debian/rules override_dh_auto_build make[1]: Entering directory '/tmp/autopkgtest.G91v24/autopkgtest_tmp' dh_auto_build -- -tags "pkcs11" cd _build && go install -gcflags=all=\"-trimpath=/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src\" -asmflags=all=\"-trimpath=/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src\" -v -p 1 -tags pkcs11 github.com/theupdateframework/notary github.com/theupdateframework/notary/client github.com/theupdateframework/notary/client/changelist github.com/theupdateframework/notary/cmd/escrow github.com/theupdateframework/notary/cmd/notary github.com/theupdateframework/notary/cmd/notary-server github.com/theupdateframework/notary/cmd/notary-signer github.com/theupdateframework/notary/cryptoservice github.com/theupdateframework/notary/passphrase github.com/theupdateframework/notary/proto github.com/theupdateframework/notary/server github.com/theupdateframework/notary/server/errors github.com/theupdateframework/notary/server/handlers github.com/theupdateframework/notary/server/snapshot github.com/theupdateframework/notary/server/storage github.com/theupdateframework/notary/server/timestamp github.com/theupdateframework/notary/signer github.com/theupdateframework/notary/signer/api github.com/theupdateframework/notary/signer/client github.com/theupdateframework/notary/signer/keydbstore github.com/theupdateframework/notary/storage github.com/theupdateframework/notary/storage/rethinkdb github.com/theupdateframework/notary/trustmanager github.com/theupdateframework/notary/trustmanager/remoteks github.com/theupdateframework/notary/trustmanager/yubikey github.com/theupdateframework/notary/trustpinning github.com/theupdateframework/notary/tuf github.com/theupdateframework/notary/tuf/data github.com/theupdateframework/notary/tuf/signed github.com/theupdateframework/notary/tuf/testutils github.com/theupdateframework/notary/tuf/testutils/interfaces github.com/theupdateframework/notary/tuf/testutils/keys github.com/theupdateframework/notary/tuf/utils github.com/theupdateframework/notary/tuf/validation github.com/theupdateframework/notary/utils github.com/theupdateframework/notary/version src/github.com/docker/distribution/digestset/set.go:9:2: cannot find package "github.com/opencontainers/go-digest" in any of: /tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src/github.com/docker/distribution/vendor/github.com/opencontainers/go-digest (vendor tree) /usr/lib/go-1.12/src/github.com/opencontainers/go-digest (from $GOROOT) /tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src/github.com/opencontainers/go-digest (from $GOPATH) src/github.com/docker/distribution/blobs.go:13:2: cannot find package "github.com/opencontainers/image-spec/specs-go/v1" in any of: /tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src/github.com/docker/distribution/vendor/github.com/opencontainers/image-spec/specs-go/v1 (vendor tree) /usr/lib/go-1.12/src/github.com/opencontainers/image-spec/specs-go/v1 (from $GOROOT) /tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src/github.com/opencontainers/image-spec/specs-go/v1 (from $GOPATH) dh_auto_build: cd _build && go install -gcflags=all=\"-trimpath=/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src\" -asmflags=all=\"-trimpath=/tmp/autopkgtest.G91v24/autopkgtest_tmp/_build/src\" -v -p 1 -tags pkcs11 github.com/theupdateframework/notary
[Touch-packages] [Bug 1851337] Re: package openssh-server 1:8.0p1-6build1 failed to install/upgrade: installed openssh-server package post-installation script subprocess returned error exit status 1
Hi csozo, It looks like your system was under some form of memory pressure prior to the openssh installation. So I don't think this is a fault necessarily in openssh itself but rather due to your computer having run out of memory and gotten into some sort of inconsistent state. I would recommend rebooting the machine (if you haven't already), and running `apt-get -f install`. It looks like there might have been some reconfiguration questions (possibly updates to some of your manual configuration work?) so I'd run it from a terminal window and keep an eye on it. Once you've done that, can you let us know if the issue is resolved or if you get a better insight as to what went wrong? ** Description changed: I don't know. ProblemType: Package DistroRelease: Ubuntu 19.10 Package: openssh-server 1:8.0p1-6build1 ProcVersionSignature: Ubuntu 5.3.0-19.20-generic 5.3.1 Uname: Linux 5.3.0-19-generic x86_64 ApportVersion: 2.20.11-0ubuntu8.1 Architecture: amd64 Date: Tue Nov 5 08:22:46 2019 ErrorMessage: installed openssh-server package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2019-01-15 (293 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3) Python3Details: /usr/bin/python3.7, Python 3.7.5rc1, python3-minimal, 3.7.5-1 PythonDetails: /usr/bin/python2.7, Python 2.7.17rc1, python-minimal, 2.7.17-1 RelatedPackageVersions: dpkg 1.19.7ubuntu2 apt 1.9.4 SSHDConfig: Error: command ['/usr/sbin/sshd', '-T'] failed with exit code 1: sshd: no hostkeys available -- exiting. SourcePackage: openssh Title: package openssh-server 1:8.0p1-6build1 failed to install/upgrade: installed openssh-server package post-installation script subprocess returned error exit status 1 UpgradeStatus: Upgraded to eoan on 2019-11-05 (0 days ago) - The dpkg log shows: + ... Setting up default-jre-headless (2:1.11-72) ... Setting up libpangoxft-1.0-0:amd64 (1.42.4-7) ... Setting up libqt4-network:amd64 (4:4.8.7+dfsg-7ubuntu3) ... Setting up openssh-server (1:8.0p1-6build1) ... Installing new version of config file /etc/ssh/moduli ... rescue-ssh.target is a disabled or a static unit, not starting it. Job for ssh.service failed because the control process exited with error code. See "systemctl status ssh.service" and "journalctl -xe" for details. invoke-rc.d: initscript ssh, action "restart" failed. ● ssh.service - OpenBSD Secure Shell server -Loaded: loaded (]8;;file://csozo-PC/lib/systemd/system/ssh.service/lib/systemd/system/ssh.service]8;;; enabled; vendor preset: enabled) -Active: activating (auto-restart) (Result: exit-code) since Tue 2019-11-05 08:22:46 CET; 6ms ago - Docs: ]8;;man:sshd(8)man:sshd(8)]8;; -]8;;man:sshd_config(5)man:sshd_config(5)]8;; - Process: 7160 ExecStartPre=/usr/sbin/sshd -t [0;1;31m(code=exited, status=1/FAILURE)[0m + Loaded: loaded (]8;;file://csozo-PC/lib/systemd/system/ssh.service/lib/systemd/system/ssh.service]8;;; enabled; vendor preset: enabled) + Active: activating (auto-restart) (Result: exit-code) since Tue 2019-11-05 08:22:46 CET; 6ms ago + Docs: ]8;;man:sshd(8)man:sshd(8)]8;; + ]8;;man:sshd_config(5)man:sshd_config(5)]8;; + Process: 7160 ExecStartPre=/usr/sbin/sshd -t [0;1;31m(code=exited, status=1/FAILURE)[0m dpkg: error processing package openssh-server (--configure): - installed openssh-server package post-installation script subprocess returned error exit status 1 + installed openssh-server package post-installation script subprocess returned error exit status 1 + + Apt ordering shows: + + ... + python-lockfile:amd64: Install + rygel:amd64: Install + xbrlapi:amd64: Install + NULL: ConfigurePending + + Dmesg indicates that an OOM killer event had occurred previously: + + [26198.228512] gsd-housekeepin invoked oom-killer: gfp_mask=0x6200ca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0 + [26198.228515] CPU: 0 PID: 4355 Comm: gsd-housekeepin Tainted: G OE 5.0.0-32-generic #34-Ubuntu + [26198.228515] Hardware name: System manufacturer System Product Name/H61M-K, BIOS 0801 07/21/2014 + [26198.228516] Call Trace: + [26198.228522] dump_stack+0x63/0x8a + [26198.228525] dump_header+0x54/0x2fb + [26198.228527] ? sched_clock+0x9/0x10 + [26198.228529] oom_kill_process.cold.30+0xb/0x1d6 + [26198.228530] out_of_memory+0x1c3/0x490 + [26198.228532] __alloc_pages_slowpath+0xb68/0xea0 + [26198.228534] __alloc_pages_nodemask+0x2c4/0x2e0 + [26198.228536] alloc_pages_current+0x81/0xe0 + [26198.228538] __page_cache_alloc+0x6a/0xa0 + [26198.228540] filemap_fault+0x3f0/0x8b0 + [26198.228541] ? filemap_map_pages+0x1ae/0x380 + [26198.228544] ext4_filemap_fault+0x31/0x44 + [26198.228546] __do_fault+0x3c/0x130 + [26198.228548] __handle_mm_fault+0xe4b/0x1280 + [26198.228550] ? __switch_to_asm+0x41/0x70 + [26198.228552]
[Touch-packages] [Bug 1851337] Re: package openssh-server 1:8.0p1-6build1 failed to install/upgrade: installed openssh-server package post-installation script subprocess returned error exit status 1
** Description changed: I don't know. ProblemType: Package DistroRelease: Ubuntu 19.10 Package: openssh-server 1:8.0p1-6build1 ProcVersionSignature: Ubuntu 5.3.0-19.20-generic 5.3.1 Uname: Linux 5.3.0-19-generic x86_64 ApportVersion: 2.20.11-0ubuntu8.1 Architecture: amd64 Date: Tue Nov 5 08:22:46 2019 ErrorMessage: installed openssh-server package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2019-01-15 (293 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3) Python3Details: /usr/bin/python3.7, Python 3.7.5rc1, python3-minimal, 3.7.5-1 PythonDetails: /usr/bin/python2.7, Python 2.7.17rc1, python-minimal, 2.7.17-1 RelatedPackageVersions: - dpkg 1.19.7ubuntu2 - apt 1.9.4 + dpkg 1.19.7ubuntu2 + apt 1.9.4 SSHDConfig: Error: command ['/usr/sbin/sshd', '-T'] failed with exit code 1: sshd: no hostkeys available -- exiting. SourcePackage: openssh Title: package openssh-server 1:8.0p1-6build1 failed to install/upgrade: installed openssh-server package post-installation script subprocess returned error exit status 1 UpgradeStatus: Upgraded to eoan on 2019-11-05 (0 days ago) + + + The dpkg log shows: + + Setting up default-jre-headless (2:1.11-72) ... + Setting up libpangoxft-1.0-0:amd64 (1.42.4-7) ... + Setting up libqt4-network:amd64 (4:4.8.7+dfsg-7ubuntu3) ... + Setting up openssh-server (1:8.0p1-6build1) ... + Installing new version of config file /etc/ssh/moduli ... + rescue-ssh.target is a disabled or a static unit, not starting it. + Job for ssh.service failed because the control process exited with error code. + See "systemctl status ssh.service" and "journalctl -xe" for details. + invoke-rc.d: initscript ssh, action "restart" failed. + ● ssh.service - OpenBSD Secure Shell server +Loaded: loaded (]8;;file://csozo-PC/lib/systemd/system/ssh.service/lib/systemd/system/ssh.service]8;;; enabled; vendor preset: enabled) +Active: activating (auto-restart) (Result: exit-code) since Tue 2019-11-05 08:22:46 CET; 6ms ago + Docs: ]8;;man:sshd(8)man:sshd(8)]8;; +]8;;man:sshd_config(5)man:sshd_config(5)]8;; + Process: 7160 ExecStartPre=/usr/sbin/sshd -t [0;1;31m(code=exited, status=1/FAILURE)[0m + dpkg: error processing package openssh-server (--configure): + installed openssh-server package post-installation script subprocess returned error exit status 1 -- 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/1851337 Title: package openssh-server 1:8.0p1-6build1 failed to install/upgrade: installed openssh-server package post-installation script subprocess returned error exit status 1 Status in openssh package in Ubuntu: Incomplete Bug description: I don't know. ProblemType: Package DistroRelease: Ubuntu 19.10 Package: openssh-server 1:8.0p1-6build1 ProcVersionSignature: Ubuntu 5.3.0-19.20-generic 5.3.1 Uname: Linux 5.3.0-19-generic x86_64 ApportVersion: 2.20.11-0ubuntu8.1 Architecture: amd64 Date: Tue Nov 5 08:22:46 2019 ErrorMessage: installed openssh-server package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2019-01-15 (293 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3) Python3Details: /usr/bin/python3.7, Python 3.7.5rc1, python3-minimal, 3.7.5-1 PythonDetails: /usr/bin/python2.7, Python 2.7.17rc1, python-minimal, 2.7.17-1 RelatedPackageVersions: dpkg 1.19.7ubuntu2 apt 1.9.4 SSHDConfig: Error: command ['/usr/sbin/sshd', '-T'] failed with exit code 1: sshd: no hostkeys available -- exiting. SourcePackage: openssh Title: package openssh-server 1:8.0p1-6build1 failed to install/upgrade: installed openssh-server package post-installation script subprocess returned error exit status 1 UpgradeStatus: Upgraded to eoan on 2019-11-05 (0 days ago) The dpkg log shows: ... Setting up default-jre-headless (2:1.11-72) ... Setting up libpangoxft-1.0-0:amd64 (1.42.4-7) ... Setting up libqt4-network:amd64 (4:4.8.7+dfsg-7ubuntu3) ... Setting up openssh-server (1:8.0p1-6build1) ... Installing new version of config file /etc/ssh/moduli ... rescue-ssh.target is a disabled or a static unit, not starting it. Job for ssh.service failed because the control process exited with error code. See "systemctl status ssh.service" and "journalctl -xe" for details. invoke-rc.d: initscript ssh, action "restart" failed. ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (]8;;file://csozo-PC/lib/systemd/system/ssh.service/lib/systemd/system/ssh.service]8;;; enabled; vendor preset: enabled) Active: activating (auto-restart) (Result: exit-code) since Tue 2019-11-05 08:22:46 CET; 6ms ago Docs: ]8;;man:sshd(8)man:sshd(8)]8;;
[Touch-packages] [Bug 1760818] Re: gedit and gnome-calculator transparency/graphics corruption issue when GTK_IM_MODULE=xim is set
I'm able to reproduce the faulty on bionic (not upgraded from xenial),
with GTK_IM_MODULE=xim and an empty .xinputrc.
Can also confirm the workaround suggested by Heiko L seems to fix this
issue, by changing /usr/share/themes/Ambiance/gtk-3.20/gtk.css to this:
> textview text {
>background-color: white;
> }
> scrollbar {
>background-color: white;
> }
> @import url("gtk-main.css");
This worked immediately after restarting gnome-calculator (installed
from deb, not snap) and gedit, no other system changes were required.
** Package changed: gtk+3.0 (Ubuntu) => ubuntu
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gtk+3.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1760818
Title:
gedit and gnome-calculator transparency/graphics corruption issue when
GTK_IM_MODULE=xim is set
Status in Ubuntu:
Confirmed
Status in im-config package in Ubuntu:
Confirmed
Bug description:
In a "Ubuntu" (Xorg) session on 18.04 gedit and gnome-calculator
suffer from a graphics issue where parts of their windows hold parts
of wallpaper or other windows' contents as background.
See attached screenshot.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: light-themes 16.10+18.04.20180328-0ubuntu1
ProcVersionSignature: Ubuntu 4.15.0-13.14-generic 4.15.10
Uname: Linux 4.15.0-13-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.9-0ubuntu2
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Tue Apr 3 09:12:31 2018
PackageArchitecture: all
SourcePackage: ubuntu-themes
UpgradeStatus: Upgraded to bionic on 2018-02-07 (54 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+bug/1760818/+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 1845652] Re: rsync sends everything, not just changes
Thanks for following up, I'm closing the issue as requested. ** Changed in: rsync (Ubuntu) Status: Incomplete => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsync in Ubuntu. https://bugs.launchpad.net/bugs/1845652 Title: rsync sends everything, not just changes Status in rsync package in Ubuntu: Invalid Bug description: Repeated runs of rsync from PC to USB key send everything, not just the changes. This is reproducible. ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: rsync 3.1.3-6 ProcVersionSignature: Ubuntu 5.0.0-29.31-generic 5.0.21 Uname: Linux 5.0.0-29-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.10-0ubuntu27.1 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Fri Sep 27 09:18:19 2019 InstallationDate: Installed on 2019-06-10 (109 days ago) InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Release amd64 (20190416) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: rsync UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1845652/+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 1846243] Re: package openssh-client 1:7.6p1-4ubuntu0.3 failed to install/upgrade: end of file on stdin at conffile prompt
Hi Nicholas, The reason for the error you got is because you had a local configuration setting for ssh in your /etc/ssh/ssh_config: -Host * -UseRoaming no The upgrader was asking whether to keep your changes or revert to the vanilla config. Since it timed out without an answer, it defaulted to keep your configuration changes, which seems sensible in this case. The other changes were just deltas in commented-out lines, so would not affect your installation at all. I think you can safely ignore the error. (It might be nice if the upgrader provided a less confusing UX for situations such as this, but that's outside the scope of ssh.) ** Changed in: openssh (Ubuntu) Status: New => Invalid -- 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/1846243 Title: package openssh-client 1:7.6p1-4ubuntu0.3 failed to install/upgrade: end of file on stdin at conffile prompt Status in openssh package in Ubuntu: Invalid Bug description: bug to install ProblemType: Package DistroRelease: Ubuntu 18.04 Package: openssh-client 1:7.6p1-4ubuntu0.3 ProcVersionSignature: Ubuntu 4.4.0-1095.106-aws 4.4.189 Uname: Linux 4.4.0-1095-aws x86_64 ApportVersion: 2.20.9-0ubuntu7.7 Architecture: amd64 Date: Tue Oct 1 17:20:44 2019 Ec2AMI: ami-0e3d43d99dd9cda2c Ec2AMIManifest: (unknown) Ec2AvailabilityZone: ca-central-1a Ec2InstanceType: t2.nano Ec2Kernel: unavailable Ec2Ramdisk: unavailable ErrorMessage: end of file on stdin at conffile prompt Python3Details: /usr/bin/python3.6, Python 3.6.8, python3-minimal, 3.6.7-1~18.04 PythonDetails: /usr/bin/python2.7, Python 2.7.15+, python-minimal, 2.7.15~rc1-1 RelatedPackageVersions: ssh-askpass N/A libpam-sshN/A keychain N/A ssh-askpass-gnome N/A SSHClientVersion: OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017 SourcePackage: openssh Title: package openssh-client 1:7.6p1-4ubuntu0.3 failed to install/upgrade: end of file on stdin at conffile prompt UpgradeStatus: Upgraded to bionic on 2019-10-01 (0 days ago) modified.conffile..etc.ssh.ssh_config: [modified] mtime.conffile..etc.ssh.ssh_config: 2019-04-30T10:51:02.029086 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1846243/+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 1843201] Re: Unity in Wayland prompts for keyboard focus on each run of ssh-askpass-gnome
I can't say for certain if the issue resides with ssh-askpass-fullscreen or is a UI usability issue in unity, gnome, or elsewhere, however this UI is not driven by OpenSSH itself, so I'll retarget this bugtask to ssh-askpass-fullscreen as a slightly more likely candidate. ** Package changed: openssh (Ubuntu) => ssh-askpass-fullscreen (Ubuntu) -- 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/1843201 Title: Unity in Wayland prompts for keyboard focus on each run of ssh- askpass-gnome Status in gnome-desktop package in Ubuntu: New Status in ssh-askpass-fullscreen package in Ubuntu: Incomplete Status in unity package in Ubuntu: New Bug description: When using a Wayland-based Unity session on Ubuntu 19.04: 1. Have ssh-askpass-gnome as your askpass program. 2. ssh-add -c 3. `ssh` to a host Each time, before the ssh-askpass prompt is shown, Unity shows this dialog: +-+ | | | ssh-askpass wants to inhibit shortcuts | | | | You can restore Shortcuts by pressing | | Super+Escape. | | | |_| | Deny | Allow | +-+ This is mildly distracting, and it means that you need to hit , answer, , instead of just answer . ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: ssh-askpass-gnome 1:7.9p1-10 ProcVersionSignature: Ubuntu 5.0.0-27.28-generic 5.0.21 Uname: Linux 5.0.0-27-generic x86_64 ApportVersion: 2.20.10-0ubuntu27.1 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Sun Sep 8 15:04:25 2019 DistributionChannelDescriptor: # This is the distribution channel descriptor for the OEM CDs # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor canonical-oem-somerville-bionic-amd64-20180608-47+tunnels-mlk+X55+tunnels-mlk+X55.1 InstallationDate: Installed on 2019-08-27 (12 days ago) InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 20180608-09:38 SourcePackage: openssh UpgradeStatus: Upgraded to disco on 2019-08-31 (8 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-desktop/+bug/1843201/+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 1841640] Re: package rsync 3.1.1-3ubuntu1 failed to install/upgrade: pacote rsync não está pronto para configuração não posso configurar (estado atual 'half-installed')
Hi Leonardo,
It sounds like your upgrade may have been interrupted for some reason,
and rsync didn't finish getting configured. Forcibly removing and
reinstalling rsync might help. There is some advice about fixing half-
installed packages here:
https://askubuntu.com/questions/490671/fix-half-installed-package
If this doesn't work, or if you determine the reason why it got into
this state, please let us know.
** Changed in: rsync (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsync in Ubuntu.
https://bugs.launchpad.net/bugs/1841640
Title:
package rsync 3.1.1-3ubuntu1 failed to install/upgrade: pacote rsync
não está pronto para configuração não posso configurar (estado atual
'half-installed')
Status in rsync package in Ubuntu:
Incomplete
Bug description:
No se bien lo que acontecio. ("I don't know well what happened")
ProblemType: Package
DistroRelease: Ubuntu 16.04
Package: rsync 3.1.1-3ubuntu1
ProcVersionSignature: Ubuntu 4.4.0-128.154-generic 4.4.131
Uname: Linux 4.4.0-128-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.18
AptOrdering:
oem-workaround-force-install-intel-red: Remove
oem-workaround-force-install-qualcomm-red: Remove
rsync: Configure
NULL: ConfigurePending
Architecture: amd64
Date: Mon Aug 26 06:37:59 2019
DistributionChannelDescriptor:
# This is a distribution channel descriptor
# For more information see
http://wiki.ubuntu.com/DistributionChannelDescriptor
canonical-oem-somerville-xenial-amd64-20160624-2
DpkgTerminalLog:
A remover oem-workaround-force-install-intel-red (1.4) ...
A remover oem-workaround-force-install-qualcomm-red (3.2) ...
dpkg: erro ao processar o pacote rsync (--configure):
pacote rsync não está pronto para configuração
não posso configurar (estado atual 'half-installed')
(dpkg: Error processing rsync package (--configure):
rsync package not ready for configuration
i can't configure)
ErrorMessage: pacote rsync não está pronto para configuração não posso
configurar (estado atual 'half-installed')
(ErrorMessage: rsync package not ready for configuration can't configure)
InstallationDate: Installed on 2019-08-01 (25 days ago)
InstallationMedia: Ubuntu 16.04 "Xenial" - Build amd64 LIVE Binary
20160624-10:47
RelatedPackageVersions:
dpkg 1.18.4ubuntu1
apt 1.2.29ubuntu0.1
SourcePackage: rsync
Title: package rsync 3.1.1-3ubuntu1 failed to install/upgrade: pacote rsync
não está pronto para configuração não posso configurar (estado atual
'half-installed')
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1841640/+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 1841654] Re: Replace mawk with gawk in main
** Tags added: server-next
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to mawk in Ubuntu.
https://bugs.launchpad.net/bugs/1841654
Title:
Replace mawk with gawk in main
Status in mawk package in Ubuntu:
New
Bug description:
For POSIX compatibility reasons Ubuntu ships with mawk ("Mike's awk" =
mawk) in main. There is an awk-symlink to mawk, thus mawk is the
official awk implementation in Ubuntu.
== Reasons against keeping mawk ==
*The mawk package is synced from debian and it is heavily
undermaintained: Debian (and thus Ubuntu) still ships version
1.3.3-17, the same version at least since oldoldstable:
https://packages.debian.org/search?searchon=names=mawk
*part-time maintainer Thomas E. Dickey (https://invisible-
island.net/mawk/) called officially out that Debian "neglected" mawk
in 2014 ("As noted, mawk has been neglected by some packagers (see for
example this http://bugs.debian.org/cgi-
bin/pkgreport.cgi?package=mawk)". And Debian (and Ubuntu) still ship
the same version five years later
*Most other distributions ship mawk at least in its last official
incarnation 1.3.4 in their repositories. Dickey lists AIX, Fedora,
FinkPorts (Mac OS X), FreeBSD port, Gentoo, HPUX, MacPorts (Mac OS X),
NetBSD pkgsrc/lang, OpenCSW (Solaris). But even that version is from
2014 and doesn't seem to be developed anymore:
https://github.com/ThomasDickey/mawk-20140914/commits/master
*A planned rewrite mawk2 was planned by original author Mike Brennan
in 2016 but obviously came to nothing:
https://github.com/ploxiln/mawk-2/commits/master
*Thus mawk sits in Ubuntu main in a version published upstream in 2009
and celebrates its 10th anniversary of negligence. In a state that
Debian was called out for 5 years ago.
*This year it is 10 years unmaintained and largely untouched. At the
end of the next LTS-support-cycle we can celebrate 15 years of not
supporting it.
*awk is included in Linux for POSIX standard compliance. Mawk is known
to be fast and small but it is the implementation that is farthest
from being POSIX compliant, missing things like named character
classes like [[:space:]] within its EREs.
== Reasons for gawk as a replacement ==
*It is the official GNU awk implementation and known to work well with
the rest of the GNU userland.
*It is actively maintained with the last version 5.01 shipping in
June, 2019 (even if Ubuntu will obviously still ship 4.2 for Eoan).
*It is mostly compliant with the POSIX standard.
*Most other distributions ship it as the standard POSIX
implementation, with a awk symlink. So it had security reviews already
by Red Hat and others.
== Possible problems with switching to gawk in time for Ubuntu 20.4 ==
- It might need to be MIRed by the Ubuntu security team and a review
might take some time. So I filed this bug early with Eoan not yet out
of the door.
- It is much larger than mawk, the Ubuntu package is 1600 kB in size,
while mawk is only about 190KB. Thus some might want to split out some
basic functionality to save size. Like what is vim-tiny to vim. To
start gawk in --traditional or --posix mode and disable the extensions
at compile time might be a good start to reduce the size. See:
https://www.gnu.org/software/gawk/manual/html_node/Additional-
Configuration-Options.html#Additional-Configuration-Options
=
ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: mawk 1.3.3-17ubuntu3
ProcVersionSignature: Ubuntu 5.0.0-27.28-generic 5.0.21
Uname: Linux 5.0.0-27-generic x86_64
ApportVersion: 2.20.10-0ubuntu27.1
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Tue Aug 27 20:12:11 2019
Dependencies:
gcc-9-base 9.1.0-2ubuntu2~19.04
libc6 2.29-0ubuntu2
libgcc1 1:9.1.0-2ubuntu2~19.04
libidn2-0 2.0.5-1
libunistring2 0.9.10-1ubuntu2
InstallationDate: Installed on 2018-02-23 (550 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180214)
ProcEnviron:
LANGUAGE=de_AT:de
PATH=(custom, no user)
XDG_RUNTIME_DIR=
LANG=de_AT.UTF-8
SHELL=/bin/bash
SourcePackage: mawk
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mawk/+bug/1841654/+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 1841640] Re: package rsync 3.1.1-3ubuntu1 failed to install/upgrade: pacote rsync não está pronto para configuração não posso configurar (estado atual 'half-installed')
** Description changed:
- No se bien lo que acontecio.
+ No se bien lo que acontecio. ("I don't know well what happened")
ProblemType: Package
DistroRelease: Ubuntu 16.04
Package: rsync 3.1.1-3ubuntu1
ProcVersionSignature: Ubuntu 4.4.0-128.154-generic 4.4.131
Uname: Linux 4.4.0-128-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.18
AptOrdering:
- oem-workaround-force-install-intel-red: Remove
- oem-workaround-force-install-qualcomm-red: Remove
- rsync: Configure
- NULL: ConfigurePending
+ oem-workaround-force-install-intel-red: Remove
+ oem-workaround-force-install-qualcomm-red: Remove
+ rsync: Configure
+ NULL: ConfigurePending
Architecture: amd64
Date: Mon Aug 26 06:37:59 2019
DistributionChannelDescriptor:
- # This is a distribution channel descriptor
- # For more information see
http://wiki.ubuntu.com/DistributionChannelDescriptor
- canonical-oem-somerville-xenial-amd64-20160624-2
+ # This is a distribution channel descriptor
+ # For more information see
http://wiki.ubuntu.com/DistributionChannelDescriptor
+ canonical-oem-somerville-xenial-amd64-20160624-2
DpkgTerminalLog:
- A remover oem-workaround-force-install-intel-red (1.4) ...
- A remover oem-workaround-force-install-qualcomm-red (3.2) ...
- dpkg: erro ao processar o pacote rsync (--configure):
- pacote rsync não está pronto para configuração
- não posso configurar (estado atual 'half-installed')
+ A remover oem-workaround-force-install-intel-red (1.4) ...
+ A remover oem-workaround-force-install-qualcomm-red (3.2) ...
+ dpkg: erro ao processar o pacote rsync (--configure):
+ pacote rsync não está pronto para configuração
+ não posso configurar (estado atual 'half-installed')
ErrorMessage: pacote rsync não está pronto para configuração não posso
configurar (estado atual 'half-installed')
InstallationDate: Installed on 2019-08-01 (25 days ago)
InstallationMedia: Ubuntu 16.04 "Xenial" - Build amd64 LIVE Binary
20160624-10:47
RelatedPackageVersions:
- dpkg 1.18.4ubuntu1
- apt 1.2.29ubuntu0.1
+ dpkg 1.18.4ubuntu1
+ apt 1.2.29ubuntu0.1
SourcePackage: rsync
Title: package rsync 3.1.1-3ubuntu1 failed to install/upgrade: pacote rsync
não está pronto para configuração não posso configurar (estado atual
'half-installed')
UpgradeStatus: No upgrade log present (probably fresh install)
** Description changed:
No se bien lo que acontecio. ("I don't know well what happened")
ProblemType: Package
DistroRelease: Ubuntu 16.04
Package: rsync 3.1.1-3ubuntu1
ProcVersionSignature: Ubuntu 4.4.0-128.154-generic 4.4.131
Uname: Linux 4.4.0-128-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.18
AptOrdering:
oem-workaround-force-install-intel-red: Remove
oem-workaround-force-install-qualcomm-red: Remove
rsync: Configure
NULL: ConfigurePending
Architecture: amd64
Date: Mon Aug 26 06:37:59 2019
DistributionChannelDescriptor:
# This is a distribution channel descriptor
# For more information see
http://wiki.ubuntu.com/DistributionChannelDescriptor
canonical-oem-somerville-xenial-amd64-20160624-2
DpkgTerminalLog:
A remover oem-workaround-force-install-intel-red (1.4) ...
A remover oem-workaround-force-install-qualcomm-red (3.2) ...
dpkg: erro ao processar o pacote rsync (--configure):
pacote rsync não está pronto para configuração
não posso configurar (estado atual 'half-installed')
+ (dpkg: Error processing rsync package (--configure):
+ rsync package not ready for configuration
+ i can't configure)
ErrorMessage: pacote rsync não está pronto para configuração não posso
configurar (estado atual 'half-installed')
InstallationDate: Installed on 2019-08-01 (25 days ago)
InstallationMedia: Ubuntu 16.04 "Xenial" - Build amd64 LIVE Binary
20160624-10:47
RelatedPackageVersions:
dpkg 1.18.4ubuntu1
apt 1.2.29ubuntu0.1
SourcePackage: rsync
Title: package rsync 3.1.1-3ubuntu1 failed to install/upgrade: pacote rsync
não está pronto para configuração não posso configurar (estado atual
'half-installed')
UpgradeStatus: No upgrade log present (probably fresh install)
** Description changed:
No se bien lo que acontecio. ("I don't know well what happened")
ProblemType: Package
DistroRelease: Ubuntu 16.04
Package: rsync 3.1.1-3ubuntu1
ProcVersionSignature: Ubuntu 4.4.0-128.154-generic 4.4.131
Uname: Linux 4.4.0-128-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.18
AptOrdering:
oem-workaround-force-install-intel-red: Remove
oem-workaround-force-install-qualcomm-red: Remove
rsync: Configure
NULL: ConfigurePending
Architecture: amd64
Date: Mon Aug 26 06:37:59 2019
DistributionChannelDescriptor:
# This is a distribution channel descriptor
# For more information see
http://wiki.ubuntu.com/DistributionChannelDescriptor
canonical-oem-somerville-xenial-amd64-20160624-2
DpkgTerminalLog:
A remover oem-workaround-force-install-intel-red (1.4) ...
A remover
[Touch-packages] [Bug 1815101] Re: [master] Restarting systemd-networkd breaks keepalived clusters
The aforementioned link shows there's been work towards a fix in
systemd. Can't say if that suggests what can be done to improve
keepalived, but I've tagged this "server-next" to get it on the Ubuntu
SErver Team's high priority list, as per Robie's earlier comment.
** Tags added: server-next
--
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/1815101
Title:
[master] Restarting systemd-networkd breaks keepalived clusters
Status in netplan:
Invalid
Status in keepalived package in Ubuntu:
Triaged
Status in systemd package in Ubuntu:
Triaged
Bug description:
Configure netplan for interfaces, for example (a working config with
IP addresses obfuscated)
network:
ethernets:
eth0:
addresses: [192.168.0.5/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth2:
addresses:
- 12.13.14.18/29
- 12.13.14.19/29
gateway4: 12.13.14.17
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth3:
addresses: [10.22.11.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth4:
addresses: [10.22.14.6/24]
dhcp4: false
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
eth7:
addresses: [9.5.17.34/29]
dhcp4: false
optional: true
nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com,
phone.blah.com]
addresses: [10.22.11.1]
version: 2
Configure keepalived (again, a working config with IP addresses
obfuscated)
global_defs # Block id
{
notification_email {
sysadm...@blah.com
}
notification_email_from keepali...@system3.hq.blah.com
smtp_server 10.22.11.7 # IP
smtp_connect_timeout 30 # integer, seconds
router_id system3 # string identifying the machine,
# (doesn't have to be hostname).
vrrp_mcast_group4 224.0.0.18 # optional, default 224.0.0.18
vrrp_mcast_group6 ff02::12 # optional, default ff02::12
enable_traps # enable SNMP traps
}
vrrp_sync_group collection {
group {
wan
lan
phone
}
vrrp_instance wan {
state MASTER
interface eth2
virtual_router_id 77
priority 150
advert_int 1
smtp_alert
authentication {
auth_type PASS
auth_pass BlahBlah
}
virtual_ipaddress {
12.13.14.20
}
}
vrrp_instance lan {
state MASTER
interface eth3
virtual_router_id 78
priority 150
advert_int 1
smtp_alert
authentication {
auth_type PASS
auth_pass MoreBlah
}
virtual_ipaddress {
10.22.11.13/24
}
}
vrrp_instance phone {
state MASTER
interface eth4
virtual_router_id 79
priority 150
advert_int 1
smtp_alert
authentication {
auth_type PASS
auth_pass MostBlah
}
virtual_ipaddress {
10.22.14.3/24
}
}
At boot the affected interfaces have:
5: eth4: mtu 1500 qdisc mq state UP group
default qlen 1000
link/ether ab:cd:ef:90:c0:e3 brd ff:ff:ff:ff:ff:ff
inet 10.22.14.6/24 brd 10.22.14.255 scope global eth4
valid_lft forever preferred_lft forever
inet 10.22.14.3/24 scope global secondary eth4
valid_lft forever preferred_lft forever
inet6 fe80::ae1f:6bff:fe90:c0e3/64 scope link
valid_lft forever preferred_lft forever
7: eth3: mtu 1500 qdisc mq state UP group
default qlen 1000
link/ether ab:cd:ef:b0:26:29 brd ff:ff:ff:ff:ff:ff
inet 10.22.11.6/24 brd 10.22.11.255 scope global eth3
valid_lft forever preferred_lft forever
inet 10.22.11.13/24 scope global secondary eth3
valid_lft forever preferred_lft forever
inet6 fe80::ae1f:6bff:feb0:2629/64 scope link
valid_lft forever preferred_lft forever
9: eth2: mtu 1500 qdisc
[Touch-packages] [Bug 1838370] Re: slapd segfault on filter parse error
** Description changed:
Impact
--
- Users willing to use the slapd rwm overlay will face a slapd segmentation
fault
- when trying to rewrite some rules. Backporting this fix will allow users using
- stable releases to take advantage of this feature without crashing slapd. This
- issue was fixed by upstream not freeing the rwm overlay filter memory without
- prior checking.
+ Users willing to use the slapd rwm overlay will face a slapd
+ segmentation fault when trying to rewrite some rules. Backporting this
+ fix will allow users using stable releases to take advantage of this
+ feature without crashing slapd. This issue was fixed by upstream not
+ freeing the rwm overlay filter memory without prior checking.
Test Case
-
- In this test case, the rwm overlay will be used and a rule will be created to
- deny any search request for uid=root, then the 'ldapsearch' will be invoked to
- trigger the failure. It is important to mention that the 'ldapsearch' command
- should fail regardless the presence of the bug in the package, the target here
- is the slapd crash. To reproduce this bug one can follow the procedure below
in
- Ubuntu xenial, bionic or disco:
+ In this test case, the rwm overlay will be used and a rule will be
+ created to deny any search request for uid=root, then the 'ldapsearch'
+ will be invoked to trigger the failure. It is important to mention that
+ the 'ldapsearch' command should fail regardless the presence of the bug
+ in the package, the target here is the slapd crash. To reproduce this
+ bug one can follow the procedure below in Ubuntu xenial, bionic or
+ disco:
$ sudo apt-get update
$ sudo apt-get install slapd ldap-utils -y
Reconfigure the slapd package. When asked about a domain, use "example.com".
Choose a password you want (or just leave it blank), and accept defaults for
everything else:
$ sudo dpkg-reconfigure slapd
Create a file called 'add-rwm.ldif' with the following content:
$ cat add-rwm.ldif
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: rwm
dn: olcOverlay=rwm,olcDatabase={1}mdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcRwmConfig
olcOverlay: rwm
olcRwmRewrite: {0} rwm-rewriteEngine "on"
olcRwmRewrite: {1} rwm-rewriteContext "searchFilter"
olcRwmRewrite: {2} rwm-rewriteRule "(.*)(uid=root)(.*)" "$1$2$3" "#"
-
With this file in place, run:
$ sudo ldapadd -Q -Y EXTERNAL -H ldapi:/// -f add-rwm.ldif
Now, to trigger the crash:
$ ldapsearch -x -h localhost -b dc=example,dc=com -LLL uid=root
Server is unwilling to perform (53)
Additional information: searchFilter/searchFilterAttrDN massage error
-
slapd process will die, and /var/crash will have a crash file for slapd. You
can run the following command to confirm the error:
$ cat /var/log/syslog | grep filter_free
Aug 9 19:51:05 popular-gorilla slapd[1479]: filter_free: unknown filter
type=28530
-
Regression Potential
- Since the fix is a patch provided by upstream (reviewed by maintainers and us)
- simple mistakes like typos are not expected. The patch impacts only the rwm
- module which is not loaded by default. So any regression would affect only the
- users that make use of this overlay. If an user is not using rwm overlay and
is
- facing any issue, it should be related to other problems related to LDAP
- directory services.
-
-
+ Since the fix is a patch provided by upstream (reviewed by maintainers
+ and us) simple mistakes like typos are not expected. The patch impacts
+ only the rwm module which is not loaded by default. So any regression
+ would affect only the users that make use of this overlay. If an user is
+ not using rwm overlay and is facing any issue, it should be related to
+ other problems related to LDAP directory services.
[Original message]
Hello!
We have faced slapd crash, seems an attacker was trying to brute force one
of our services and uid parsing failures caused slapd crash:
Jul 26 18:59:47 slapd[1252]: conn=1466 op=13 SRCH
base="ou=test,dc=test,dc=com" scope=2 deref=0
filter="(&(uid=aistar123<>!n)(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0"
Jul 26 18:59:47 slapd[1252]: conn=1466 op=13 SRCH attr=objectClass uid
userPassword uidNumber gidNumber gecos homeDirectory loginShell
krbPrincipalName cn memberOf modifyTimestamp modifyTimestamp
shadowLastChange shadowMin shadow
Max shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange
krbPasswordExpiration pwdAttribute authorizedService accountExpires
userAccountControl nsAccountLock host loginDisabled loginExpirationTime
loginAllowedTimeMap sshPublic
Key
Jul 26 18:59:47 slapd[1252]: conn=1466 op=13 SEARCH RESULT tag=101 err=0
nentries=0 text=massaged filter parse error
Jul 26 18:59:47 kernel: [ 9441.554161] slapd[2367]: segfault at 18 ip
[Touch-packages] [Bug 1838370] Re: slapd segfault on filter parse error
** Tags added: server-next -- 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/1838370 Title: slapd segfault on filter parse error Status in openldap: Fix Released Status in openldap package in Ubuntu: Confirmed Status in openldap source package in Xenial: New Status in openldap source package in Bionic: New Status in openldap source package in Disco: New Bug description: Hello! We have faced slapd crash, seems an attacker was trying to brute force one of our services and uid parsing failures caused slapd crash: Jul 26 18:59:47 slapd[1252]: conn=1466 op=13 SRCH base="ou=test,dc=test,dc=com" scope=2 deref=0 filter="(&(uid=aistar123<>!n)(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0" Jul 26 18:59:47 slapd[1252]: conn=1466 op=13 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn memberOf modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadow Max shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService accountExpires userAccountControl nsAccountLock host loginDisabled loginExpirationTime loginAllowedTimeMap sshPublic Key Jul 26 18:59:47 slapd[1252]: conn=1466 op=13 SEARCH RESULT tag=101 err=0 nentries=0 text=massaged filter parse error Jul 26 18:59:47 kernel: [ 9441.554161] slapd[2367]: segfault at 18 ip 7fc8d18ec512 sp 7fc8889e2810 error 4 in libc-2.23.so [7fc8d1868000+1c] Another faulty filter example: filter="(&(uid=sql<>?)(objectClass=posixAccount)(&(uidNumber=*)(!(uidNumber=0" filter="(&(uid=fugeone<>?123)(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0" $ lsb_release -rd Description: Ubuntu 16.04.5 LTS Release: 16.04 $ slapd -VVV @(#) $OpenLDAP: slapd (Ubuntu) (May 22 2018 13:54:12) $ buildd@lcy01-amd64-019 :/build/openldap-t_Ta0O/openldap-2.4.42+dfsg/debian/build/servers/slapd Included static backends: config ldif $ apt-cache policy slapd slapd: Installed: 2.4.42+dfsg-2ubuntu3.3 Candidate: 2.4.42+dfsg-2ubuntu3.5 Version table: 2.4.42+dfsg-2ubuntu3.5 500 500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages *** 2.4.42+dfsg-2ubuntu3.3 100 100 /var/lib/dpkg/status 2.4.42+dfsg-2ubuntu3.2 500 500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages 2.4.42+dfsg-2ubuntu3 500 500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages affects ubuntu/openldap To manage notifications about this bug go to: https://bugs.launchpad.net/openldap/+bug/1838370/+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 1838370] Re: slapd segfault on filter parse error
** Patch added: "Patch mentioned in previous comment" https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1838370/+attachment/5280211/+files/0001-ITS-8964-Do-not-free-original-filter.patch -- 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/1838370 Title: slapd segfault on filter parse error Status in openldap: Fix Released Status in openldap package in Ubuntu: Confirmed Status in openldap source package in Xenial: New Status in openldap source package in Bionic: New Status in openldap source package in Disco: New Bug description: Hello! We have faced slapd crash, seems an attacker was trying to brute force one of our services and uid parsing failures caused slapd crash: Jul 26 18:59:47 slapd[1252]: conn=1466 op=13 SRCH base="ou=test,dc=test,dc=com" scope=2 deref=0 filter="(&(uid=aistar123<>!n)(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0" Jul 26 18:59:47 slapd[1252]: conn=1466 op=13 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn memberOf modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadow Max shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService accountExpires userAccountControl nsAccountLock host loginDisabled loginExpirationTime loginAllowedTimeMap sshPublic Key Jul 26 18:59:47 slapd[1252]: conn=1466 op=13 SEARCH RESULT tag=101 err=0 nentries=0 text=massaged filter parse error Jul 26 18:59:47 kernel: [ 9441.554161] slapd[2367]: segfault at 18 ip 7fc8d18ec512 sp 7fc8889e2810 error 4 in libc-2.23.so [7fc8d1868000+1c] Another faulty filter example: filter="(&(uid=sql<>?)(objectClass=posixAccount)(&(uidNumber=*)(!(uidNumber=0" filter="(&(uid=fugeone<>?123)(objectClass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0" $ lsb_release -rd Description: Ubuntu 16.04.5 LTS Release: 16.04 $ slapd -VVV @(#) $OpenLDAP: slapd (Ubuntu) (May 22 2018 13:54:12) $ buildd@lcy01-amd64-019 :/build/openldap-t_Ta0O/openldap-2.4.42+dfsg/debian/build/servers/slapd Included static backends: config ldif $ apt-cache policy slapd slapd: Installed: 2.4.42+dfsg-2ubuntu3.3 Candidate: 2.4.42+dfsg-2ubuntu3.5 Version table: 2.4.42+dfsg-2ubuntu3.5 500 500 http://nl.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages *** 2.4.42+dfsg-2ubuntu3.3 100 100 /var/lib/dpkg/status 2.4.42+dfsg-2ubuntu3.2 500 500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages 2.4.42+dfsg-2ubuntu3 500 500 http://nl.archive.ubuntu.com/ubuntu xenial/main amd64 Packages affects ubuntu/openldap To manage notifications about this bug go to: https://bugs.launchpad.net/openldap/+bug/1838370/+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 1838436] Re: popt download location broken
Debian sees the problem too, at least since mid-June: http://duck.debian.net/static/sp/p/popt.html https://tracker.debian.org/pkg/popt The domain name is still registered, through next year: https://whois.gandi.net/en/results?search=rpm5.org >From debian/changelog, looks like the last major release, 1.16, was back in 2010. The project's devel mailing list had discussion activity within the last couple years, but not very much, and nothing to explain what's going on.: https://www.mail-archive.com/popt-devel@rpm5.org/maillist.html It looks like the problem isn't merely a stale link, but that the activity level of the upstream project has dropped - unfortunately not something really addressable at the distro level. Depending on what you need from the upstream website, you might try reaching out to individuals from that mailing list discussion. Are you spotting any secondary issues being caused by the offline rpm5.org website, within Ubuntu or the Ubuntu project infrastructure? If there isn't, then I think since Ubuntu has been simply syncing this package from Debian, I think we just follow their lead on what to do packaging-wise. ** Changed in: popt (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to popt in Ubuntu. https://bugs.launchpad.net/bugs/1838436 Title: popt download location broken Status in popt package in Ubuntu: Incomplete Bug description: rpm5.org disappeared, with download area, home page and CVS repo. See also https://bugs.archlinux.org/task/62888?project=1=popt To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/popt/+bug/1838436/+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 1531184] Re: [SRU] dnsmasq doesn't start on boot because its interface isn't up yet
** Description changed: [Impact] - TBD + dnsmasq will fail to respond on network devices that weren't up when its + service started, thus not binding as expected. [Test Case] TBD [Regression Potential] The fix is just configuring the order of service startup, so is unlikely to create any regressions. Things to watch would be service related misbehaviors and general availability of the dnsmasq functionality. [Fix] - https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=774970;filename=774970-network-online.debdiff;msg=22 + Straightforward packaging fix to the service to make it delay startup + until after the network is online. + + https://bugs.debian.org/cgi- + bin/bugreport.cgi?att=1;bug=774970;filename=774970-network- + online.debdiff;msg=22 [Discussion] [Original Report] My dnsmasq instance uses "interface=br-vz0" and the interface br-vz0 is managed manually in /etc/network/interfaces. During boot, dnsmasq is started before br-vz0 is created and this causes dnsmasq to exit: Jan 5 08:56:16 simon-laptop dnsmasq[1008]: dnsmasq: unknown interface br-vz0 Jan 5 08:56:16 simon-laptop dnsmasq[1008]: unknown interface br-vz0 Jan 5 08:56:16 simon-laptop dnsmasq[1008]: FAILED to start up Jan 5 08:56:17 simon-laptop NetworkManager[937]: NetworkManager (version 1.0.4) is starting... ... Jan 5 08:56:18 simon-laptop NetworkManager[937]: interface-parser: parsing file /etc/network/interfaces ... Jan 5 08:56:18 simon-laptop NetworkManager[937]: found bridge ports none for br-vz0 Jan 5 08:56:18 simon-laptop NetworkManager[937]: adding bridge port none to eni_ifaces Jan 5 08:56:18 simon-laptop NetworkManager[937]: management mode: unmanaged ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: dnsmasq 2.75-1 ProcVersionSignature: Ubuntu 4.3.0-5.16-generic 4.3.3 Uname: Linux 4.3.0-5-generic x86_64 ApportVersion: 2.19.3-0ubuntu2 Architecture: amd64 CurrentDesktop: Unity Date: Tue Jan 5 09:53:30 2016 PackageArchitecture: all SourcePackage: dnsmasq UpgradeStatus: No upgrade log present (probably fresh install) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1531184 Title: [SRU] dnsmasq doesn't start on boot because its interface isn't up yet Status in One Hundred Papercuts: Confirmed Status in dnsmasq package in Ubuntu: Confirmed Status in dnsmasq package in Debian: New Bug description: [Impact] dnsmasq will fail to respond on network devices that weren't up when its service started, thus not binding as expected. [Test Case] TBD [Regression Potential] The fix is just configuring the order of service startup, so is unlikely to create any regressions. Things to watch would be service related misbehaviors and general availability of the dnsmasq functionality. [Fix] Straightforward packaging fix to the service to make it delay startup until after the network is online. https://bugs.debian.org/cgi- bin/bugreport.cgi?att=1;bug=774970;filename=774970-network- online.debdiff;msg=22 [Discussion] [Original Report] My dnsmasq instance uses "interface=br-vz0" and the interface br-vz0 is managed manually in /etc/network/interfaces. During boot, dnsmasq is started before br-vz0 is created and this causes dnsmasq to exit: Jan 5 08:56:16 simon-laptop dnsmasq[1008]: dnsmasq: unknown interface br-vz0 Jan 5 08:56:16 simon-laptop dnsmasq[1008]: unknown interface br-vz0 Jan 5 08:56:16 simon-laptop dnsmasq[1008]: FAILED to start up Jan 5 08:56:17 simon-laptop NetworkManager[937]: NetworkManager (version 1.0.4) is starting... ... Jan 5 08:56:18 simon-laptop NetworkManager[937]: interface-parser: parsing file /etc/network/interfaces ... Jan 5 08:56:18 simon-laptop NetworkManager[937]: found bridge ports none for br-vz0 Jan 5 08:56:18 simon-laptop NetworkManager[937]: adding bridge port none to eni_ifaces Jan 5 08:56:18 simon-laptop NetworkManager[937]: management mode: unmanaged ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: dnsmasq 2.75-1 ProcVersionSignature: Ubuntu 4.3.0-5.16-generic 4.3.3 Uname: Linux 4.3.0-5-generic x86_64 ApportVersion: 2.19.3-0ubuntu2 Architecture: amd64 CurrentDesktop: Unity Date: Tue Jan 5 09:53:30 2016 PackageArchitecture: all SourcePackage: dnsmasq UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/hundredpapercuts/+bug/1531184/+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 1822776] Re: [SRU] Apply Bash 4.4.20 to fix cpu spinning on built-in wait
Thanks for testing so thoroughly! I've gone ahead and set the verification tags to done, to allow this to now go out. I've also added your script to the Test Case, for future reference. ** Description changed: [Impact] Long running bash loops that create and reap processes will crash, hanging at 100% CPU. [Test Case] A PPA with the proposed fix included is at: - https://launchpad.net/~bryce/+archive/ubuntu/bash-sru-19-010-1 + https://launchpad.net/~bryce/+archive/ubuntu/bash-sru-19-010-1 Install the PPA with the fix via: - sudo add-apt-repository ppa:bryce/bash-sru-19-010-1 - sudo apt-get update - sudo apt-get install bash + sudo add-apt-repository ppa:bryce/bash-sru-19-010-1 + sudo apt-get update + sudo apt-get install bash Run this loop for a few days/weeks: #!/bin/bash while true; do sleep 0.5 & wait done + + Reproducer script: + https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1822776/+attachment/5275112/+files + /bash-crash-test.sh It will eventually cause the 'wait' statement to hang, consuming 100% after some indeterminate amount of time, dependent on how fast PIDs are cycled in the machine. The Bash bug report mentions longer running loops, but it seems hash collisions are the cause, meaning it's just a matter of chance, influenced by how fast PIDs are cycled on the machine. [Regression Potential] The fix has been reviewed and accepted upstream. The patch adds a test at time of pid determination for if the pid is already in use and if so, skip it and pick a different one. This does change behavior slightly in that different pid numbers will be generated in rare cases, but nothing should depend on how pids are generated, as the behavior is not specified to be anything but random. The patch adds a new warning message, "bgp_delete: LOOP: psi (%d) == storage[psi].bucket_next", but this only shows when the original bug would have been triggered. Using 'apt-get source bash' to get the original source version, I created a deb that includes the 4.4.20 patch and have been running it since April 2nd. The 100% CPU spinning is solved, and no other regressions have been observed. Ubuntu 18.04 is already at 4.4.19, which is one patch level behind, so this involves linearly progressing to the next version (so not skipping patches). [Fix] Official patch to fix, and to bump to 4.4.20: http://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 The newest Ubuntu tar.xz with patches I could find at: http://archive.ubuntu.com/ubuntu/pool/main/b/bash/ also didn't have the 4.4.20 patch, so it seems no Ubuntu release has the fix yet. Although not completely sure, this problem seems to have been introduced in the 4.4 version of Bash, so in term of LTS versions, 18.04 and up are affected. [Original Report] Bash pre-4.4.20 has a bug in its PID hash table that causes spin-loops when spawning sub processes and waiting for them. There is a fix: https://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 Our application started being affected (locking up) by this since migrating from Ubuntu 14.04 to 18.04. Ubuntu 14.04 has bash 4.3.11(1), Ubuntu 18.04 has bash 4.4.19 (that is, when running 'bash --version', because of their unusual versions as patches, apt shows it as 4.4.18-2ubuntu1). The 4.4-020 version needs to be included. I think it's actually quite critical. A justification for including the fix would be that a standard language feature in a script language is broken, and that it's indeterminate when it breaks. Considering the wide spread use of bash, I'm surprised not more people have reported issues. My and a client started having issues with independently of each other very soon after upgrading to an affected version. ** Tags removed: verification-needed verification-needed-bionic verification-needed-cosmic ** Tags added: verification-done verification-done-bionic verification-done-cosmic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bash in Ubuntu. https://bugs.launchpad.net/bugs/1822776 Title: [SRU] Apply Bash 4.4.20 to fix cpu spinning on built-in wait Status in bash package in Ubuntu: Fix Released Status in bash source package in Bionic: Fix Committed Status in bash source package in Cosmic: Fix Committed Bug description: [Impact] Long running bash loops that create and reap processes will crash, hanging at 100% CPU. [Test Case] A PPA with the proposed fix included is at: https://launchpad.net/~bryce/+archive/ubuntu/bash-sru-19-010-1 Install the PPA with the fix via: sudo add-apt-repository ppa:bryce/bash-sru-19-010-1 sudo apt-get update sudo apt-get install bash Run this loop for a few days/weeks: #!/bin/bash while true; do sleep 0.5 &
[Touch-packages] [Bug 1834994] Re: rsync: --xattrs is extremely slow
This issue was fixed in Debian with the attached patch from upstream. SRU process prohibits version jumps so would reject directly updating the rsync package on Ubuntu 16.04 to 3.2.2-2. However, if you can define a test case to reliably reproduce the bug, then it may be possible to get the specific patch accepted. Would you be willing to help draft a set of steps to reproduce the bug - preferably something that can be performed within a few minutes or an hour, as opposed to a few weeks (else it'll be too hard for folks to test)? You can see other steps required for filing an SRU at https://wiki.ubuntu.com/StableReleaseUpdates. Anything you can do towards making this bug report fulfill those requirements will make it more likely for this to get attention. One of the potential problems in this case is that the patch is rather large so may be harder to review. SRU's tend to go faster when the patch is just a few lines. ** Patch added: "speedup-xattrs.diff" https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1834994/+attachment/5274955/+files/speedup-xattrs.diff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsync in Ubuntu. https://bugs.launchpad.net/bugs/1834994 Title: rsync: --xattrs is extremely slow Status in rsync package in Ubuntu: New Bug description: Ubuntu 16.04 LTS repositories contain only rsync version 3.1.1: $ apt policy rsync rsync: Installed: 3.1.1-3ubuntu1.2 Candidate: 3.1.1-3ubuntu1.2 Version table: *** 3.1.1-3ubuntu1.2 500 500 http://fi.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 500 http://security.ubuntu.com/ubuntu xenial-security/main amd64 Packages 100 /var/lib/dpkg/status 3.1.1-3ubuntu1 500 500 http://fi.archive.ubuntu.com/ubuntu xenial/main amd64 Packages However, this version has a bug where flag --xattrs causes very very high CPU usage if source contains lots of unique extended attributes. I'm trying to sync 13 TB (roughly 6.5 M files) with extended attributes and this bug seems to make this slower and slower as the time goes by. The system has been copying the stuff for three weeks (!) now. It's getting slower every day but still seems to make progress so I try to run it to completion. First couple of terabytes suggested that this sync operation should have taken around 4 days. The source directory is used by glusterfs which creates checksums as extended attributes and practically every file has different checksum. Please, update rsync package on Ubuntu 16.04 to 3.1.2-2 or later. See also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799143 ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: rsync 3.1.1-3ubuntu1.2 ProcVersionSignature: Ubuntu 4.15.0-51.55~16.04.1-lowlatency 4.15.18 Uname: Linux 4.15.0-51-lowlatency x86_64 NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 CurrentDesktop: MATE Date: Tue Jul 2 09:07:49 2019 InstallationDate: Installed on 2015-02-23 (1589 days ago) InstallationMedia: Ubuntu 14.04.2 LTS "Trusty Tahr" - Release amd64 (20150218.1) SourcePackage: rsync UpgradeStatus: Upgraded to xenial on 2016-06-10 (1116 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1834994/+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 1822776] Re: [SRU] Apply Bash 4.4.20 to fix cpu spinning on built-in wait
Hi halfgaar, just checking in on how the testing has been coming along? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bash in Ubuntu. https://bugs.launchpad.net/bugs/1822776 Title: [SRU] Apply Bash 4.4.20 to fix cpu spinning on built-in wait Status in bash package in Ubuntu: Fix Released Status in bash source package in Bionic: Fix Committed Status in bash source package in Cosmic: Fix Committed Bug description: [Impact] Long running bash loops that create and reap processes will crash, hanging at 100% CPU. [Test Case] A PPA with the proposed fix included is at: https://launchpad.net/~bryce/+archive/ubuntu/bash-sru-19-010-1 Install the PPA with the fix via: sudo add-apt-repository ppa:bryce/bash-sru-19-010-1 sudo apt-get update sudo apt-get install bash Run this loop for a few days/weeks: #!/bin/bash while true; do sleep 0.5 & wait done It will eventually cause the 'wait' statement to hang, consuming 100% after some indeterminate amount of time, dependent on how fast PIDs are cycled in the machine. The Bash bug report mentions longer running loops, but it seems hash collisions are the cause, meaning it's just a matter of chance, influenced by how fast PIDs are cycled on the machine. [Regression Potential] The fix has been reviewed and accepted upstream. The patch adds a test at time of pid determination for if the pid is already in use and if so, skip it and pick a different one. This does change behavior slightly in that different pid numbers will be generated in rare cases, but nothing should depend on how pids are generated, as the behavior is not specified to be anything but random. The patch adds a new warning message, "bgp_delete: LOOP: psi (%d) == storage[psi].bucket_next", but this only shows when the original bug would have been triggered. Using 'apt-get source bash' to get the original source version, I created a deb that includes the 4.4.20 patch and have been running it since April 2nd. The 100% CPU spinning is solved, and no other regressions have been observed. Ubuntu 18.04 is already at 4.4.19, which is one patch level behind, so this involves linearly progressing to the next version (so not skipping patches). [Fix] Official patch to fix, and to bump to 4.4.20: http://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 The newest Ubuntu tar.xz with patches I could find at: http://archive.ubuntu.com/ubuntu/pool/main/b/bash/ also didn't have the 4.4.20 patch, so it seems no Ubuntu release has the fix yet. Although not completely sure, this problem seems to have been introduced in the 4.4 version of Bash, so in term of LTS versions, 18.04 and up are affected. [Original Report] Bash pre-4.4.20 has a bug in its PID hash table that causes spin-loops when spawning sub processes and waiting for them. There is a fix: https://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 Our application started being affected (locking up) by this since migrating from Ubuntu 14.04 to 18.04. Ubuntu 14.04 has bash 4.3.11(1), Ubuntu 18.04 has bash 4.4.19 (that is, when running 'bash --version', because of their unusual versions as patches, apt shows it as 4.4.18-2ubuntu1). The 4.4-020 version needs to be included. I think it's actually quite critical. A justification for including the fix would be that a standard language feature in a script language is broken, and that it's indeterminate when it breaks. Considering the wide spread use of bash, I'm surprised not more people have reported issues. My and a client started having issues with independently of each other very soon after upgrading to an affected version. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1822776/+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 1834129] Re: Presence of sshd_config mandatory
Hi Luke, thanks for reporting this issue. Unfortunately, I am not able
to reproduce it.
Ubuntu 18.04.2 ships openssh-server 1:7.6p1-4ubuntu0.3, not 7.9. Is the
version typo'd in the report or are you running a self-installed version
of openssh perhaps?
In any case, I attempted reproduction on both 18.04 (bionic) and 19.10
(eoan) in lxc, but was not able to reproduce a fault. If you could,
please provide an exact set of commands to reproduce, and the error
message you encountered. Please also verify you're running the stock
distro version of openssh when doing - reproducing in a clean vanilla
lxc instance or a fresh installation of ubuntu would be helpful.
$ lxc launch ubuntu:18.04/amd64 lp1834129
$ lxc exec lp1834129 bash
# apt-get update
[...]
# ps aux | grep sshd
root 685 0.0 0.0 72296 5660 ?Ss 22:31 0:00 /usr/sbin/sshd
-D
root 687 0.0 0.0 14856 1008 ?S+ 22:31 0:00 grep
--color=auto sshd
# service sshd stop
# ps aux | grep sshd
root 718 0.0 0.0 14856 1116 ?S+ 22:31 0:00 grep
--color=auto sshd
# ls -l /run/ssh*
ls: cannot access '/run/ssh*': No such file or directory
# touch my_sshd_config
# sshd -f ./my_sshd_config
sshd re-exec requires execution with an absolute path
# /usr/sbin/sshd -f ./my_sshd_config
Missing privilege separation directory: /run/sshd
# mkdir /run/sshd
# /usr/sbin/sshd -f ./my_sshd_config
# ps aux | grep sshd
root 725 0.0 0.0 72296 3344 ?Ss 22:31 0:00 /usr/sbin/sshd
-f ./my_sshd_config
root 727 0.0 0.0 14856 1040 ?S+ 22:31 0:00 grep
--color=auto sshd
# kill 725
# !ps
ps aux | grep sshd
root 729 0.0 0.0 14856 1004 ?S+ 22:32 0:00 grep
--color=auto sshd
# mv /etc/ssh/sshd_config /tmp/
# /usr/sbin/sshd -f ./my_sshd_config
# !ps
ps aux | grep sshd
root 732 0.0 0.0 72296 3200 ?Ss 22:32 0:00 /usr/sbin/sshd
-f ./my_sshd_config
root 734 0.0 0.0 14856 1156 ?S+ 22:32 0:00 grep
--color=auto sshd
# ls -l /etc/ssh/sshd_*
ls: cannot access '/etc/ssh/sshd_*': No such file or directory
# passwd ubuntu
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
# su ubuntu
To run a command as administrator (user "root"), use "sudo ".
See "man sudo_root" for details.
$ ssh localhost
ubuntu@localhost's password:
To run a command as administrator (user "root"), use "sudo ".
See "man sudo_root" for details.
$ logout
Connection to localhost closed.
$ . /etc/lsb-release && echo ${DISTRIB_DESCRIPTION}
Ubuntu 18.04.2 LTS
$ ssh -V
OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017
$ apt-cache policy openssh-server | grep Installed
Installed: 1:7.6p1-4ubuntu0.3
** Changed in: openssh (Ubuntu)
Status: New => Incomplete
--
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/1834129
Title:
Presence of sshd_config mandatory
Status in openssh package in Ubuntu:
Incomplete
Bug description:
OpenSSH 7.9p1
Ubuntu 18..04.2 (LTS)
If a sshd daemon is started with a "-f my_sshd_config" command-line
specification the sshd process still requires the existence of the
sshd_config. The bug is somewhere in one of the forked processes
started when an external client attempts a connection. Since the
sshd_config file does not exists, an external client connection cannot
be started.
Solution: If I "touch /etc/ssh/sshd_config" then the lock-up issue
goes away and I am successfully able to login.
Bug: If the sshd configuration file is specified in the command line
execution of the daeomon, then this should be the only file that
should be required.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1834129/+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 1819074] Re: Keepalived < 2.0.x in Ubuntu 18.04 LTS not compatible with systemd-networkd
** Tags added: server-next -- 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/1819074 Title: Keepalived < 2.0.x in Ubuntu 18.04 LTS not compatible with systemd- networkd Status in keepalived package in Ubuntu: Triaged Status in netplan.io package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in keepalived source package in Bionic: Triaged Status in netplan.io source package in Bionic: New Status in systemd source package in Bionic: New Status in keepalived source package in Cosmic: Triaged Status in netplan.io source package in Cosmic: New Status in systemd source package in Cosmic: New Bug description: Systemd-networkd clobbers VIPs placed by other daemons on any reconfiguration triggering systemd-networkd restart (netplan apply for example). Keepalived < version 2.0.x will not restore a VIP lost in this fashion, breaking high availability on Ubuntu 18.04 LTS. A backport for keepalived >= 2.0.x should fix the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/keepalived/+bug/1819074/+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 1819074] Re: Keepalived < 2.0.x in Ubuntu 18.04 LTS not compatible with systemd-networkd
** Changed in: keepalived (Ubuntu Bionic) Status: New => Triaged ** Changed in: keepalived (Ubuntu Cosmic) Status: New => Triaged ** Changed in: keepalived (Ubuntu) Importance: Undecided => Medium ** Changed in: keepalived (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: keepalived (Ubuntu Cosmic) 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/1819074 Title: Keepalived < 2.0.x in Ubuntu 18.04 LTS not compatible with systemd- networkd Status in keepalived package in Ubuntu: Triaged Status in netplan.io package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in keepalived source package in Bionic: Triaged Status in netplan.io source package in Bionic: New Status in systemd source package in Bionic: New Status in keepalived source package in Cosmic: Triaged Status in netplan.io source package in Cosmic: New Status in systemd source package in Cosmic: New Bug description: Systemd-networkd clobbers VIPs placed by other daemons on any reconfiguration triggering systemd-networkd restart (netplan apply for example). Keepalived < version 2.0.x will not restore a VIP lost in this fashion, breaking high availability on Ubuntu 18.04 LTS. A backport for keepalived >= 2.0.x should fix the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/keepalived/+bug/1819074/+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 1819074] Re: Keepalived < 2.0.x in Ubuntu 18.04 LTS not compatible with systemd-networkd
Given SRU and backport team policies, having a newer version of keepalived in bionic seems pretty unlikely. SRU policy favors backports of specific fixes rather than entire package backports, while the backports team generally discourages backports of libraries or services since they can randomly break other software using them. So, the most practical route forward would be to identify the patch(es) needed for fixing the particular issue at hand, and go through the regular SRU process. I am, unfortunately, completely unfamiliar with keepalived, but attached is a list of upstream comments mentioning "VIP" since the v.1.3.9 release, which I generated like this: git log --grep="VIP" v1.3.9.. > /tmp/vip_commits.txt The next step would be for someone more familiar than me, to review the list and identify 1 or 2 patches worth testing. Then apply the patch to the bionic keepalived package and test for a fix. After we know what patch is needed, an SRU request can be placed to have it released for all users. ** Attachment added: "vip_commits.txt" https://bugs.launchpad.net/ubuntu/+source/keepalived/+bug/1819074/+attachment/5271627/+files/vip_commits.txt ** Changed in: keepalived (Ubuntu) Status: Confirmed => Triaged -- 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/1819074 Title: Keepalived < 2.0.x in Ubuntu 18.04 LTS not compatible with systemd- networkd Status in keepalived package in Ubuntu: Triaged Status in netplan.io package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in keepalived source package in Bionic: New Status in netplan.io source package in Bionic: New Status in systemd source package in Bionic: New Status in keepalived source package in Cosmic: New Status in netplan.io source package in Cosmic: New Status in systemd source package in Cosmic: New Bug description: Systemd-networkd clobbers VIPs placed by other daemons on any reconfiguration triggering systemd-networkd restart (netplan apply for example). Keepalived < version 2.0.x will not restore a VIP lost in this fashion, breaking high availability on Ubuntu 18.04 LTS. A backport for keepalived >= 2.0.x should fix the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/keepalived/+bug/1819074/+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 1819074] Re: Keepalived < 2.0.x in Ubuntu 18.04 LTS not compatible with systemd-networkd
Oh, one other thing that will be necessary to file an SRU for this would be a a series of "paint by number" steps to reproduce the issue, and to verify the fix. For example, something akin to: https://bugs.launchpad.net/ubuntu/+source/keepalived/+bug/1810583/comments/12 ** Also affects: keepalived (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: netplan.io (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: keepalived (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: netplan.io (Ubuntu Bionic) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1819074 Title: Keepalived < 2.0.x in Ubuntu 18.04 LTS not compatible with systemd- networkd Status in keepalived package in Ubuntu: Triaged Status in netplan.io package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in keepalived source package in Bionic: New Status in netplan.io source package in Bionic: New Status in systemd source package in Bionic: New Status in keepalived source package in Cosmic: New Status in netplan.io source package in Cosmic: New Status in systemd source package in Cosmic: New Bug description: Systemd-networkd clobbers VIPs placed by other daemons on any reconfiguration triggering systemd-networkd restart (netplan apply for example). Keepalived < version 2.0.x will not restore a VIP lost in this fashion, breaking high availability on Ubuntu 18.04 LTS. A backport for keepalived >= 2.0.x should fix the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/keepalived/+bug/1819074/+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 1822776] Re: Apply Bash 4.4.20 to fix cpu spinning on built-in wait
Fixes have been pushed to cosmic-proposed and bionic-proposed. ** Summary changed: - Apply Bash 4.4.20 to fix cpu spinning on built-in wait + [SRU] Apply Bash 4.4.20 to fix cpu spinning on built-in wait -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bash in Ubuntu. https://bugs.launchpad.net/bugs/1822776 Title: [SRU] Apply Bash 4.4.20 to fix cpu spinning on built-in wait Status in bash package in Ubuntu: Fix Released Status in bash source package in Bionic: In Progress Status in bash source package in Cosmic: In Progress Bug description: [Impact] Long running bash loops that create and reap processes will crash, hanging at 100% CPU. [Test Case] A PPA with the proposed fix included is at: https://launchpad.net/~bryce/+archive/ubuntu/bash-sru-19-010-1 Install the PPA with the fix via: sudo add-apt-repository ppa:bryce/bash-sru-19-010-1 sudo apt-get update sudo apt-get install bash Run this loop for a few days/weeks: #!/bin/bash while true; do sleep 0.5 & wait done It will eventually cause the 'wait' statement to hang, consuming 100% after some indeterminate amount of time, dependent on how fast PIDs are cycled in the machine. The Bash bug report mentions longer running loops, but it seems hash collisions are the cause, meaning it's just a matter of chance, influenced by how fast PIDs are cycled on the machine. [Regression Potential] The fix has been reviewed and accepted upstream. The patch adds a test at time of pid determination for if the pid is already in use and if so, skip it and pick a different one. This does change behavior slightly in that different pid numbers will be generated in rare cases, but nothing should depend on how pids are generated, as the behavior is not specified to be anything but random. The patch adds a new warning message, "bgp_delete: LOOP: psi (%d) == storage[psi].bucket_next", but this only shows when the original bug would have been triggered. Using 'apt-get source bash' to get the original source version, I created a deb that includes the 4.4.20 patch and have been running it since April 2nd. The 100% CPU spinning is solved, and no other regressions have been observed. Ubuntu 18.04 is already at 4.4.19, which is one patch level behind, so this involves linearly progressing to the next version (so not skipping patches). [Fix] Official patch to fix, and to bump to 4.4.20: http://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 The newest Ubuntu tar.xz with patches I could find at: http://archive.ubuntu.com/ubuntu/pool/main/b/bash/ also didn't have the 4.4.20 patch, so it seems no Ubuntu release has the fix yet. Although not completely sure, this problem seems to have been introduced in the 4.4 version of Bash, so in term of LTS versions, 18.04 and up are affected. [Original Report] Bash pre-4.4.20 has a bug in its PID hash table that causes spin-loops when spawning sub processes and waiting for them. There is a fix: https://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 Our application started being affected (locking up) by this since migrating from Ubuntu 14.04 to 18.04. Ubuntu 14.04 has bash 4.3.11(1), Ubuntu 18.04 has bash 4.4.19 (that is, when running 'bash --version', because of their unusual versions as patches, apt shows it as 4.4.18-2ubuntu1). The 4.4-020 version needs to be included. I think it's actually quite critical. A justification for including the fix would be that a standard language feature in a script language is broken, and that it's indeterminate when it breaks. Considering the wide spread use of bash, I'm surprised not more people have reported issues. My and a client started having issues with independently of each other very soon after upgrading to an affected version. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1822776/+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 1531184] Re: [SRU] dnsmasq doesn't start on boot because its interface isn't up yet
** Description changed: [Impact] TBD [Test Case] TBD [Regression Potential] + The fix is just configuring the order of service startup, so is unlikely to create any regressions. Things to watch would be service related misbehaviors and general availability of the dnsmasq functionality. [Fix] + https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=774970;filename=774970-network-online.debdiff;msg=22 [Discussion] [Original Report] - - My dnsmasq instance uses "interface=br-vz0" and the interface br-vz0 is - managed manually in /etc/network/interfaces. + My dnsmasq instance uses "interface=br-vz0" and the interface br-vz0 is managed manually in /etc/network/interfaces. During boot, dnsmasq is started before br-vz0 is created and this causes dnsmasq to exit: Jan 5 08:56:16 simon-laptop dnsmasq[1008]: dnsmasq: unknown interface br-vz0 Jan 5 08:56:16 simon-laptop dnsmasq[1008]: unknown interface br-vz0 Jan 5 08:56:16 simon-laptop dnsmasq[1008]: FAILED to start up Jan 5 08:56:17 simon-laptop NetworkManager[937]: NetworkManager (version 1.0.4) is starting... ... Jan 5 08:56:18 simon-laptop NetworkManager[937]: interface-parser: parsing file /etc/network/interfaces ... Jan 5 08:56:18 simon-laptop NetworkManager[937]: found bridge ports none for br-vz0 Jan 5 08:56:18 simon-laptop NetworkManager[937]: adding bridge port none to eni_ifaces Jan 5 08:56:18 simon-laptop NetworkManager[937]: management mode: unmanaged ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: dnsmasq 2.75-1 ProcVersionSignature: Ubuntu 4.3.0-5.16-generic 4.3.3 Uname: Linux 4.3.0-5-generic x86_64 ApportVersion: 2.19.3-0ubuntu2 Architecture: amd64 CurrentDesktop: Unity Date: Tue Jan 5 09:53:30 2016 PackageArchitecture: all SourcePackage: dnsmasq UpgradeStatus: No upgrade log present (probably fresh install) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1531184 Title: [SRU] dnsmasq doesn't start on boot because its interface isn't up yet Status in One Hundred Papercuts: Confirmed Status in dnsmasq package in Ubuntu: Confirmed Status in dnsmasq package in Debian: New Bug description: [Impact] TBD [Test Case] TBD [Regression Potential] The fix is just configuring the order of service startup, so is unlikely to create any regressions. Things to watch would be service related misbehaviors and general availability of the dnsmasq functionality. [Fix] https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=774970;filename=774970-network-online.debdiff;msg=22 [Discussion] [Original Report] My dnsmasq instance uses "interface=br-vz0" and the interface br-vz0 is managed manually in /etc/network/interfaces. During boot, dnsmasq is started before br-vz0 is created and this causes dnsmasq to exit: Jan 5 08:56:16 simon-laptop dnsmasq[1008]: dnsmasq: unknown interface br-vz0 Jan 5 08:56:16 simon-laptop dnsmasq[1008]: unknown interface br-vz0 Jan 5 08:56:16 simon-laptop dnsmasq[1008]: FAILED to start up Jan 5 08:56:17 simon-laptop NetworkManager[937]: NetworkManager (version 1.0.4) is starting... ... Jan 5 08:56:18 simon-laptop NetworkManager[937]: interface-parser: parsing file /etc/network/interfaces ... Jan 5 08:56:18 simon-laptop NetworkManager[937]: found bridge ports none for br-vz0 Jan 5 08:56:18 simon-laptop NetworkManager[937]: adding bridge port none to eni_ifaces Jan 5 08:56:18 simon-laptop NetworkManager[937]: management mode: unmanaged ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: dnsmasq 2.75-1 ProcVersionSignature: Ubuntu 4.3.0-5.16-generic 4.3.3 Uname: Linux 4.3.0-5-generic x86_64 ApportVersion: 2.19.3-0ubuntu2 Architecture: amd64 CurrentDesktop: Unity Date: Tue Jan 5 09:53:30 2016 PackageArchitecture: all SourcePackage: dnsmasq UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/hundredpapercuts/+bug/1531184/+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 1531184] Re: [SRU] dnsmasq doesn't start on boot because its interface isn't up yet
** Description changed: + [Impact] + TBD + + [Test Case] + TBD + + [Regression Potential] + + [Fix] + + [Discussion] + + [Original Report] + My dnsmasq instance uses "interface=br-vz0" and the interface br-vz0 is managed manually in /etc/network/interfaces. During boot, dnsmasq is started before br-vz0 is created and this causes dnsmasq to exit: Jan 5 08:56:16 simon-laptop dnsmasq[1008]: dnsmasq: unknown interface br-vz0 Jan 5 08:56:16 simon-laptop dnsmasq[1008]: unknown interface br-vz0 Jan 5 08:56:16 simon-laptop dnsmasq[1008]: FAILED to start up Jan 5 08:56:17 simon-laptop NetworkManager[937]: NetworkManager (version 1.0.4) is starting... ... Jan 5 08:56:18 simon-laptop NetworkManager[937]: interface-parser: parsing file /etc/network/interfaces ... Jan 5 08:56:18 simon-laptop NetworkManager[937]: found bridge ports none for br-vz0 Jan 5 08:56:18 simon-laptop NetworkManager[937]: adding bridge port none to eni_ifaces Jan 5 08:56:18 simon-laptop NetworkManager[937]: management mode: unmanaged ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: dnsmasq 2.75-1 ProcVersionSignature: Ubuntu 4.3.0-5.16-generic 4.3.3 Uname: Linux 4.3.0-5-generic x86_64 ApportVersion: 2.19.3-0ubuntu2 Architecture: amd64 CurrentDesktop: Unity Date: Tue Jan 5 09:53:30 2016 PackageArchitecture: all SourcePackage: dnsmasq UpgradeStatus: No upgrade log present (probably fresh install) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1531184 Title: [SRU] dnsmasq doesn't start on boot because its interface isn't up yet Status in One Hundred Papercuts: Confirmed Status in dnsmasq package in Ubuntu: Confirmed Status in dnsmasq package in Debian: New Bug description: [Impact] TBD [Test Case] TBD [Regression Potential] The fix is just configuring the order of service startup, so is unlikely to create any regressions. Things to watch would be service related misbehaviors and general availability of the dnsmasq functionality. [Fix] https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=774970;filename=774970-network-online.debdiff;msg=22 [Discussion] [Original Report] My dnsmasq instance uses "interface=br-vz0" and the interface br-vz0 is managed manually in /etc/network/interfaces. During boot, dnsmasq is started before br-vz0 is created and this causes dnsmasq to exit: Jan 5 08:56:16 simon-laptop dnsmasq[1008]: dnsmasq: unknown interface br-vz0 Jan 5 08:56:16 simon-laptop dnsmasq[1008]: unknown interface br-vz0 Jan 5 08:56:16 simon-laptop dnsmasq[1008]: FAILED to start up Jan 5 08:56:17 simon-laptop NetworkManager[937]: NetworkManager (version 1.0.4) is starting... ... Jan 5 08:56:18 simon-laptop NetworkManager[937]: interface-parser: parsing file /etc/network/interfaces ... Jan 5 08:56:18 simon-laptop NetworkManager[937]: found bridge ports none for br-vz0 Jan 5 08:56:18 simon-laptop NetworkManager[937]: adding bridge port none to eni_ifaces Jan 5 08:56:18 simon-laptop NetworkManager[937]: management mode: unmanaged ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: dnsmasq 2.75-1 ProcVersionSignature: Ubuntu 4.3.0-5.16-generic 4.3.3 Uname: Linux 4.3.0-5-generic x86_64 ApportVersion: 2.19.3-0ubuntu2 Architecture: amd64 CurrentDesktop: Unity Date: Tue Jan 5 09:53:30 2016 PackageArchitecture: all SourcePackage: dnsmasq UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/hundredpapercuts/+bug/1531184/+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 1531184] Re: [SRU] dnsmasq doesn't start on boot because its interface isn't up yet
** Summary changed: - dnsmasq doesn't start on boot because its interface isn't up yet + [SRU] dnsmasq doesn't start on boot because its interface isn't up yet -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1531184 Title: [SRU] dnsmasq doesn't start on boot because its interface isn't up yet Status in One Hundred Papercuts: Confirmed Status in dnsmasq package in Ubuntu: Confirmed Status in dnsmasq package in Debian: New Bug description: My dnsmasq instance uses "interface=br-vz0" and the interface br-vz0 is managed manually in /etc/network/interfaces. During boot, dnsmasq is started before br-vz0 is created and this causes dnsmasq to exit: Jan 5 08:56:16 simon-laptop dnsmasq[1008]: dnsmasq: unknown interface br-vz0 Jan 5 08:56:16 simon-laptop dnsmasq[1008]: unknown interface br-vz0 Jan 5 08:56:16 simon-laptop dnsmasq[1008]: FAILED to start up Jan 5 08:56:17 simon-laptop NetworkManager[937]: NetworkManager (version 1.0.4) is starting... ... Jan 5 08:56:18 simon-laptop NetworkManager[937]: interface-parser: parsing file /etc/network/interfaces ... Jan 5 08:56:18 simon-laptop NetworkManager[937]: found bridge ports none for br-vz0 Jan 5 08:56:18 simon-laptop NetworkManager[937]: adding bridge port none to eni_ifaces Jan 5 08:56:18 simon-laptop NetworkManager[937]: management mode: unmanaged ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: dnsmasq 2.75-1 ProcVersionSignature: Ubuntu 4.3.0-5.16-generic 4.3.3 Uname: Linux 4.3.0-5-generic x86_64 ApportVersion: 2.19.3-0ubuntu2 Architecture: amd64 CurrentDesktop: Unity Date: Tue Jan 5 09:53:30 2016 PackageArchitecture: all SourcePackage: dnsmasq UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/hundredpapercuts/+bug/1531184/+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 1822776] Re: Apply Bash 4.4.20 to fix cpu spinning on built-in wait
** Description changed: [Impact] Long running bash loops that create and reap processes will crash, hanging at 100% CPU. + [Test Case] - [Test Case] + A PPA with the proposed fix included is at: + + https://launchpad.net/~bryce/+archive/ubuntu/bash-sru-19-010-1 + + Install the PPA with the fix via: + + sudo add-apt-repository ppa:bryce/bash-sru-19-010-1 + sudo apt-get update + sudo apt-get install bash Run this loop for a few days/weeks: #!/bin/bash while true; do sleep 0.5 & wait done It will eventually cause the 'wait' statement to hang, consuming 100% after some indeterminate amount of time, dependent on how fast PIDs are cycled in the machine. The Bash bug report mentions longer running loops, but it seems hash collisions are the cause, meaning it's just a matter of chance, influenced by how fast PIDs are cycled on the machine. - [Regression Potential] The fix has been reviewed and accepted upstream. The patch adds a test at time of pid determination for if the pid is already in use and if so, skip it and pick a different one. This does change behavior slightly in that different pid numbers will be generated in rare cases, but nothing should depend on how pids are generated, as the behavior is not specified to be anything but random. The patch adds a new warning message, "bgp_delete: LOOP: psi (%d) == storage[psi].bucket_next", but this only shows when the original bug would have been triggered. Using 'apt-get source bash' to get the original source version, I created a deb that includes the 4.4.20 patch and have been running it since April 2nd. The 100% CPU spinning is solved, and no other regressions have been observed. Ubuntu 18.04 is already at 4.4.19, which is one patch level behind, so this involves linearly progressing to the next version (so not skipping patches). - [Fix] Official patch to fix, and to bump to 4.4.20: http://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 The newest Ubuntu tar.xz with patches I could find at: http://archive.ubuntu.com/ubuntu/pool/main/b/bash/ also didn't have the 4.4.20 patch, so it seems no Ubuntu release has the fix yet. Although not completely sure, this problem seems to have been introduced in the 4.4 version of Bash, so in term of LTS versions, 18.04 and up are affected. - [Original Report] Bash pre-4.4.20 has a bug in its PID hash table that causes spin-loops when spawning sub processes and waiting for them. There is a fix: https://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 Our application started being affected (locking up) by this since migrating from Ubuntu 14.04 to 18.04. Ubuntu 14.04 has bash 4.3.11(1), Ubuntu 18.04 has bash 4.4.19 (that is, when running 'bash --version', because of their unusual versions as patches, apt shows it as 4.4.18-2ubuntu1). The 4.4-020 version needs to be included. I think it's actually quite critical. A justification for including the fix would be that a standard language feature in a script language is broken, and that it's indeterminate when it breaks. Considering the wide spread use of bash, I'm surprised not more people have reported issues. My and a client started having issues with independently of each other very soon after upgrading to an affected version. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bash in Ubuntu. https://bugs.launchpad.net/bugs/1822776 Title: Apply Bash 4.4.20 to fix cpu spinning on built-in wait Status in bash package in Ubuntu: Fix Released Status in bash source package in Bionic: In Progress Status in bash source package in Cosmic: In Progress Bug description: [Impact] Long running bash loops that create and reap processes will crash, hanging at 100% CPU. [Test Case] A PPA with the proposed fix included is at: https://launchpad.net/~bryce/+archive/ubuntu/bash-sru-19-010-1 Install the PPA with the fix via: sudo add-apt-repository ppa:bryce/bash-sru-19-010-1 sudo apt-get update sudo apt-get install bash Run this loop for a few days/weeks: #!/bin/bash while true; do sleep 0.5 & wait done It will eventually cause the 'wait' statement to hang, consuming 100% after some indeterminate amount of time, dependent on how fast PIDs are cycled in the machine. The Bash bug report mentions longer running loops, but it seems hash collisions are the cause, meaning it's just a matter of chance, influenced by how fast PIDs are cycled on the machine. [Regression Potential] The fix has been reviewed and accepted upstream. The patch adds a test at time of pid determination for if the pid is already in use and if so, skip it and pick a different one. This does change behavior slightly in that different pid numbers will
[Touch-packages] [Bug 1822776] Re: Apply Bash 4.4.20 to fix cpu spinning on built-in wait
** Changed in: bash (Ubuntu Bionic) Status: New => In Progress ** Changed in: bash (Ubuntu Cosmic) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bash in Ubuntu. https://bugs.launchpad.net/bugs/1822776 Title: Apply Bash 4.4.20 to fix cpu spinning on built-in wait Status in bash package in Ubuntu: Fix Released Status in bash source package in Bionic: In Progress Status in bash source package in Cosmic: In Progress Bug description: [Impact] Long running bash loops that create and reap processes will crash, hanging at 100% CPU. [Test Case] Run this loop for a few days/weeks: #!/bin/bash while true; do sleep 0.5 & wait done It will eventually cause the 'wait' statement to hang, consuming 100% after some indeterminate amount of time, dependent on how fast PIDs are cycled in the machine. The Bash bug report mentions longer running loops, but it seems hash collisions are the cause, meaning it's just a matter of chance, influenced by how fast PIDs are cycled on the machine. [Regression Potential] The fix has been reviewed and accepted upstream. The patch adds a test at time of pid determination for if the pid is already in use and if so, skip it and pick a different one. This does change behavior slightly in that different pid numbers will be generated in rare cases, but nothing should depend on how pids are generated, as the behavior is not specified to be anything but random. The patch adds a new warning message, "bgp_delete: LOOP: psi (%d) == storage[psi].bucket_next", but this only shows when the original bug would have been triggered. Using 'apt-get source bash' to get the original source version, I created a deb that includes the 4.4.20 patch and have been running it since April 2nd. The 100% CPU spinning is solved, and no other regressions have been observed. Ubuntu 18.04 is already at 4.4.19, which is one patch level behind, so this involves linearly progressing to the next version (so not skipping patches). [Fix] Official patch to fix, and to bump to 4.4.20: http://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 The newest Ubuntu tar.xz with patches I could find at: http://archive.ubuntu.com/ubuntu/pool/main/b/bash/ also didn't have the 4.4.20 patch, so it seems no Ubuntu release has the fix yet. Although not completely sure, this problem seems to have been introduced in the 4.4 version of Bash, so in term of LTS versions, 18.04 and up are affected. [Original Report] Bash pre-4.4.20 has a bug in its PID hash table that causes spin-loops when spawning sub processes and waiting for them. There is a fix: https://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 Our application started being affected (locking up) by this since migrating from Ubuntu 14.04 to 18.04. Ubuntu 14.04 has bash 4.3.11(1), Ubuntu 18.04 has bash 4.4.19 (that is, when running 'bash --version', because of their unusual versions as patches, apt shows it as 4.4.18-2ubuntu1). The 4.4-020 version needs to be included. I think it's actually quite critical. A justification for including the fix would be that a standard language feature in a script language is broken, and that it's indeterminate when it breaks. Considering the wide spread use of bash, I'm surprised not more people have reported issues. My and a client started having issues with independently of each other very soon after upgrading to an affected version. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1822776/+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 1830121] Re: rsync --rsync-path="sudo rsync" over ssh via pki fails due to protocol mismatch
Hi Gareth, thanks for following up, and glad to hear you've sorted the trouble out! ** Changed in: rsync (Ubuntu) Status: Incomplete => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsync in Ubuntu. https://bugs.launchpad.net/bugs/1830121 Title: rsync --rsync-path="sudo rsync" over ssh via pki fails due to protocol mismatch Status in Ubuntu MATE: Invalid Status in rsync package in Ubuntu: Invalid Bug description: rsync with remote sudo fails over ssh on Ubuntu Mate 18.04.2 rsync version 3.1.2 protocol version 31 - same on local and remote OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017 - same on local and remote I have checked for spurious output from .bashrc using $ ssh user@host /bin/true > out.dat which results in $ ls -l *.dat -rw-rw-r-- 1 user user 0 May 22 23:33 out.dat -- The [redacted] command is rsync -AEavvvogt --rsync-path="sudo rsync" --debug=CONNECT -e "ssh -i /home/xxx/.ssh/id_rsa -tt -v -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" --exclude-from=/home/xxx/backup.exclude --delete --link-dest=../$lastdt /etc $dest/$dt; -- The [redacted] output is opening connection using: ssh -i /home/user/.ssh/id_rsa -tt -v -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -l user xxx "sudo rsync" --server -vvvlogDtpAre.iLsfxC --delete --link-dest ../20190506_021137 . /home/backups/xxx/20190522_232738 (20 args) OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to xxx [192.168.1.120] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /home/user/.ssh/id_rsa type 0 debug1: key_load_public: No such file or directory debug1: identity file /home/user/.ssh/id_rsa-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 debug1: match: OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 pat OpenSSH* compat 0x0400 debug1: Authenticating to xxx:22 as 'user' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: curve25519-sha256 debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex: server->client cipher: chacha20-poly1...@openssh.com MAC: compression: none debug1: kex: client->server cipher: chacha20-poly1...@openssh.com MAC: compression: none debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: xxx Warning: Permanently added 'xxx,192.168.1.120' (ECDSA) to the list of known hosts. debug1: rekey after 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey after 134217728 blocks debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs= debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Offering public key: RSA SHA256:xxx /home/user/.ssh/id_rsa debug1: Server accepts key: xxx debug1: Authentication succeeded (publickey). Authenticated to xxx ([192.168.1.120]:22). debug1: channel 0: new [client-session] debug1: Requesting no-more-sessi...@openssh.com debug1: Entering interactive session. debug1: pledge: network debug1: client_input_global_request: rtype hostkeys...@openssh.com want_reply 0 debug1: tty_make_modes: no fd or tio debug1: Sending environment. debug1: Sending env LANG = en_GB.UTF-8 debug1: Sending command: sudo rsync --server -vvvlogDtpAre.iLsfxC --delete --link-dest ../20190506_021137 . /home/backups/xxx/20190522_232738 protocol version mismatch -- is your shell clean? (see the rsync man page for an explanation) rsync error: protocol incompatibility (code 2) at compat.c(178) [sender=3.1.2] [sender] _exit_cleanup(code=2, file=compat.c, line=178): about to call exit(2) /etc/sudoers contains userALL= NOPASSWD:/usr/bin/rsync ...which I have tried placing above (as is the default) and below lines beginning %admin and %sudo and the space in "ALL= NOPASSWD..." doesn't seem to make any difference I followed the instructions at https://www.digitalocean.com/community/tutorials/how-to-copy-files-with-rsync-over-ssh https://askubuntu.com/questions/719439/using-rsync-with-sudo-on-the-destination-machine - which worked on 16.04, so I wonder if there may be a bug, although grateful for any other suggestions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-mate/+bug/1830121/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe :
[Touch-packages] [Bug 1778073] Re: dnsmasq and resolvconf hangs on start
Hi Thomas, have you had a chance to re-test this on 18.04? From Christian's comment #3, sounds like this issue may already be resolved, but if not we can investigate further. ** Changed in: dnsmasq (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/1778073 Title: dnsmasq and resolvconf hangs on start Status in dnsmasq package in Ubuntu: Incomplete Status in dnsmasq package in Debian: New Bug description: I installed today dnsmasq and I use resolvconf in background. Problem is, that systemd takes 1 minute or so after service start and than reports: root@proxy:~# service dnsmasq status dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled) Drop-In: /run/systemd/generator/dnsmasq.service.d 50-dnsmasq-$named.conf, 50-insserv.conf-$named.conf Active: failed (Result: timeout) since Do 2018-06-21 15:58:13 CEST; 2min 10s ago Process: 3295 ExecStop=/etc/init.d/dnsmasq systemd-stop-resolvconf (code=killed, signal=TERM) Process: 3865 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf (code=killed, signal=TERM) Process: 3837 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, status=0/SUCCESS) Process: 3825 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, status=0/SUCCESS) Main PID: 3862 (code=exited, status=0/SUCCESS) Jun 21 15:56:43 proxy dnsmasq[3862]: Benutze Namensserver 192.168.23.1#53 Jun 21 15:56:43 proxy dnsmasq[3865]: * Awakening mail retriever agent: Jun 21 15:56:43 proxy dnsmasq[3865]:...done. Jun 21 15:56:43 proxy postfix[3951]: Postfix is running with backwards-compatible default settings Jun 21 15:56:43 proxy postfix[3951]: See http://www.postfix.org/COMPATIBILITY_README.html for details Jun 21 15:56:43 proxy postfix[3951]: To disable backwards compatibility use "postconf compatibility_level=2" and "postfix reload" Jun 21 15:58:13 proxy systemd[1]: dnsmasq.service: Start-post operation timed out. Stopping. Jun 21 15:58:13 proxy systemd[1]: Failed to start dnsmasq - A lightweight DHCP and caching DNS server. Jun 21 15:58:13 proxy systemd[1]: dnsmasq.service: Unit entered failed state. Jun 21 15:58:13 proxy systemd[1]: dnsmasq.service: Failed with result 'timeout'. when I look into the start script /etc/init.d/dnsmasq there is a func systemd-start-resolvconf which points to start-resolvconf. There is this part: for interface in $DNSMASQ_EXCEPT do [ $interface = lo ] && return done Before I had not defined DNSMASQ_EXCEPT in /etc/defaults/dnsmasq. Problem is, that this part MUST be faulty! When I commend it out, I can start dnsmasq! It looks like it loops forever there?! Also if I define DNSMASQ_EXCEPT to my listen interface, it works - but is is really needed? I found a other user which had the same problem: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871958 ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: dnsmasq 2.75-1ubuntu0.16.04.4 [modified: etc/default/dnsmasq] ProcVersionSignature: Ubuntu 4.15.0-23.25~16.04.1-generic 4.15.18 Uname: Linux 4.15.0-23-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 Date: Thu Jun 21 16:12:14 2018 InstallationDate: Installed on 2017-02-27 (479 days ago) InstallationMedia: Ubuntu-Server 16.04.2 LTS "Xenial Xerus" - Release amd64 (20170215.8) PackageArchitecture: all ProcEnviron: TERM=xterm SHELL=/bin/bash PATH=(custom, no user) LANG=de_DE.UTF-8 SourcePackage: dnsmasq UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.default.dnsmasq: 2018-06-21T16:07:24.818774 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1778073/+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 1822776] Re: Apply Bash 4.4.20 to fix cpu spinning on built-in wait
** Changed in: bash (Ubuntu Cosmic) Importance: Undecided => High ** Changed in: bash (Ubuntu Cosmic) Assignee: (unassigned) => Bryce Harrington (bryce) ** Changed in: bash (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bash in Ubuntu. https://bugs.launchpad.net/bugs/1822776 Title: Apply Bash 4.4.20 to fix cpu spinning on built-in wait Status in bash package in Ubuntu: Fix Released Status in bash source package in Bionic: New Status in bash source package in Cosmic: New Bug description: [Impact] Long running bash loops that create and reap processes will crash, hanging at 100% CPU. [Test Case] Run this loop for a few days/weeks: #!/bin/bash while true; do sleep 0.5 & wait done It will eventually cause the 'wait' statement to hang, consuming 100% after some indeterminate amount of time, dependent on how fast PIDs are cycled in the machine. The Bash bug report mentions longer running loops, but it seems hash collisions are the cause, meaning it's just a matter of chance, influenced by how fast PIDs are cycled on the machine. [Regression Potential] The fix has been reviewed and accepted upstream. The patch adds a test at time of pid determination for if the pid is already in use and if so, skip it and pick a different one. This does change behavior slightly in that different pid numbers will be generated in rare cases, but nothing should depend on how pids are generated, as the behavior is not specified to be anything but random. The patch adds a new warning message, "bgp_delete: LOOP: psi (%d) == storage[psi].bucket_next", but this only shows when the original bug would have been triggered. Using 'apt-get source bash' to get the original source version, I created a deb that includes the 4.4.20 patch and have been running it since April 2nd. The 100% CPU spinning is solved, and no other regressions have been observed. Ubuntu 18.04 is already at 4.4.19, which is one patch level behind, so this involves linearly progressing to the next version (so not skipping patches). [Fix] Official patch to fix, and to bump to 4.4.20: http://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 The newest Ubuntu tar.xz with patches I could find at: http://archive.ubuntu.com/ubuntu/pool/main/b/bash/ also didn't have the 4.4.20 patch, so it seems no Ubuntu release has the fix yet. Although not completely sure, this problem seems to have been introduced in the 4.4 version of Bash, so in term of LTS versions, 18.04 and up are affected. [Original Report] Bash pre-4.4.20 has a bug in its PID hash table that causes spin-loops when spawning sub processes and waiting for them. There is a fix: https://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 Our application started being affected (locking up) by this since migrating from Ubuntu 14.04 to 18.04. Ubuntu 14.04 has bash 4.3.11(1), Ubuntu 18.04 has bash 4.4.19 (that is, when running 'bash --version', because of their unusual versions as patches, apt shows it as 4.4.18-2ubuntu1). The 4.4-020 version needs to be included. I think it's actually quite critical. A justification for including the fix would be that a standard language feature in a script language is broken, and that it's indeterminate when it breaks. Considering the wide spread use of bash, I'm surprised not more people have reported issues. My and a client started having issues with independently of each other very soon after upgrading to an affected version. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1822776/+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 1822776] Re: Apply Bash 4.4.20 to fix cpu spinning on built-in wait
Hi halfgaar, Robie asked me to help you with this bug, thanks for reporting it. I may not be able to get full attention on this until next week due to a project deadline, but I've had a quick look at the patch and your problem description, and it looks pretty straightforward. Thanks also for the test case, I'll run it and see if I can repro the bug myself. It looks like both bionic and cosmic are running 4.4.18-x, so I'm gathering cosmic will need the fix as well. disco and eoan have moved to bash 5.0, and I've verified the upstream source code includes the fix, so no changes are needed for those distro releases. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bash in Ubuntu. https://bugs.launchpad.net/bugs/1822776 Title: Apply Bash 4.4.20 to fix cpu spinning on built-in wait Status in bash package in Ubuntu: New Status in bash source package in Bionic: New Status in bash source package in Cosmic: New Bug description: [Impact] Long running bash loops that create and reap processes will crash, hanging at 100% CPU. [Test Case] Run this loop for a few days/weeks: #!/bin/bash while true; do sleep 0.5 & wait done It will eventually cause the 'wait' statement to hang, consuming 100% after some indeterminate amount of time, dependent on how fast PIDs are cycled in the machine. The Bash bug report mentions longer running loops, but it seems hash collisions are the cause, meaning it's just a matter of chance, influenced by how fast PIDs are cycled on the machine. [Regression Potential] The fix has been reviewed and accepted upstream. The patch adds a test at time of pid determination for if the pid is already in use and if so, skip it and pick a different one. This does change behavior slightly in that different pid numbers will be generated in rare cases, but nothing should depend on how pids are generated, as the behavior is not specified to be anything but random. The patch adds a new warning message, "bgp_delete: LOOP: psi (%d) == storage[psi].bucket_next", but this only shows when the original bug would have been triggered. Using 'apt-get source bash' to get the original source version, I created a deb that includes the 4.4.20 patch and have been running it since April 2nd. The 100% CPU spinning is solved, and no other regressions have been observed. Ubuntu 18.04 is already at 4.4.19, which is one patch level behind, so this involves linearly progressing to the next version (so not skipping patches). [Fix] Official patch to fix, and to bump to 4.4.20: http://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 The newest Ubuntu tar.xz with patches I could find at: http://archive.ubuntu.com/ubuntu/pool/main/b/bash/ also didn't have the 4.4.20 patch, so it seems no Ubuntu release has the fix yet. Although not completely sure, this problem seems to have been introduced in the 4.4 version of Bash, so in term of LTS versions, 18.04 and up are affected. [Original Report] Bash pre-4.4.20 has a bug in its PID hash table that causes spin-loops when spawning sub processes and waiting for them. There is a fix: https://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 Our application started being affected (locking up) by this since migrating from Ubuntu 14.04 to 18.04. Ubuntu 14.04 has bash 4.3.11(1), Ubuntu 18.04 has bash 4.4.19 (that is, when running 'bash --version', because of their unusual versions as patches, apt shows it as 4.4.18-2ubuntu1). The 4.4-020 version needs to be included. I think it's actually quite critical. A justification for including the fix would be that a standard language feature in a script language is broken, and that it's indeterminate when it breaks. Considering the wide spread use of bash, I'm surprised not more people have reported issues. My and a client started having issues with independently of each other very soon after upgrading to an affected version. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1822776/+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 1822776] Re: Apply Bash 4.4.20 to fix cpu spinning on built-in wait
** Description changed: - Bash pre-4.4.20 has a bug in its PID hash table that causes spin-loops - when spawning sub processes and waiting for them. There is a fix: + [Impact] - https://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 + Long running bash loops that create and reap processes will crash, + hanging at 100% CPU. - Our application started being affected (locking up) by this since - migrating from Ubuntu 14.04 to 18.04. Ubuntu 14.04 has bash 4.3.11(1), - Ubuntu 18.04 has bash 4.4.19 (that is, when running 'bash --version', - because of their unusual versions as patches, apt shows it as - 4.4.18-2ubuntu1). - The 4.4-020 version needs to be included. I think it's actually quite - critical. + [Test Case] + + Run this loop for a few days/weeks: + + #!/bin/bash + while true; do + sleep 0.5 & + wait + done + + It will eventually cause the 'wait' statement to hang, consuming 100% + after some indeterminate amount of time, dependent on how fast PIDs are + cycled in the machine. The Bash bug report mentions longer running loops, but it seems hash collisions are the cause, meaning it's just a matter of chance, influenced by how fast PIDs are cycled on the machine. - Edit as per the SRU procedure: -[Impact] + [Regression Potential] - Long running bash loops that create and reap processes will crash, - hanging at 100% CPU. + The fix has been reviewed and accepted upstream. The patch adds a test + at time of pid determination for if the pid is already in use and if so, + skip it and pick a different one. This does change behavior slightly in + that different pid numbers will be generated in rare cases, but nothing + should depend on how pids are generated, as the behavior is not + specified to be anything but random. - A justification for including the fix would be that a standard language - feature in a script language is broken, and that it's indeterminate when - it breaks. Considering the wide spread use of bash, I'm surprised not - more people have reported issues. My and a client started having issues - with independently of each other very soon after upgrading to an - affected version. - -[Test Case] - - Run this loop for a few days/weeks: - - #!/bin/bash - while true; do - sleep 0.5 & - wait - done - - - It will cause the 'wait' statement to hang, consuming 100% after some indeterminate amount of time, dependent on how fast PIDs are cycled in the machine. - -[Regression Potential] + The patch adds a new warning message, "bgp_delete: LOOP: psi (%d) == + storage[psi].bucket_next", but this only shows when the original bug + would have been triggered. Using 'apt-get source bash' to get the original source version, I created a deb that includes the 4.4.20 patch and have been running it since April 2nd. The 100% CPU spinning is solved, and no other regressions have been observed. Ubuntu 18.04 is already at 4.4.19, which is one patch level behind, so this involves linearly progressing to the next version (so not skipping patches). -[Other Info] + + [Fix] Official patch to fix, and to bump to 4.4.20: http://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 The newest Ubuntu tar.xz with patches I could find at: http://archive.ubuntu.com/ubuntu/pool/main/b/bash/ also didn't have the 4.4.20 patch, so it seems no Ubuntu release has the fix yet. Although not completely sure, this problem seems to have been introduced in the 4.4 version of Bash, so in term of LTS versions, 18.04 and up are affected. + + + [Original Report] + Bash pre-4.4.20 has a bug in its PID hash table that causes spin-loops when spawning sub processes and waiting for them. There is a fix: + + https://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 + + Our application started being affected (locking up) by this since + migrating from Ubuntu 14.04 to 18.04. Ubuntu 14.04 has bash 4.3.11(1), + Ubuntu 18.04 has bash 4.4.19 (that is, when running 'bash --version', + because of their unusual versions as patches, apt shows it as + 4.4.18-2ubuntu1). + + The 4.4-020 version needs to be included. I think it's actually quite + critical. + + A justification for including the fix would be that a standard language + feature in a script language is broken, and that it's indeterminate when + it breaks. Considering the wide spread use of bash, I'm surprised not + more people have reported issues. My and a client started having issues + with independently of each other very soon after upgrading to an + affected version. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bash in Ubuntu. https://bugs.launchpad.net/bugs/1822776 Title: Apply Bash 4.4.20 to fix cpu spinning on built-in wait Status in bash package in Ubuntu: New Status in bash source package in Bionic: New Status in bash source package in Cosmic: New
[Touch-packages] [Bug 1822776] Re: Apply Bash 4.4.20 to fix cpu spinning on built-in wait
** Also affects: bash (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: bash (Ubuntu Bionic) Importance: Undecided => High ** Changed in: bash (Ubuntu Bionic) Assignee: (unassigned) => Bryce Harrington (bryce) ** Also affects: bash (Ubuntu Cosmic) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bash in Ubuntu. https://bugs.launchpad.net/bugs/1822776 Title: Apply Bash 4.4.20 to fix cpu spinning on built-in wait Status in bash package in Ubuntu: New Status in bash source package in Bionic: New Status in bash source package in Cosmic: New Bug description: Bash pre-4.4.20 has a bug in its PID hash table that causes spin-loops when spawning sub processes and waiting for them. There is a fix: https://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 Our application started being affected (locking up) by this since migrating from Ubuntu 14.04 to 18.04. Ubuntu 14.04 has bash 4.3.11(1), Ubuntu 18.04 has bash 4.4.19 (that is, when running 'bash --version', because of their unusual versions as patches, apt shows it as 4.4.18-2ubuntu1). The 4.4-020 version needs to be included. I think it's actually quite critical. The Bash bug report mentions longer running loops, but it seems hash collisions are the cause, meaning it's just a matter of chance, influenced by how fast PIDs are cycled on the machine. Edit as per the SRU procedure: [Impact] Long running bash loops that create and reap processes will crash, hanging at 100% CPU. A justification for including the fix would be that a standard language feature in a script language is broken, and that it's indeterminate when it breaks. Considering the wide spread use of bash, I'm surprised not more people have reported issues. My and a client started having issues with independently of each other very soon after upgrading to an affected version. [Test Case] Run this loop for a few days/weeks: #!/bin/bash while true; do sleep 0.5 & wait done It will cause the 'wait' statement to hang, consuming 100% after some indeterminate amount of time, dependent on how fast PIDs are cycled in the machine. [Regression Potential] Using 'apt-get source bash' to get the original source version, I created a deb that includes the 4.4.20 patch and have been running it since April 2nd. The 100% CPU spinning is solved, and no other regressions have been observed. Ubuntu 18.04 is already at 4.4.19, which is one patch level behind, so this involves linearly progressing to the next version (so not skipping patches). [Other Info] Official patch to fix, and to bump to 4.4.20: http://ftp.gnu.org/gnu/bash/bash-4.4-patches/bash44-020 The newest Ubuntu tar.xz with patches I could find at: http://archive.ubuntu.com/ubuntu/pool/main/b/bash/ also didn't have the 4.4.20 patch, so it seems no Ubuntu release has the fix yet. Although not completely sure, this problem seems to have been introduced in the 4.4 version of Bash, so in term of LTS versions, 18.04 and up are affected. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1822776/+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 1371403] Re: [PATCH] Please disable USB autosuspend for Avocent SC Secure KVM
** Changed in: systemd (Ubuntu Trusty)
Status: In Progress => Confirmed
--
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/1371403
Title:
[PATCH] Please disable USB autosuspend for Avocent SC Secure KVM
Status in systemd package in Ubuntu:
Invalid
Status in systemd source package in Trusty:
Confirmed
Status in systemd source package in Utopic:
Won't Fix
Bug description:
My mouse becomes temporarily become unresponsive to drags and clicks,
until I right-click or give keyboard input, when it's been idle for a
few seconds. The same thing affects the keyboard. In some cases the
mouse cursor jumps back to the center of the screen.
The mouse and keyboard are connected to a number of different
computers via an 8-port Avocent SC Secure KVM. When the mouse and/or
keyboard are directly attached to one of the PCs, there is no problem.
I've tested with different keyboards and mice as well, and they're
similarly messed up.
Only the computers running Ubuntu 14.04 are affected. Two of the computers
are identical hardware, differing only in Ubuntu versions - the 14.04 one is
affected but the one with 13.04 is not. I also have a machine with 12.04 on it
connected to the KVM which is fine.
I first noticed the problem when I upgraded to 13.10.
In powertop I notice that autosuspend is enabled for the Avocent. If
I switch that off, then the problem disappears completely. I can also
prevent it by issuing:
echo 'on' > '/sys/bus/usb/devices/3-10/power/control';
where 3-10 is the Avocent (the number is different on each of my
systems).
I notice in 42-usb-hid-pm.rules there is a rule for Avocent devices:
# Catch-all for Avocent HID devices. Keyed off interface in order to only
# trigger on HID class devices.
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0624",
ATTR{bInterfaceClass}=="03", TEST=="../power/control",
ATTR{../power/control}="auto"
However my KVM device doesn't appear to have a bInterfaceClass
defined.
In any case, the following udev rule corrects the problem for me:
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0624",
ATTR{idProduct}=="0013", ATTR{product}=="SC Secure KVM",
TEST=="power/control", ATTR{power/control}:="on"
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1371403/+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 1371403] Re: [PATCH] Please disable USB autosuspend for Avocent SC Secure KVM
See #17 for where this is stuck.
--
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/1371403
Title:
[PATCH] Please disable USB autosuspend for Avocent SC Secure KVM
Status in systemd package in Ubuntu:
Invalid
Status in systemd source package in Trusty:
In Progress
Status in systemd source package in Utopic:
Won't Fix
Bug description:
My mouse becomes temporarily become unresponsive to drags and clicks,
until I right-click or give keyboard input, when it's been idle for a
few seconds. The same thing affects the keyboard. In some cases the
mouse cursor jumps back to the center of the screen.
The mouse and keyboard are connected to a number of different
computers via an 8-port Avocent SC Secure KVM. When the mouse and/or
keyboard are directly attached to one of the PCs, there is no problem.
I've tested with different keyboards and mice as well, and they're
similarly messed up.
Only the computers running Ubuntu 14.04 are affected. Two of the computers
are identical hardware, differing only in Ubuntu versions - the 14.04 one is
affected but the one with 13.04 is not. I also have a machine with 12.04 on it
connected to the KVM which is fine.
I first noticed the problem when I upgraded to 13.10.
In powertop I notice that autosuspend is enabled for the Avocent. If
I switch that off, then the problem disappears completely. I can also
prevent it by issuing:
echo 'on' > '/sys/bus/usb/devices/3-10/power/control';
where 3-10 is the Avocent (the number is different on each of my
systems).
I notice in 42-usb-hid-pm.rules there is a rule for Avocent devices:
# Catch-all for Avocent HID devices. Keyed off interface in order to only
# trigger on HID class devices.
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0624",
ATTR{bInterfaceClass}=="03", TEST=="../power/control",
ATTR{../power/control}="auto"
However my KVM device doesn't appear to have a bInterfaceClass
defined.
In any case, the following udev rule corrects the problem for me:
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0624",
ATTR{idProduct}=="0013", ATTR{product}=="SC Secure KVM",
TEST=="power/control", ATTR{power/control}:="on"
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1371403/+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 1371403] Re: [PATCH] Please disable USB autosuspend for Avocent SC Secure KVM
Hrm, well with the := changed to =, the rule doesn't seem to be working.
(I guess it's the := change; I suppose there could be another error
somewhere...)
blackwold:~$ sudo ./disable_avocent_autosuspend
[sudo] password for bryce:
/sys/bus/usb/devices/3-13 on
/sys/bus/usb/devices/3-14 SC Secure KVM auto
/sys/bus/usb/devices/3-3 Perfection1240 on
/sys/bus/usb/devices/3-4 USB Modem on
/sys/bus/usb/devices/4-2 PRO57U SSon
/sys/bus/usb/devices/usb1 EHCI Host Controller auto
/sys/bus/usb/devices/usb2 EHCI Host Controller auto
/sys/bus/usb/devices/usb3 xHCI Host Controller auto
/sys/bus/usb/devices/usb4 xHCI Host Controller auto
--- (setting to auto)
/sys/bus/usb/devices/3-13 on
/sys/bus/usb/devices/3-14 SC Secure KVM auto
/sys/bus/usb/devices/3-3 Perfection1240 on
/sys/bus/usb/devices/3-4 USB Modem on
/sys/bus/usb/devices/4-2 PRO57U SSon
/sys/bus/usb/devices/usb1 EHCI Host Controller auto
/sys/bus/usb/devices/usb2 EHCI Host Controller auto
/sys/bus/usb/devices/usb3 xHCI Host Controller auto
/sys/bus/usb/devices/usb4 xHCI Host Controller auto
--- (applying udev rule)
/sys/bus/usb/devices/3-13 on
/sys/bus/usb/devices/3-14 SC Secure KVM auto
/sys/bus/usb/devices/3-3 Perfection1240 on
/sys/bus/usb/devices/3-4 USB Modem on
/sys/bus/usb/devices/4-2 PRO57U SSon
/sys/bus/usb/devices/usb1 EHCI Host Controller auto
/sys/bus/usb/devices/usb2 EHCI Host Controller auto
/sys/bus/usb/devices/usb3 xHCI Host Controller auto
/sys/bus/usb/devices/usb4 xHCI Host Controller auto
--- (forcing to on)
/sys/bus/usb/devices/3-13 on
/sys/bus/usb/devices/3-14 SC Secure KVM on
/sys/bus/usb/devices/3-3 Perfection1240 on
/sys/bus/usb/devices/3-4 USB Modem on
/sys/bus/usb/devices/4-2 PRO57U SSon
/sys/bus/usb/devices/usb1 EHCI Host Controller auto
/sys/bus/usb/devices/usb2 EHCI Host Controller auto
/sys/bus/usb/devices/usb3 xHCI Host Controller auto
/sys/bus/usb/devices/usb4 xHCI Host Controller auto
blackwold:~$ apt-cache policy udev
udev:
Installed: 204-5ubuntu20.17
Candidate: 204-5ubuntu20.17
Version table:
*** 204-5ubuntu20.17 0
500 http://us.archive.ubuntu.com/ubuntu/ trusty-proposed/main amd64
Packages
100 /var/lib/dpkg/status
204-5ubuntu20.15 0
500 http://us.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64
Packages
204-5ubuntu20 0
500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
Not really certain where to go from here... :-/
--
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/1371403
Title:
[PATCH] Please disable USB autosuspend for Avocent SC Secure KVM
Status in systemd package in Ubuntu:
Invalid
Status in systemd source package in Trusty:
In Progress
Status in systemd source package in Utopic:
Won't Fix
Bug description:
My mouse becomes temporarily become unresponsive to drags and clicks,
until I right-click or give keyboard input, when it's been idle for a
few seconds. The same thing affects the keyboard. In some cases the
mouse cursor jumps back to the center of the screen.
The mouse and keyboard are connected to a number of different
computers via an 8-port Avocent SC Secure KVM. When the mouse and/or
keyboard are directly attached to one of the PCs, there is no problem.
I've tested with different keyboards and mice as well, and they're
similarly messed up.
Only the computers running Ubuntu 14.04 are affected. Two of the computers
are identical hardware, differing only in Ubuntu versions - the 14.04 one is
affected but the one with 13.04 is not. I also have a machine with 12.04 on it
connected to the KVM which is fine.
I first noticed the problem when I upgraded to 13.10.
In powertop I notice that autosuspend is enabled for the Avocent. If
I switch that off, then the problem disappears completely. I can also
prevent it by issuing:
echo 'on' > '/sys/bus/usb/devices/3-10/power/control';
where 3-10 is the Avocent (the number is different on each of my
systems).
I notice in 42-usb-hid-pm.rules there is a rule for Avocent devices:
# Catch-all for Avocent HID devices. Keyed off interface in order to only
# trigger on HID class devices.
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0624",
ATTR{bInterfaceClass}=="03", TEST=="../power/control",
ATTR{../power/control}="auto"
However my KVM device doesn't appear to have a bInterfaceClass
defined.
In any case, the following udev rule corrects the problem for me:
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0624",
ATTR{idProduct}=="0013", ATTR{product}=="SC Secure KVM",
TEST=="power/control", ATTR{power/control}:="on"
To manage notifications about this bug go to:
[Touch-packages] [Bug 1371403] Re: [PATCH] Please disable USB autosuspend for Avocent SC Secure KVM
While the rules seem to work fine, apparently the syntax checker in the
packaging scripts don't like the use of := for assignment, so I've
change that to just =. I think that should also work fine, but will
test once the package actually is built.
** Tags removed: verification-needed
** Changed in: systemd (Ubuntu Trusty)
Status: Fix Committed => 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/1371403
Title:
[PATCH] Please disable USB autosuspend for Avocent SC Secure KVM
Status in systemd package in Ubuntu:
Invalid
Status in systemd source package in Trusty:
In Progress
Status in systemd source package in Utopic:
Won't Fix
Bug description:
My mouse becomes temporarily become unresponsive to drags and clicks,
until I right-click or give keyboard input, when it's been idle for a
few seconds. The same thing affects the keyboard. In some cases the
mouse cursor jumps back to the center of the screen.
The mouse and keyboard are connected to a number of different
computers via an 8-port Avocent SC Secure KVM. When the mouse and/or
keyboard are directly attached to one of the PCs, there is no problem.
I've tested with different keyboards and mice as well, and they're
similarly messed up.
Only the computers running Ubuntu 14.04 are affected. Two of the computers
are identical hardware, differing only in Ubuntu versions - the 14.04 one is
affected but the one with 13.04 is not. I also have a machine with 12.04 on it
connected to the KVM which is fine.
I first noticed the problem when I upgraded to 13.10.
In powertop I notice that autosuspend is enabled for the Avocent. If
I switch that off, then the problem disappears completely. I can also
prevent it by issuing:
echo 'on' > '/sys/bus/usb/devices/3-10/power/control';
where 3-10 is the Avocent (the number is different on each of my
systems).
I notice in 42-usb-hid-pm.rules there is a rule for Avocent devices:
# Catch-all for Avocent HID devices. Keyed off interface in order to only
# trigger on HID class devices.
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0624",
ATTR{bInterfaceClass}=="03", TEST=="../power/control",
ATTR{../power/control}="auto"
However my KVM device doesn't appear to have a bInterfaceClass
defined.
In any case, the following udev rule corrects the problem for me:
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0624",
ATTR{idProduct}=="0013", ATTR{product}=="SC Secure KVM",
TEST=="power/control", ATTR{power/control}:="on"
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1371403/+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 1371403] Re: [PATCH] Please disable USB autosuspend for Avocent SC Secure KVM
** Changed in: systemd (Ubuntu Trusty)
Status: Triaged => 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/1371403
Title:
[PATCH] Please disable USB autosuspend for Avocent SC Secure KVM
Status in systemd package in Ubuntu:
Invalid
Status in systemd source package in Trusty:
In Progress
Status in systemd source package in Utopic:
Won't Fix
Bug description:
My mouse becomes temporarily become unresponsive to drags and clicks,
until I right-click or give keyboard input, when it's been idle for a
few seconds. The same thing affects the keyboard. In some cases the
mouse cursor jumps back to the center of the screen.
The mouse and keyboard are connected to a number of different
computers via an 8-port Avocent SC Secure KVM. When the mouse and/or
keyboard are directly attached to one of the PCs, there is no problem.
I've tested with different keyboards and mice as well, and they're
similarly messed up.
Only the computers running Ubuntu 14.04 are affected. Two of the computers
are identical hardware, differing only in Ubuntu versions - the 14.04 one is
affected but the one with 13.04 is not. I also have a machine with 12.04 on it
connected to the KVM which is fine.
I first noticed the problem when I upgraded to 13.10.
In powertop I notice that autosuspend is enabled for the Avocent. If
I switch that off, then the problem disappears completely. I can also
prevent it by issuing:
echo 'on' > '/sys/bus/usb/devices/3-10/power/control';
where 3-10 is the Avocent (the number is different on each of my
systems).
I notice in 42-usb-hid-pm.rules there is a rule for Avocent devices:
# Catch-all for Avocent HID devices. Keyed off interface in order to only
# trigger on HID class devices.
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0624",
ATTR{bInterfaceClass}=="03", TEST=="../power/control",
ATTR{../power/control}="auto"
However my KVM device doesn't appear to have a bInterfaceClass
defined.
In any case, the following udev rule corrects the problem for me:
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0624",
ATTR{idProduct}=="0013", ATTR{product}=="SC Secure KVM",
TEST=="power/control", ATTR{power/control}:="on"
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1371403/+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 1255610] Re: 100% CPU usage with initctl emit plymouth-ready process
Possibly dupe with #1173915?
I too am seeing 100% cpu on initctl, after a nearly three month uptime
on 14.04:
Linux dorset.bryceharrington.org 3.13.0-35-generic #62-Ubuntu SMP Fri
Aug 15 01:58:42 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
# cat /proc/1327/stack
[] 0x
# uptime
17:24:15 up 87 days, 13:54, 9 users, load average: 1.00, 1.01, 1.05
# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 14.04.1 LTS
Release:14.04
Codename: trusty
# ls -l /proc/1327/fd
total 0
lrwx-- 1 root root 64 Feb 11 02:39 0 - /dev/null
lrwx-- 1 root root 64 Feb 11 02:39 1 - /dev/pts/24
lrwx-- 1 root root 64 Feb 11 02:39 2 - /dev/pts/24
lrwx-- 1 root root 64 Feb 11 02:39 3 - socket:[9674]
# lsof | grep 9674
lsof: WARNING: can't stat() nfs4 file system /srv/Backup
Output information may be incomplete.
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
Output information may be incomplete.
initctl1327 root3u unix 0x8807ef6f2680 0t0
9674 socket
# strace -p 9674
...
poll([{fd=3, events=POLLIN}], 1, 1023162120) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 1023162112) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 1023162103) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 1023162095) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 1023162087) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 1023162078) = 1 ([{fd=3, revents=POLLIN}])
poll([{fd=3, events=POLLIN}], 1, 1023162070) = 1 ([{fd=3, revents=POLLIN}])
...
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to upstart in Ubuntu.
https://bugs.launchpad.net/bugs/1255610
Title:
100% CPU usage with initctl emit plymouth-ready process
Status in upstart package in Ubuntu:
Confirmed
Bug description:
root 977 99.1 2.7 98668 93964 ?R12:59 453:31
initctl emit plymouth-ready
this makes my CPU very hot, I don't know how to debug deeper. Any
ideas?
ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: upstart 1.10-0ubuntu7
ProcVersionSignature: Ubuntu 3.11.0-13.20-generic 3.11.6
Uname: Linux 3.11.0-13-generic i686
NonfreeKernelModules: nvidia
ApportVersion: 2.12.5-0ubuntu2.1
Architecture: i386
Date: Wed Nov 27 20:46:04 2013
InstallationDate: Installed on 2012-03-12 (625 days ago)
InstallationMedia: Ubuntu 12.04 LTS Precise Pangolin - Beta i386 (20120301)
MarkForUpload: True
ProcKernelCmdline: BOOT_IMAGE=/boot/vmlinuz-3.11.0-13-generic
root=UUID=d0d8bf63-cf4c-479f-9091-1f14156a902f ro quiet splash
SourcePackage: upstart
UpgradeStatus: Upgraded to saucy on 2013-10-21 (37 days ago)
UpstartBugCategory: System
UpstartRunningSessionVersion: init (upstart 1.10)
UpstartRunningSystemVersion: init (upstart 1.10)
modified.conffile..etc.at.deny: [inaccessible: [Errno 13] Permission denied:
'/etc/at.deny']
modified.conffile..etc.init.d.networking: [modified]
mtime.conffile..etc.init.d.networking: 2013-08-27T01:19:11
upstart.upstart-file-bridge.log:
Job got added /com/ubuntu/Upstart/jobs/unicast_2dlocal_2davahi
Job got added /com/ubuntu/Upstart/jobs/update_2dnotifier_2dcrash
Job got added /com/ubuntu/Upstart/jobs/update_2dnotifier_2drelease
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1255610/+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 973932] Re: Disabling 'below' display does not reposition windows properly
Ayup. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unity in Ubuntu. https://bugs.launchpad.net/bugs/973932 Title: Disabling 'below' display does not reposition windows properly Status in Unity: Incomplete Status in unity package in Ubuntu: Incomplete Bug description: [Problem] In a multihead config with one monitor above the other, if the lower monitor is disabled the windows on that screen aren't moved to the still-active display. [Test Case] 0. Attach laptop (LVDS1) to an external display (VGA1). 1. In the GNOME display properties applet, set the LVDS1 beneath VGA1. 2. Move to the lower left desktop (ctrl+alt+down) 3. Open one gnome terminal window on each monitor. 4. In the upper (VGA1) gnome terminal window type: xrandr --output LVDS1 --off (Alternatively, bring up the gnome display properties applet and shut the laptop display off there) 5. With the LVDS turned off, count the number of gnome terminal windows visible on VGA1 6. Using either xrandr or gnome, re-enable LVDS1 to the above/below arrangement 7. With the LVDS re-enabled, count the number of gnome terminals visible on VGA1 and LVDS1 Expected: 2, then 1/1 Actual: Gnome Classic (No Effects): 2, then 1/1 Gnome Classic (With Effects): 2, then 1/1 Unity2D: 2, then 1/1 Unity: 1, then 1/1 Other findings... A. On Unity, with LVDS1 off the missing gnome terminal window is inaccessible. It can be recovered in various ways, but it's fairly confusing. B. If step #2 is skipped and the test performed in the upper left desktop, Unity will place the lower windows into the lower left desktop. C. On Unity, repeated testing of this seems to scramble the window positions to some extent. The same effect does not appear to occur with metacity; windows generally get placed back where they'd been before. ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: unity 5.8.0-0ubuntu2 ProcVersionSignature: Ubuntu 3.2.0-22.35-generic 3.2.14 Uname: Linux 3.2.0-22-generic i686 ApportVersion: 2.0-0ubuntu4 Architecture: i386 CompizPlugins: [core,composite,opengl,compiztoolbox,decor,vpswitch,snap,mousepoll,resize,place,move,wall,grid,regex,imgpng,session,gnomecompat,animation,fade,workarounds,scale,expo,ezoom] Date: Thu Apr 5 05:27:33 2012 InstallationMedia: Ubuntu 11.10 Oneiric Ocelot - Beta i386 (20110921.2) SourcePackage: unity UpgradeStatus: Upgraded to precise on 2011-11-22 (135 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/unity/+bug/973932/+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 1360606] Re: libcairo.so for Ubuntu 14.04 is dead-slow compared to Ubuntu 13.10
Thanks peter and chris, sounds like the issue is resolved so I'll close the bug as suggested. ** Changed in: cairo (Ubuntu) Status: New = Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cairo in Ubuntu. https://bugs.launchpad.net/bugs/1360606 Title: libcairo.so for Ubuntu 14.04 is dead-slow compared to Ubuntu 13.10 Status in “cairo” package in Ubuntu: Fix Released Bug description: I'm running the video mixer software called Snowmix that uses libcairo extensively. After updating to Ubuntu 14.04 Desktop amd64, I noticed that mixing video required 8 times more CPU compared to Ubuntu 13.10. Using oprofile I discovered the heavy CPU load was taking place in libpixman used by libcairo. However libpixman is currently the same release in Ubuntu 14.04 and 13.10. However I did notice that libcairo got upgraded from libcairo.so.2.11200.16 in Ubuntu 13.10 to libcairo.so.2.11301.0 in Uuntu 14.04. Snowmix uses libcairo2 primarily for scaling and rotating images and overlay them in memory. Replacing libcairo.so.2.11301.0 with libcairo.so.2.11200.16 in Ubuntu 14.04 lower the CPU usage by at least 8 times. So I suspect that libcairo for Ubuntu 14.04 somehow got compiled without the hardware acceleration such as MMX/SSE2/SSE3 etc. This is quite bad if this is the case. If it is not the case, something else is seriously wrong with libcairo2. 1)Description:Ubuntu 14.04.1 LTS Release:14.04 2) libcairo2: Installed: 1.13.0~20140204-0ubuntu1 Candidate: 1.13.0~20140204-0ubuntu1 Version table: *** 1.13.0~20140204-0ubuntu1 0 500 http://dk.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages 100 /var/lib/dpkg/status 3) I expected libcairo2 (libcairo.so.2.11301.0) for Ubuntu14.04 to work as efficient as libcairo2 (libcairo.so.2.11200.16)for Ubuntu13.10. 4) Libcairo2 for Ubuntu 14.04 works 8 times slower indicating a lack of MMX/SSE2/SSE3 etc acceleration. For the source, you have the source for libcairo2 for Ubuntu14.04. I can provide you with the source code for Snowmix using libcairo2, but I don't expected you need it nor want it. Best regards Peter Maersk-Moller ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: libcairo2 1.13.0~20140204-0ubuntu1 ProcVersionSignature: Ubuntu 3.13.0-34.60-generic 3.13.11.4 Uname: Linux 3.13.0-34-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.3 Architecture: amd64 Date: Sat Aug 23 15:23:38 2014 InstallationDate: Installed on 2013-06-21 (428 days ago) InstallationMedia: Ubuntu 12.04.2 LTS Precise Pangolin - Release amd64 (20130213) ProcEnviron: LANGUAGE=en_US:en TERM=xterm PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: cairo UpgradeStatus: Upgraded to trusty on 2014-08-20 (3 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/1360606/+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
