[Touch-packages] [Bug 1965673] Re: Object 0x... of type IBusText has been finalized while it was still owned by gjs, this is due to invalid memory management
Sounds like https://github.com/ibus/ibus/pull/2394 might fix the issue? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ibus in Ubuntu. https://bugs.launchpad.net/bugs/1965673 Title: Object 0x... of type IBusText has been finalized while it was still owned by gjs, this is due to invalid memory management Status in ibus: Unknown Status in gnome-shell package in Ubuntu: Confirmed Status in ibus package in Ubuntu: Confirmed Bug description: Ubuntu 22.04 development branch @ 20/03/2022 Journal logs spam a lot of lines like these: mrt 20 13:36:38 R00TB00K gnome-shell[3452]: Object 0x7f896cf7cad0 of type IBusText has been finalized while it was still owned by gjs, this is due to invalid memory management. mrt 20 13:36:38 R00TB00K gnome-shell[3452]: Object 0x557a992efd20 of type IBusText has been finalized while it was still owned by gjs, this is due to invalid memory management Probably regression bug upstream: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5147 ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: gnome-shell 42~beta-1ubuntu2 ProcVersionSignature: Ubuntu 5.15.0-22.22-generic 5.15.19 Uname: Linux 5.15.0-22-generic x86_64 ApportVersion: 2.20.11-0ubuntu79 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Sun Mar 20 13:34:37 2022 DisplayManager: gdm3 RelatedPackageVersions: mutter-common 42~beta-1ubuntu2 SourcePackage: gnome-shell UpgradeStatus: No upgrade log present (probably fresh install) mtime.conffile..etc.xdg.autostart.gnome-shell-overrides-migration.desktop: 2021-10-23T19:12:47.175230 To manage notifications about this bug go to: https://bugs.launchpad.net/ibus/+bug/1965673/+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 1953052] Re: In Jammy sound level reset after reboot
So I can confirm that copying /usr/share/pipewire/media-session.conf to /etc/pipewire/media-session.d/media-session.conf and deleting these lines fixes the issue: $ diff /etc/pipewire/media-session.d/media-session.conf /usr/share/pipewire/media-session.d/media-session.conf 94a95,116 > with-audio = [ > metadata > default-nodes > default-profile > default-routes > alsa-seq > alsa-monitor > ] > with-alsa = [ > with-audio > ] > with-jack = [ > with-audio > ] > with-pulseaudio = [ > with-audio > bluez5 > bluez5-autoswitch > logind > restore-stream > streams-follow-default > ] -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1953052 Title: In Jammy sound level reset after reboot Status in alsa-utils package in Ubuntu: Confirmed Status in pipewire package in Ubuntu: Confirmed Status in pulseaudio package in Ubuntu: Confirmed Bug description: After reboot sound level is reset ignoring the level set in previous session. I manually set the sound output level at next boot the sound is set at a different level (about 70%) Expected: the sound level is persistent across power off/on What happens : sound level is set at a different level (about 70%) Note: this problem does not occur on different partitions of same PC running Ubuntu 20.04 or 21.10 corrado@corrado-p3-jj-1130:~$ apt policy gnome-control-center gnome-control-center: Installed: 1:41.1-1ubuntu1 Candidate: 1:41.1-1ubuntu1 Version table: *** 1:41.1-1ubuntu1 500 500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages 100 /var/lib/dpkg/status corrado@corrado-p3-jj-1130:~$ inxi -Fx System:Host: corrado-p3-jj-1130 Kernel: 5.13.0-19-generic x86_64 bits: 64 compiler: gcc v: 11.2.0 Desktop: GNOME 40.5 Distro: Ubuntu 22.04 (Jammy Jellyfish) Machine: Type: Laptop System: Dell product: Inspiron 3793 v: N/A serial: Mobo: Dell model: 0C1PF2 v: A00 serial: UEFI: Dell v: 1.5.0 date: 12/17/2019 Battery: ID-1: BAT0 charge: 13.9 Wh (42.1%) condition: 33.0/42.0 Wh (78.7%) volts: 11.3 min: 11.4 model: SWD-ATL3.618 DELL WJPC403 status: Discharging CPU: Info: Quad Core model: Intel Core i5-1035G1 bits: 64 type: MT MCP arch: Ice Lake rev: 5 cache: L2: 6 MiB flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 19046 Speed: 968 MHz min/max: 400/1000 MHz Core speeds (MHz): 1: 968 2: 710 3: 706 4: 714 5: 966 6: 712 7: 724 8: 821 Graphics: Device-1: Intel Iris Plus Graphics G1 vendor: Dell driver: i915 v: kernel bus-ID: 00:02.0 Device-2: Realtek Integrated_Webcam_HD type: USB driver: uvcvideo bus-ID: 1-6:3 Display: wayland server: X.Org 1.21.1.2 compositor: gnome-shell driver: loaded: i915 note: n/a (using device driver) resolution: 1920x1080~60Hz OpenGL: renderer: Mesa Intel UHD Graphics (ICL GT1) v: 4.6 Mesa 21.2.2 direct render: Yes Audio: Device-1: Intel Ice Lake-LP Smart Sound Audio vendor: Dell driver: snd_hda_intel v: kernel bus-ID: 00:1f.3 Sound Server-1: ALSA v: k5.13.0-19-generic running: yes Sound Server-2: PulseAudio v: 15.0 running: yes Sound Server-3: PipeWire v: 0.3.40 running: yes Network: Device-1: Realtek RTL810xE PCI Express Fast Ethernet vendor: Dell driver: r8169 v: kernel port: 3000 bus-ID: 01:00.0 IF: enp1s0 state: down mac: 98:e7:43:59:19:19 Device-2: Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter vendor: Dell driver: ath10k_pci v: kernel bus-ID: 02:00.0 IF: wlp2s0 state: up mac: d8:12:65:b8:21:b9 Bluetooth: Device-1: Qualcomm Atheros type: USB driver: btusb v: 0.8 bus-ID: 1-10:4 Report: hciconfig ID: hci0 rfk-id: 0 state: down bt-service: enabled,running rfk-block: hardware: no software: yes address: D8:12:65:B8:21:BA Drives:Local Storage: total: 942.7 GiB used: 11.77 GiB (1.2%) ID-1: /dev/nvme0n1 vendor: Toshiba model: KBG40ZNS512G NVMe KIOXIA 512GB size: 476.94 GiB temp: 24.9 C ID-2: /dev/sda vendor: Crucial model: CT500MX500SSD1 size: 465.76 GiB Partition: ID-1: / size: 46.95 GiB used: 11.73 GiB (25.0%) fs: ext4 dev: /dev/nvme0n1p3 ID-2: /boot/efi size: 246 MiB used: 46.4 MiB (18.9%) fs: vfat dev: /dev/nvme0n1p1 Swap: Alert: No swap data was found. Sensors: System Temperatures: cpu: 27.8 C mobo: N/A Fan Speeds (RPM): cpu: 0 Info: Processes: 263 Uptime: 31m Memory: 15.4 GiB used: 2.45 GiB (15.9%) Init: systemd runlevel: 5 Compilers: gcc: N/A Packages:
[Touch-packages] [Bug 1659676] Re: backport timesyncd patch for updating the RTC
Whoops, just checked the latest xenial systemd source package and mistakenly thought I saw the patch had already been pulled. Please pull this. ** Changed in: systemd (Ubuntu) Status: Fix Released => New ** Description changed: - Please backport this patch to 16.04, which should improve reliability of - timesyncd updates to the RTC: + Please backport this patch to 16.04. Sometimes hosts can boot up with + system clocks that are off by more than the NTP_MAX_ADJUST. This patch + improves reliability of timesyncd updates to the RTC: https://github.com/systemd/systemd/commit/5f36e3d30375cf04292bbc1bf3f4d7512cf80139 -- 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/1659676 Title: backport timesyncd patch for updating the RTC Status in systemd package in Ubuntu: New Bug description: Please backport this patch to 16.04. Sometimes hosts can boot up with system clocks that are off by more than the NTP_MAX_ADJUST. This patch improves reliability of timesyncd updates to the RTC: https://github.com/systemd/systemd/commit/5f36e3d30375cf04292bbc1bf3f4d7512cf80139 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1659676/+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 1659676] Re: backport timesyncd patch for updating the RTC
** Tags added: patch patch-accepted-upstream ** Changed in: systemd (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1659676 Title: backport timesyncd patch for updating the RTC Status in systemd package in Ubuntu: New Bug description: Please backport this patch to 16.04. Sometimes hosts can boot up with system clocks that are off by more than the NTP_MAX_ADJUST. This patch improves reliability of timesyncd updates to the RTC: https://github.com/systemd/systemd/commit/5f36e3d30375cf04292bbc1bf3f4d7512cf80139 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1659676/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 1668724] Re: fails to mount cgroupfs inside containers running on 16.04
I'm happy to provide a patch, but if the root cause of my issue is in lxc it may be easier to patch that than worrying about backwards compatibility for cgroups on older distro releases. On Mar 3, 2017 20:11, "Serge Hallyn" <1668...@bugs.launchpad.net> wrote: > This bug incidentally also affects the cgroupfs-mount package. > > -- > You received this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1668724 > > Title: > fails to mount cgroupfs inside containers running on 16.04 > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/cgroup-lite/+ > bug/1668724/+subscriptions > -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cgroup-lite in Ubuntu. https://bugs.launchpad.net/bugs/1668724 Title: fails to mount cgroupfs inside containers running on 16.04 Status in cgroup-lite package in Ubuntu: Triaged Status in cgroup-lite source package in Precise: New Status in cgroup-lite source package in Trusty: New Status in cgroup-lite source package in Xenial: New Status in cgroup-lite source package in Yakkety: New Bug description: I need to run nested Ubuntu 12.04 and 14.04 containers on 16.04 hosts, and have noticed that the cgroups-mount script for mounting the cgroups inside the containers has stopped working. This is because systemd now comounts multiple controllers on a single hierarchy, which prevents mounting them individually inside the container. === SRU Justification Impact: nested containers fail to start Reproduce: create a root owned container; install lxc and cgroup-lite; create a container, and try to start it. Starting will fail if cgroup-lite is running in the first level container without this patch. Regression potential: should be low, it's possible that the regexp is simply wrong for some cases. === To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cgroup-lite/+bug/1668724/+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 1668724] Re: fails to mount cgroupfs inside containers running on 16.04
Hm, I found a bug in my last version of this patch. Freshly booted machines which had not mounted the cgroupfs had all the hierarchies as 0, causing all cgroups to get mounted onto a single directory. I can work around this by detecting this scenario. However, I wonder if I am actually seeing a bug in LXC. On my 12.04 hosts spawning 12.04 containers with the nesting.conf include, the cgroupfs gets automounted inside the container even without this package. This is not the case on 16.04 hosts. I'm currently using LXC 2.0.6. RE: name=systemd, I had modified an older version of our scripts to mount name=systemd, because that was how it showed up in /proc/self/cgroups, but everywhere I see the systemd cgroup mentioned on the internet has it mounted at /sys/fs/cgroup/systemd, so I guess that's an implementation detail I just have to deal with. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cgroup-lite in Ubuntu. https://bugs.launchpad.net/bugs/1668724 Title: fails to mount cgroupfs inside containers running on 16.04 Status in cgroup-lite package in Ubuntu: Triaged Status in cgroup-lite source package in Precise: New Status in cgroup-lite source package in Trusty: New Status in cgroup-lite source package in Xenial: New Status in cgroup-lite source package in Yakkety: New Bug description: I need to run nested Ubuntu 12.04 and 14.04 containers on 16.04 hosts, and have noticed that the cgroups-mount script for mounting the cgroups inside the containers has stopped working. This is because systemd now comounts multiple controllers on a single hierarchy, which prevents mounting them individually inside the container. === SRU Justification Impact: nested containers fail to start Reproduce: create a root owned container; install lxc and cgroup-lite; create a container, and try to start it. Starting will fail if cgroup-lite is running in the first level container without this patch. Regression potential: should be low, it's possible that the regexp is simply wrong for some cases. === To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cgroup-lite/+bug/1668724/+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 1668724] Re: fails to mount cgroupfs inside containers running on 16.04
Edit: re: the systemd hierarchy, it's actually not mentioned in /proc/cgroups, it's /proc/self/cgroups -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cgroup-lite in Ubuntu. https://bugs.launchpad.net/bugs/1668724 Title: fails to mount cgroupfs inside containers running on 16.04 Status in cgroup-lite package in Ubuntu: Triaged Bug description: I need to run nested Ubuntu 12.04 and 14.04 containers on 16.04 hosts, and have noticed that the cgroups-mount script for mounting the cgroups inside the containers has stopped working. This is because systemd now comounts multiple controllers on a single hierarchy, which prevents mounting them individually inside the container. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cgroup-lite/+bug/1668724/+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 1668724] Re: fails to mount cgroupfs inside containers running on 16.04
Also, is there a reason the name=systemd cgroup controller gets mounted at /sys/fs/cgroup/systemd instead of /sys/fs/cgroup/name=systemd in newer versions of cgroups-mount? It means my applications have to special-case stripping off the name= when they try to work with cgroups based upon /proc/cgroups. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cgroup-lite in Ubuntu. https://bugs.launchpad.net/bugs/1668724 Title: fails to mount cgroupfs inside containers running on 16.04 Status in cgroup-lite package in Ubuntu: Triaged Bug description: I need to run nested Ubuntu 12.04 and 14.04 containers on 16.04 hosts, and have noticed that the cgroups-mount script for mounting the cgroups inside the containers has stopped working. This is because systemd now comounts multiple controllers on a single hierarchy, which prevents mounting them individually inside the container. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cgroup-lite/+bug/1668724/+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 1668724] Re: fails to mount cgroupfs inside containers running on 16.04
Whoops, didn't notice I changed that part in my local copy. Should have been more careful with my patch. ** Patch removed: "cgroup-lite_1.1.5.patch" https://bugs.launchpad.net/ubuntu/+source/cgroup-lite/+bug/1668724/+attachment/4828546/+files/cgroup-lite_1.1.5.patch ** Patch removed: "cgroup-lite_1.12.patch" https://bugs.launchpad.net/ubuntu/+source/cgroup-lite/+bug/1668724/+attachment/4828547/+files/cgroup-lite_1.12.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cgroup-lite in Ubuntu. https://bugs.launchpad.net/bugs/1668724 Title: fails to mount cgroupfs inside containers running on 16.04 Status in cgroup-lite package in Ubuntu: Triaged Bug description: I need to run nested Ubuntu 12.04 and 14.04 containers on 16.04 hosts, and have noticed that the cgroups-mount script for mounting the cgroups inside the containers has stopped working. This is because systemd now comounts multiple controllers on a single hierarchy, which prevents mounting them individually inside the container. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cgroup-lite/+bug/1668724/+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 1668724] Re: fails to mount cgroupfs inside containers running on 16.04
Patch for 1.12 ** Patch added: "cgroup-lite_1.12.patch" https://bugs.launchpad.net/ubuntu/+source/cgroup-lite/+bug/1668724/+attachment/4828590/+files/cgroup-lite_1.12.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cgroup-lite in Ubuntu. https://bugs.launchpad.net/bugs/1668724 Title: fails to mount cgroupfs inside containers running on 16.04 Status in cgroup-lite package in Ubuntu: Triaged Bug description: I need to run nested Ubuntu 12.04 and 14.04 containers on 16.04 hosts, and have noticed that the cgroups-mount script for mounting the cgroups inside the containers has stopped working. This is because systemd now comounts multiple controllers on a single hierarchy, which prevents mounting them individually inside the container. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cgroup-lite/+bug/1668724/+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 1668724] Re: fails to mount cgroupfs inside containers running on 16.04
Patch for 1.1.5 ** Patch added: "cgroup-lite_1.1.5.patch" https://bugs.launchpad.net/ubuntu/+source/cgroup-lite/+bug/1668724/+attachment/4828588/+files/cgroup-lite_1.1.5.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cgroup-lite in Ubuntu. https://bugs.launchpad.net/bugs/1668724 Title: fails to mount cgroupfs inside containers running on 16.04 Status in cgroup-lite package in Ubuntu: Triaged Bug description: I need to run nested Ubuntu 12.04 and 14.04 containers on 16.04 hosts, and have noticed that the cgroups-mount script for mounting the cgroups inside the containers has stopped working. This is because systemd now comounts multiple controllers on a single hierarchy, which prevents mounting them individually inside the container. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cgroup-lite/+bug/1668724/+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 1668724] Re: fails to mount cgroupfs inside containers running on 16.04
It looks like there were fixes in the latest version of cgroup-lite that would still be applicable/useful for earlier ubuntu releases, but I tried to minimize the diffs to have the functionality that I need. Let me know if you need a patch for trusty as well. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cgroup-lite in Ubuntu. https://bugs.launchpad.net/bugs/1668724 Title: fails to mount cgroupfs inside containers running on 16.04 Status in cgroup-lite package in Ubuntu: Triaged Bug description: I need to run nested Ubuntu 12.04 and 14.04 containers on 16.04 hosts, and have noticed that the cgroups-mount script for mounting the cgroups inside the containers has stopped working. This is because systemd now comounts multiple controllers on a single hierarchy, which prevents mounting them individually inside the container. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cgroup-lite/+bug/1668724/+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 1668724] Re: fails to mount cgroupfs inside containers running on 16.04
Patch for 1.12 ** Patch added: "cgroup-lite_1.12.patch" https://bugs.launchpad.net/ubuntu/+source/cgroup-lite/+bug/1668724/+attachment/4828547/+files/cgroup-lite_1.12.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cgroup-lite in Ubuntu. https://bugs.launchpad.net/bugs/1668724 Title: fails to mount cgroupfs inside containers running on 16.04 Status in cgroup-lite package in Ubuntu: Triaged Bug description: I need to run nested Ubuntu 12.04 and 14.04 containers on 16.04 hosts, and have noticed that the cgroups-mount script for mounting the cgroups inside the containers has stopped working. This is because systemd now comounts multiple controllers on a single hierarchy, which prevents mounting them individually inside the container. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cgroup-lite/+bug/1668724/+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 1668724] Re: fails to mount cgroupfs inside containers running on 16.04
Patch for cgroup-lite 1.1.5 ** Patch added: "cgroup-lite_1.1.5.patch" https://bugs.launchpad.net/ubuntu/+source/cgroup-lite/+bug/1668724/+attachment/4828546/+files/cgroup-lite_1.1.5.patch -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cgroup-lite in Ubuntu. https://bugs.launchpad.net/bugs/1668724 Title: fails to mount cgroupfs inside containers running on 16.04 Status in cgroup-lite package in Ubuntu: Triaged Bug description: I need to run nested Ubuntu 12.04 and 14.04 containers on 16.04 hosts, and have noticed that the cgroups-mount script for mounting the cgroups inside the containers has stopped working. This is because systemd now comounts multiple controllers on a single hierarchy, which prevents mounting them individually inside the container. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cgroup-lite/+bug/1668724/+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 1668724] [NEW] fails to mount cgroupfs inside containers running on 16.04
Public bug reported: I need to run nested Ubuntu 12.04 and 14.04 containers on 16.04 hosts, and have noticed that the cgroups-mount script for mounting the cgroups inside the containers has stopped working. This is because systemd now comounts multiple controllers on a single hierarchy, which prevents mounting them individually inside the container. ** Affects: cgroup-lite (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cgroup-lite in Ubuntu. https://bugs.launchpad.net/bugs/1668724 Title: fails to mount cgroupfs inside containers running on 16.04 Status in cgroup-lite package in Ubuntu: New Bug description: I need to run nested Ubuntu 12.04 and 14.04 containers on 16.04 hosts, and have noticed that the cgroups-mount script for mounting the cgroups inside the containers has stopped working. This is because systemd now comounts multiple controllers on a single hierarchy, which prevents mounting them individually inside the container. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cgroup-lite/+bug/1668724/+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 1659676] [NEW] backport timesyncd patch for updating the RTC
Public bug reported: Please backport this patch to 16.04, which should improve reliability of timesyncd updates to the RTC: https://github.com/systemd/systemd/commit/5f36e3d30375cf04292bbc1bf3f4d7512cf80139 ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Description changed: - Please backport this patch, which should improve reliability of + Please backport this patch to 16.04, which should improve reliability of timesyncd updates to the RTC: https://github.com/systemd/systemd/commit/5f36e3d30375cf04292bbc1bf3f4d7512cf80139 -- 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/1659676 Title: backport timesyncd patch for updating the RTC Status in systemd package in Ubuntu: New Bug description: Please backport this patch to 16.04, which should improve reliability of timesyncd updates to the RTC: https://github.com/systemd/systemd/commit/5f36e3d30375cf04292bbc1bf3f4d7512cf80139 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1659676/+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 1125726] Re: boot-time race between /etc/network/if-up.d/ntpdate and "/etc/init.d/ntp start"
Nathan: How many interfaces or IP's are you bringing up? That error message makes it sound like there could be a lot of contention on the lock. Could you also get the output of `pstree | grep -B3 lockfile` while a VM is coming up? (You'll need to attach to a free virtual terminal using the kvm console). Upon reading more of the lockfile-create manpage, it appears that there's a non-configurable 5-minute timeout on stale locks. Setting the --use-pid option might free up the lock more quickly if the parent process has died for some reason. It's not clear to me how this could prevent networking from coming up, since the network has to be up for NTP to run, and the if-up.d script backgrounds the ntpdate locking+syncing script. sshd in 12.04 and 14.04 is started from an upstart script which does not depend on the NTP service. The NTP service itself is fairly early in the sysvinit order at S23, so there might be other init scripts blocked behind it. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1125726 Title: boot-time race between /etc/network/if-up.d/ntpdate and "/etc/init.d/ntp start" Status in ntp package in Ubuntu: Fix Released Status in ntp source package in Precise: Fix Released Status in ntp source package in Trusty: Fix Released Bug description: [Impact] * Hardware clocks are not stepped at boot, which can prevent NTP from ever syncing the clock. Incorrect clocks can cause serious issues in distributed systems. * Upstream originally added a lock file to eliminate a race between the ntp service (which keeps the clock synchronized during normal operation) and ntpdate (which is used to step the clock by large intervals at boot time). That change had a flaw which introduced a deadlock. An Ubuntu patch was applied which broke the locking mechanism entirely, reintroducing the race condition. * This change undoes the Ubuntu patch and fixes the deadlock by unlocking before attempting to start the ntp service. [Test Case] * There are two bugs: The race, and the deadlock. To reproduce the race more consistently: - add 'sleep 30' to '/etc/network/if-up.d/ntpdate' on the line preceding '/usr/sbin/ntpdate-debian -s $OPTS 2>/dev/null || :', and comment out 'invoke-rc.d --quiet $service stop >/dev/null 2>&1 || true'. This will reproduce the case where the ntp service starts between the stop command and the ntpdate command. The result will be that the ntpdate command fails. There will be a message in syslog like: 'ntpdate[17660]: the NTP socket is in use, exiting' - Reintroducing the lock brings back the deadlock issue. Both the ntpdate if-up.d script and the ntp init script check the lock file, but the ntpdate script attempted to start the ntp init script before unlocking the lock. Moving the unlock before the init script invocation fixes the deadlock. The original deadlock behavior is described here: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/246203 [Regression Potential] * Low. Out-of-sync clocks could be changed a large amount at boot time, but only for machines with static IP's. The clock is only likely to be in this state if the clock was very skewed at boot time, which is also unlikely since NTP usually keeps the software clock in sync during operation and the hardware clock is updated at shutdown. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1125726/+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 1125726] Re: boot-time race between /etc/network/if-up.d/ntpdate and "/etc/init.d/ntp start"
I can confirm I've been running this in production and have not seen any further issues. ** Tags removed: verification-needed ** Tags added: verification-done -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1125726 Title: boot-time race between /etc/network/if-up.d/ntpdate and "/etc/init.d/ntp start" Status in ntp package in Ubuntu: Fix Released Status in ntp source package in Precise: Fix Committed Status in ntp source package in Trusty: Fix Committed Bug description: [Impact] * Hardware clocks are not stepped at boot, which can prevent NTP from ever syncing the clock. Incorrect clocks can cause serious issues in distributed systems. * Upstream originally added a lock file to eliminate a race between the ntp service (which keeps the clock synchronized during normal operation) and ntpdate (which is used to step the clock by large intervals at boot time). That change had a flaw which introduced a deadlock. An Ubuntu patch was applied which broke the locking mechanism entirely, reintroducing the race condition. * This change undoes the Ubuntu patch and fixes the deadlock by unlocking before attempting to start the ntp service. [Test Case] * There are two bugs: The race, and the deadlock. To reproduce the race more consistently: - add 'sleep 30' to '/etc/network/if-up.d/ntpdate' on the line preceding '/usr/sbin/ntpdate-debian -s $OPTS 2>/dev/null || :', and comment out 'invoke-rc.d --quiet $service stop >/dev/null 2>&1 || true'. This will reproduce the case where the ntp service starts between the stop command and the ntpdate command. The result will be that the ntpdate command fails. There will be a message in syslog like: 'ntpdate[17660]: the NTP socket is in use, exiting' - Reintroducing the lock brings back the deadlock issue. Both the ntpdate if-up.d script and the ntp init script check the lock file, but the ntpdate script attempted to start the ntp init script before unlocking the lock. Moving the unlock before the init script invocation fixes the deadlock. The original deadlock behavior is described here: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/246203 [Regression Potential] * Low. Out-of-sync clocks could be changed a large amount at boot time, but only for machines with static IP's. The clock is only likely to be in this state if the clock was very skewed at boot time, which is also unlikely since NTP usually keeps the software clock in sync during operation and the hardware clock is updated at shutdown. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1125726/+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 1125726] Re: boot-time race between /etc/network/if-up.d/ntpdate and "/etc/init.d/ntp start"
** Description changed: - We're seeing a race between if-up.d/ntpdate and the ntp startup script. + [Impact] + * Hardware clocks are not stepped at boot, which can prevent NTP from ever + syncing the clock. + Incorrect clocks can cause serious issues in distributed systems. - 1) if-up.d/ntpdate starts. - 2) if-up.d/ntpdate acquires the lock "/var/lock/ntpdate-ifup". - 3) if-up.d/ntpdate stops the ntp service [which isn't running anyway]. - 4) if-up.d/ntpdate starts running ntpdate, which bids UDP *.ntp - 5) /etc/init.d/rc 2 executes "/etc/rc2.d/S20ntp start" - 6) /etc/init.d/ntp acquires the lock "/var/lock/ntpdate". - 7) /etc/init.d/ntp starts the ntp daemon. - 8) The ntp daemon logs an error, complaining that it cannot bind UDP *.ntp. - 9) if-up.d/ntpdate now starts the ntp service. + * Upstream originally added a lock file to eliminate a race between the ntp + service (which keeps the clock synchronized during normal operation) and + ntpdate (which is used to step the clock by large intervals at boot time). + That change had a flaw which introduced a deadlock. An Ubuntu patch was + applied which broke the locking mechanism entirely, reintroducing the race + condition. - The result is a weird churn, though ntpd does end up running at the end. + * This change undoes the Ubuntu patch and fixes the deadlock by unlocking + before attempting to start the ntp service. - Should these not be using the same lock file? + [Test Case] + + * There are two bugs: The race, and the deadlock. To reproduce the race more + consistently: + - add 'sleep 30' to '/etc/network/if-up.d/ntpdate' on the line preceding + '/usr/sbin/ntpdate-debian -s $OPTS 2>/dev/null || :', and comment out + 'invoke-rc.d --quiet $service stop >/dev/null 2>&1 || true'. This will + reproduce the case where the ntp service starts between the stop command + and the ntpdate command. + The result will be that the ntpdate command fails. There will be a + message in syslog like: + 'ntpdate[17660]: the NTP socket is in use, exiting' + - Reintroducing the lock brings back the deadlock issue. Both the ntpdate + if-up.d script and the ntp init script check the lock file, but the + ntpdate script attempted to start the ntp init script before unlocking + the lock. Moving the unlock before the init script invocation fixes + the deadlock. The original deadlock behavior is described here: + https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/246203 + + [Regression Potential] + + * Low. Out-of-sync clocks could be changed a large amount at boot time, but + only for machines with static IP's. The clock is only likely to be in this + state if the clock was very skewed at boot time, which is also unlikely + since NTP usually keeps the software clock in sync during operation and + the hardware clock is updated at shutdown. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1125726 Title: boot-time race between /etc/network/if-up.d/ntpdate and "/etc/init.d/ntp start" Status in ntp package in Ubuntu: Fix Released Status in ntp source package in Precise: New Status in ntp source package in Trusty: New Bug description: [Impact] * Hardware clocks are not stepped at boot, which can prevent NTP from ever syncing the clock. Incorrect clocks can cause serious issues in distributed systems. * Upstream originally added a lock file to eliminate a race between the ntp service (which keeps the clock synchronized during normal operation) and ntpdate (which is used to step the clock by large intervals at boot time). That change had a flaw which introduced a deadlock. An Ubuntu patch was applied which broke the locking mechanism entirely, reintroducing the race condition. * This change undoes the Ubuntu patch and fixes the deadlock by unlocking before attempting to start the ntp service. [Test Case] * There are two bugs: The race, and the deadlock. To reproduce the race more consistently: - add 'sleep 30' to '/etc/network/if-up.d/ntpdate' on the line preceding '/usr/sbin/ntpdate-debian -s $OPTS 2>/dev/null || :', and comment out 'invoke-rc.d --quiet $service stop >/dev/null 2>&1 || true'. This will reproduce the case where the ntp service starts between the stop command and the ntpdate command. The result will be that the ntpdate command fails. There will be a message in syslog like: 'ntpdate[17660]: the NTP socket is in use, exiting' - Reintroducing the lock brings back the deadlock issue. Both the ntpdate if-up.d script and the ntp init script check the lock file, but the ntpdate script attempted to start the ntp init script before unlocking the lock. Moving the unlock before the init script invocation fixes the deadlock. The original
[Touch-packages] [Bug 1125726] Re: boot-time race between /etc/network/if-up.d/ntpdate and "/etc/init.d/ntp start"
In case it wasn't clear, my patch is supposed to be for the debian/ntpdate.if-up file. Also, I think the priority of this bug should be higher, it was assigned 'low' when there was no clear problem caused by the race. Systems booting with uncorrectable clock skew can be a serious problem. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/1125726 Title: boot-time race between /etc/network/if-up.d/ntpdate and "/etc/init.d/ntp start" Status in ntp package in Ubuntu: Confirmed Bug description: We're seeing a race between if-up.d/ntpdate and the ntp startup script. 1) if-up.d/ntpdate starts. 2) if-up.d/ntpdate acquires the lock "/var/lock/ntpdate-ifup". 3) if-up.d/ntpdate stops the ntp service [which isn't running anyway]. 4) if-up.d/ntpdate starts running ntpdate, which bids UDP *.ntp 5) /etc/init.d/rc 2 executes "/etc/rc2.d/S20ntp start" 6) /etc/init.d/ntp acquires the lock "/var/lock/ntpdate". 7) /etc/init.d/ntp starts the ntp daemon. 8) The ntp daemon logs an error, complaining that it cannot bind UDP *.ntp. 9) if-up.d/ntpdate now starts the ntp service. The result is a weird churn, though ntpd does end up running at the end. Should these not be using the same lock file? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1125726/+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 1316873] Re: Left mouse button stops working
I think a common cause for this issue could be stuck buttons. I was seeing a similar symptom today where the left button on my usb mouse attached to my closed laptop wasn't working. Opening the lid and tapping the mouse buttons by my touchpad fixed the issue. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1316873 Title: Left mouse button stops working Status in xorg package in Ubuntu: Expired Bug description: This problem has plagued me for a few years across different laptops and Ubuntu versions. Current I am experiencing this on a Dell Inspiron 15z running Ubuntu 14.04 LTS. It typically starts after I have used the chat or call feature in gmail, by clicking on the phone icon in the left chat margin. I am a Firefox user and have not tested this with chrome etc. It has not happened if i dont install google-talkplugin so it is quite possible that the plugin is to blame. Symptom === The left mouse button on all attached mice - USB , Trackpad and touch - will not do anything however the right mouse button continues to work. This happens to all applications and also to the desktop. The keyboard continues to function as normal. When this occurs , my solution is to Alt-F4 close all windows and log out of the X session. When I re-login the left mouse button works as normal. This is an irritant and work disruptor as I have to save all browser and desktop applications to safe state before I logout to reset the mouse. I will appreciate any soltion or workaround. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: xorg 1:7.7+1ubuntu8 ProcVersionSignature: Ubuntu 3.13.0-24.47-generic 3.13.9 Uname: Linux 3.13.0-24-generic x86_64 .tmp.unity.support.test.0: ApportVersion: 2.14.1-0ubuntu3 Architecture: amd64 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: compiz CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0' CompositorUnredirectFSW: true CurrentDesktop: Unity Date: Tue May 6 21:41:29 2014 DistUpgraded: Fresh install DistroCodename: trusty DistroVariant: ubuntu ExtraDebuggingInterest: Yes GraphicsCard: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Dell Device [1028:058f] InstallationDate: Installed on 2014-04-17 (19 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) MachineType: Dell Inc. Inspiron 5523 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-24-generic root=UUID=f5004b03-b37f-4733-88a8-51c6f3bd0a4d ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 05/18/2013 dmi.bios.vendor: Dell Inc. dmi.bios.version: A05 dmi.board.name: 0GKGJG dmi.board.vendor: Dell Inc. dmi.board.version: A05 dmi.chassis.type: 8 dmi.chassis.vendor: Dell Inc. dmi.chassis.version: Not Specified dmi.modalias: dmi:bvnDellInc.:bvrA05:bd05/18/2013:svnDellInc.:pnInspiron5523:pvrNotSpecified:rvnDellInc.:rn0GKGJG:rvrA05:cvnDellInc.:ct8:cvrNotSpecified: dmi.product.name: Inspiron 5523 dmi.product.version: Not Specified dmi.sys.vendor: Dell Inc. version.compiz: compiz 1:0.9.11+14.04.20140423-0ubuntu1 version.ia32-libs: ia32-libs N/A version.libdrm2: libdrm2 2.4.52-1 version.libgl1-mesa-dri: libgl1-mesa-dri 10.1.0-4ubuntu5 version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A version.libgl1-mesa-glx: libgl1-mesa-glx 10.1.0-4ubuntu5 version.xserver-xorg-core: xserver-xorg-core 2:1.15.1-0ubuntu2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.8.2-1ubuntu2 version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.3.0-1ubuntu3 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.910-0ubuntu1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.10-1ubuntu2 xserver.bootTime: Tue May 6 21:20:40 2014 xserver.configfile: default xserver.errors: xserver.logfile: /var/log/Xorg.0.log xserver.outputs: product id5558 vendor CMN xserver.version: 2:1.15.1-0ubuntu2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1316873/+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
