[Desktop-packages] [Bug 2043640] Re: amdgpu: GPU Recovery fails, frequent hangs
** Description changed: I've been using 23.04 for a few months, and experienced a total system hang occasionally when sharing my screen over Zoom or Google Meet (running on Google Chrome). At first it hangs and then it periodically flashes like it's trying (unsuccessfully) to recover; I've got 3 screens (including the laptop's internal one) and each attempt shows something different (at first it tries to recover the contents of all 3 screens, then it shows only one of them, and then it shows the same content on all 3, but it never gets responsive). I've recently upgraded to 23.10, hoping a new kernel would help the situation. It's only gotten considerably worse now; it hangs sometimes just when opening Zoom; it's somehow easier to reproduce with Google Chrome. Interestingly, it fails quickly and reliably now when enabling my webcam (with special effects). It started hanging badly when using Google Maps as well. For all these behaviors, I suspect amdgpu is to blame (I'm running on Renoir, 4750U Pro); `dmesg` and `journalctl` didn't seem to show anything interesting. Any tips about debugging this further? ProblemType: Bug DistroRelease: Ubuntu 23.10 Package: linux-generic 6.5.0.10.12 ProcVersionSignature: Ubuntu 6.5.0-10.10-generic 6.5.3 Uname: Linux 6.5.0-10-generic x86_64 ApportVersion: 2.27.0-0ubuntu5 Architecture: amd64 CRDA: N/A CasperMD5CheckResult: pass CurrentDesktop: GNOME Date: Thu Nov 16 02:27:45 2023 InstallationDate: Installed on 2023-07-02 (137 days ago) InstallationMedia: Ubuntu 23.04 "Lunar Lobster" - Release amd64 (20230418) MachineType: {report['dmi.sys.vendor']} {report['dmi.product.name']} ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR= ProcFB: 0 amdgpudrmfb ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-6.5.0-10-generic root=/dev/mapper/ubuntu--vg-ubuntu--lv ro quiet splash vt.handoff=7 PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. RelatedPackageVersions: linux-restricted-modules-6.5.0-10-generic N/A linux-backports-modules-6.5.0-10-generic N/A linux-firmware20230919.git3672ccab-0ubuntu2.1 SourcePackage: linux UpgradeStatus: Upgraded to mantic on 2023-11-14 (2 days ago) dmi.bios.date: 06/13/2023 dmi.bios.release: 1.44 dmi.bios.vendor: LENOVO dmi.bios.version: R1BET75W(1.44 ) dmi.board.asset.tag: Not Available dmi.board.name: 20UD000GUS dmi.board.vendor: LENOVO dmi.board.version: SDK0J40697 WIN dmi.chassis.asset.tag: No Asset Information dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: None dmi.ec.firmware.release: 1.44 dmi.modalias: dmi:bvnLENOVO:bvrR1BET75W(1.44):bd06/13/2023:br1.44:efr1.44:svnLENOVO:pn20UD000GUS:pvrThinkPadT14Gen1:rvnLENOVO:rn20UD000GUS:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_20UD_BU_Think_FM_ThinkPadT14Gen1: dmi.product.family: ThinkPad T14 Gen 1 dmi.product.name: 20UD000GUS dmi.product.sku: LENOVO_MT_20UD_BU_Think_FM_ThinkPad T14 Gen 1 dmi.product.version: ThinkPad T14 Gen 1 dmi.sys.vendor: LENOVO + + X-HWE-Bug: Bug #2047389 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/2043640 Title: amdgpu: GPU Recovery fails, frequent hangs Status in Mesa: Fix Released Status in linux package in Ubuntu: Confirmed Status in mesa package in Ubuntu: Fix Released Status in linux source package in Jammy: Confirmed Status in mesa source package in Jammy: New Status in linux source package in Lunar: Confirmed Status in mesa source package in Lunar: New Bug description: I've been using 23.04 for a few months, and experienced a total system hang occasionally when sharing my screen over Zoom or Google Meet (running on Google Chrome). At first it hangs and then it periodically flashes like it's trying (unsuccessfully) to recover; I've got 3 screens (including the laptop's internal one) and each attempt shows something different (at first it tries to recover the contents of all 3 screens, then it shows only one of them, and then it shows the same content on all 3, but it never gets responsive). I've recently upgraded to 23.10, hoping a new kernel would help the situation. It's only gotten considerably worse now; it hangs sometimes just when opening Zoom; it's somehow easier to reproduce with Google Chrome. Interestingly, it fails quickly and reliably now when enabling my webcam (with special effects). It started hanging badly when using Google Maps as well. For all these behaviors, I suspect amdgpu is to blame (I'm running on Renoir, 4750U Pro); `dmesg` and `journalctl` didn't seem to show anything interesting. Any tips about debugging this further? ProblemType: Bug
[Desktop-packages] [Bug 2047388] [NEW] System reboots automatically when lock screen screen enabled.
Public bug reported: System reboots automatically when lock screen screen enabled. The same is tested on ubuntu-20.04 as well as ubuntu-22.04. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: xorg 1:7.7+23ubuntu2 ProcVersionSignature: Ubuntu 6.2.0-26.26~22.04.1-generic 6.2.13 Uname: Linux 6.2.0-26-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: pass CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Tue Dec 26 11:42:52 2023 DistUpgraded: Fresh install DistroCodename: jammy DistroVariant: ubuntu ExtraDebuggingInterest: Yes GraphicsCard: Intel Corporation CoffeeLake-S GT2 [UHD Graphics 630] [8086:3e92] (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company CometLake-S GT2 [UHD Graphics 630] [103c:85a2] InstallationDate: Installed on 2023-12-07 (19 days ago) InstallationMedia: Ubuntu 22.04.3 LTS "Jammy Jellyfish" - Release amd64 (20230807.2) MachineType: HP HP ProOne 400 G5 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.2.0-26-generic root=UUID=3a72d508-3f06-4b45-a814-8d4bef8b43d0 ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/21/2021 dmi.bios.release: 9.0 dmi.bios.vendor: HP dmi.bios.version: R12 Ver. 02.09.00 dmi.board.name: 85A2 dmi.board.vendor: HP dmi.board.version: KBC Version 08.98.00 dmi.chassis.type: 13 dmi.chassis.vendor: HP dmi.ec.firmware.release: 8.152 dmi.modalias: dmi:bvnHP:bvrR12Ver.02.09.00:bd04/21/2021:br9.0:efr8.152:svnHP:pnHPProOne400G5:pvr:rvnHP:rn85A2:rvrKBCVersion08.98.00:cvnHP:ct13:cvr:sku6AE46AV: dmi.product.family: 103C_53307F HP ProOne dmi.product.name: HP ProOne 400 G5 dmi.product.sku: 6AE46AV dmi.sys.vendor: HP version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.113-2~ubuntu0.22.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 23.0.4-0ubuntu1~22.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:21.1.4-2ubuntu1.7~22.04.1 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2ubuntu1 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20210115-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-2build1 ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug jammy ubuntu wayland-session -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/2047388 Title: System reboots automatically when lock screen screen enabled. Status in xorg package in Ubuntu: New Bug description: System reboots automatically when lock screen screen enabled. The same is tested on ubuntu-20.04 as well as ubuntu-22.04. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: xorg 1:7.7+23ubuntu2 ProcVersionSignature: Ubuntu 6.2.0-26.26~22.04.1-generic 6.2.13 Uname: Linux 6.2.0-26-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.5 Architecture: amd64 BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log' CasperMD5CheckResult: pass CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Tue Dec 26 11:42:52 2023 DistUpgraded: Fresh install DistroCodename: jammy DistroVariant: ubuntu ExtraDebuggingInterest: Yes GraphicsCard: Intel Corporation CoffeeLake-S GT2 [UHD Graphics 630] [8086:3e92] (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company CometLake-S GT2 [UHD Graphics 630] [103c:85a2] InstallationDate: Installed on 2023-12-07 (19 days ago) InstallationMedia: Ubuntu 22.04.3 LTS "Jammy Jellyfish" - Release amd64 (20230807.2) MachineType: HP HP ProOne 400 G5 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.2.0-26-generic root=UUID=3a72d508-3f06-4b45-a814-8d4bef8b43d0 ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/21/2021 dmi.bios.release: 9.0 dmi.bios.vendor: HP dmi.bios.version: R12 Ver. 02.09.00 dmi.board.name: 85A2 dmi.board.vendor: HP dmi.board.version: KBC Version 08.98.00 dmi.chassis.type: 13 dmi.chassis.vendor: HP dmi.ec.firmware.release: 8.152 dmi.modalias: dmi:bvnHP:bvrR12Ver.02.09.00:bd04/21/2021:br9.0:efr8.152:svnHP:pnHPProOne400G5:pvr:rvnHP:rn85A2:rvrKBCVersion08.98.00:cvnHP:ct13:cvr:sku6AE46AV: dmi.product.family: 103C_53307F HP ProOne dmi.product.name: HP ProOne 400 G5 dmi.product.sku: 6AE46AV dmi.sys.vendor: HP version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.113-2~ubuntu0.22.04.1 version.libgl1-mesa-dri: libgl1-mesa-dri 23.0.4-0ubuntu1~22.04.1 version.libgl1-mesa-glx: libgl1-mesa-glx N/A version.xserver-xorg-core: xserver-xorg-core 2:21.1.4-2ubuntu1.7~22.04.1 version.xserver-xorg-input-evdev: xserver-xorg-input-evd
[Desktop-packages] [Bug 2047363] [NEW] bottom dock animation issue
Public bug reported: I noticed that there a bug where when you have the Dock at the bottom and you launch an app, which minimizing it it won’t minimize to the bottom as it still thinks the Dock is off to the left. Once you change work spaces then only does the app realize that the dock is at the bottom of the screen. ProblemType: Bug DistroRelease: Ubuntu 23.10 Package: gnome-shell-extension-ubuntu-dock 87ubuntu2 ProcVersionSignature: Ubuntu 6.5.0-14.14-generic 6.5.3 Uname: Linux 6.5.0-14-generic x86_64 ApportVersion: 2.27.0-0ubuntu5 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Mon Dec 25 21:38:53 2023 InstallationDate: Installed on 2023-12-02 (23 days ago) InstallationMedia: Ubuntu 23.10.1 "Mantic Minotaur" - Release amd64 (20231016.1) PackageArchitecture: all ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR= SourcePackage: gnome-shell-extension-ubuntu-dock UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: gnome-shell-extension-ubuntu-dock (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug mantic wayland-session -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-ubuntu-dock in Ubuntu. https://bugs.launchpad.net/bugs/2047363 Title: bottom dock animation issue Status in gnome-shell-extension-ubuntu-dock package in Ubuntu: New Bug description: I noticed that there a bug where when you have the Dock at the bottom and you launch an app, which minimizing it it won’t minimize to the bottom as it still thinks the Dock is off to the left. Once you change work spaces then only does the app realize that the dock is at the bottom of the screen. ProblemType: Bug DistroRelease: Ubuntu 23.10 Package: gnome-shell-extension-ubuntu-dock 87ubuntu2 ProcVersionSignature: Ubuntu 6.5.0-14.14-generic 6.5.3 Uname: Linux 6.5.0-14-generic x86_64 ApportVersion: 2.27.0-0ubuntu5 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Mon Dec 25 21:38:53 2023 InstallationDate: Installed on 2023-12-02 (23 days ago) InstallationMedia: Ubuntu 23.10.1 "Mantic Minotaur" - Release amd64 (20231016.1) PackageArchitecture: all ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR= SourcePackage: gnome-shell-extension-ubuntu-dock UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell-extension-ubuntu-dock/+bug/2047363/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1720364] Re: Unable to use shortcuts with keyboard layout switcher on Ubuntu MATE, 16.04 (with HWE), 17.10 and 18.04 LTS
*** This bug is a duplicate of bug 1683383 *** https://bugs.launchpad.net/bugs/1683383 There is indeed a problem in Linux with this... Please vote for this bug: https://github.com/xkbcommon/libxkbcommon/issues/420, I really hope they fix it. This is a stopper for me moving to Linux. ** Bug watch added: github.com/xkbcommon/libxkbcommon/issues #420 https://github.com/xkbcommon/libxkbcommon/issues/420 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1720364 Title: Unable to use shortcuts with keyboard layout switcher on Ubuntu MATE, 16.04 (with HWE), 17.10 and 18.04 LTS Status in MATE Desktop: New Status in Ubuntu MATE: New Status in X.Org X server: Confirmed Status in marco package in Ubuntu: Confirmed Status in xorg package in Ubuntu: Confirmed Status in xorg-hwe-16.04 package in Ubuntu: Confirmed Status in xorg package in Debian: New Bug description: Steps to reproduce: 1. Install ubuntu-mate-desktop on Ubuntu 16.04 LTS with HWE (Xorg 1.19.5), or 17.10 or 18.04 LTS. 2. Set-up two keyboard layouts - English and Russian 3. Set as keyboard layout switcher 4. Try to use shortcuts starting from : 4.1. Open Firefox, open new tab, go to some site in it, close tab, try to click to restore closed tab. 4.2. Open mate-terminal, try to open new tab with , or copy (), or paste (). 4.3. Open pluma, write some text, try to navigate in it with . Expected results: switches keyboard layout, shortcuts starting from work normally. Actual results: switches keyboard layout, shortcuts starting from do not work. Notes: 1. Ubuntu 16.04 LTS (Xorg 1.18.4) with Marco and Compton work normally with keyboard layout switcher. 2. This problem was discovered before on 13.10, 14.04 and other modern versions with GNOME desktop (Metacity and Compiz) - see bug 1245473. ProblemType: Bug DistroRelease: Ubuntu 17.10 Package: marco 1.18.1-3ubuntu1 ProcVersionSignature: Ubuntu 4.13.0-12.13-generic 4.13.3 Uname: Linux 4.13.0-12-generic i686 ApportVersion: 2.20.7-0ubuntu1 Architecture: i386 CurrentDesktop: MATE Date: Fri Sep 29 16:18:02 2017 InstallationDate: Installed on 2017-08-26 (33 days ago) InstallationMedia: Ubuntu 17.10 "Artful Aardvark" - Alpha i386 (20170826) SourcePackage: marco UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/mate-desktop/+bug/1720364/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2047356] Re: gvfs-disks2-volume-monitor and gsd-housekeeping processes can eat a lot of CPU with k3s workload
** Description changed: On Ubuntu 22.04.3, when running a k3s workload that uses volumes (using default local-path storageClass), process gvfs-disks2-volume-monitor can take around 100% of one CPU core, and process gsd-housekeeping around 25% of one CPU core. Even if the actual k3s workload is idle. Steps To Reproduce: - Use or install a desktop Ubuntu 22.04.3 (with default settings) - Install K3s on it (current version is "v1.28.4+k3s2"), with default settings: "curl -sfL https://get.k3s.io | sh -" - - Deploy k8s manifests with many volumes, like https://gitlab.com/-/snippets/3634487: "wget https://gitlab.com/-/snippets/3634487/raw/main/deployment-wit-many-volumes.yaml && sudo k3s kubectl apply -f deployment-wit-many-volumes.yaml" + - Deploy k8s manifests with many volumes, like https://gitlab.com/-/snippets/3634487: "wget https://gitlab.com/-/snippets/3634487/raw/main/deployment-with-many-volumes.yaml && sudo k3s kubectl apply -f deployment-with-many-volumes.yaml" - Check CPU consumption on the host, with top, gnome-system-monitor or anything else Expected behavior: Gnome desktop tools should not interfere with k3s. Actual behavior: Processes gvfs-disks2-volume-monitor and gsd-housekeeping consume a lot of CPU, at least at provisioning time. Same CPU consumption if you then remove the workload ("sudo k3s kubectl delete -f deployment-wit-many-volumes.yaml"), until the PVs are deleted by k3s. I have other workloads (with data in PVs) where this CPU consumption is always there, when the workload is running. Additional context: The symptoms are very similar to https://github.com/k3s-io/k3s/issues/522, but the workaround of comment https://github.com/k3s-io/k3s/issues/522#issuecomment-811737023 (adding a udev rule to ignore some loopback devices) does not help. Executing "systemctl stop --user gvfs-udisks2-volume-monitor" can be a temporary workaround Technical details: k3s uses containerd to run containers. The local-path storageClass mounts local volumes (physically stored in /var/lib/rancher/k3s/storage subfolders) in these containers. - I suppose gnome applications try to scan these mount points. In this case, the solution might be to make them ignore them, a bit like https://github.com/moby/moby/blob/b96a0909f0ebc683de817665ff090d57ced6f981/contrib/udev/80-docker.rules does for docker + I suppose gnome applications try to scan these mount points. In this case, the solution might be to make them ignore them, a bit like https://github.com/moby/moby/blob/master/contrib/udev/80-docker.rules does for docker NB: Was initially reported on https://github.com/k3s-io/k3s/issues/9093 ** Description changed: - On Ubuntu 22.04.3, when running a k3s workload that uses volumes (using default local-path storageClass), process gvfs-disks2-volume-monitor can take around 100% of one CPU core, and process gsd-housekeeping around 25% of one CPU core. + On Ubuntu 22.04.3 desktop, when running a k3s workload that uses volumes (using default local-path storageClass), process gvfs-disks2-volume-monitor can take around 100% of one CPU core, and process gsd-housekeeping around 25% of one CPU core. Even if the actual k3s workload is idle. Steps To Reproduce: - Use or install a desktop Ubuntu 22.04.3 (with default settings) - Install K3s on it (current version is "v1.28.4+k3s2"), with default settings: "curl -sfL https://get.k3s.io | sh -" - Deploy k8s manifests with many volumes, like https://gitlab.com/-/snippets/3634487: "wget https://gitlab.com/-/snippets/3634487/raw/main/deployment-with-many-volumes.yaml && sudo k3s kubectl apply -f deployment-with-many-volumes.yaml" - Check CPU consumption on the host, with top, gnome-system-monitor or anything else Expected behavior: Gnome desktop tools should not interfere with k3s. Actual behavior: Processes gvfs-disks2-volume-monitor and gsd-housekeeping consume a lot of CPU, at least at provisioning time. Same CPU consumption if you then remove the workload ("sudo k3s kubectl delete -f deployment-wit-many-volumes.yaml"), until the PVs are deleted by k3s. I have other workloads (with data in PVs) where this CPU consumption is always there, when the workload is running. Additional context: The symptoms are very similar to https://github.com/k3s-io/k3s/issues/522, but the workaround of comment https://github.com/k3s-io/k3s/issues/522#issuecomment-811737023 (adding a udev rule to ignore some loopback devices) does not help. Executing "systemctl stop --user gvfs-udisks2-volume-monitor" can be a temporary workaround Technical details: k3s uses containerd to run containers. The local-path storageClass mounts local volumes (physically stored in /var/lib/rancher/k3s/storage subfolders) in these containers. I suppose gnome applications try to scan these mount points. In this case, the solution might be to make them ignore them, a bit li
[Desktop-packages] [Bug 2047356] Re: gvfs-disks2-volume-monitor and gsd-housekeeping processes can eat a lot of CPU with k3s workload
** Description changed: On Ubuntu 22.04.3, when running a k3s workload that uses volumes (using default local-path storageClass), process gvfs-disks2-volume-monitor can take around 100% of one CPU core, and process gsd-housekeeping around 25% of one CPU core. Even if the actual k3s workload is idle. Steps To Reproduce: - Use or install a desktop Ubuntu 22.04.3 (with default settings) - Install K3s on it (current version is "v1.28.4+k3s2"), with default settings: "curl -sfL https://get.k3s.io | sh -" - Deploy k8s manifests with many volumes, like https://gitlab.com/-/snippets/3634487: "wget https://gitlab.com/-/snippets/3634487/raw/main/deployment-wit-many-volumes.yaml && sudo k3s kubectl apply -f deployment-wit-many-volumes.yaml" - Check CPU consumption on the host, with top, gnome-system-monitor or anything else Expected behavior: Gnome desktop tools should not interfere with k3s. Actual behavior: Processes gvfs-disks2-volume-monitor and gsd-housekeeping consume a lot of CPU, at least at provisioning time. Same CPU consumption if you then remove the workload ("sudo k3s kubectl delete -f deployment-wit-many-volumes.yaml"), until the PVs are deleted by k3s. I have other workloads (with data in PVs) where this CPU consumption is always there, when the workload is running. Additional context: The symptoms are very similar to https://github.com/k3s-io/k3s/issues/522, but the workaround of comment https://github.com/k3s-io/k3s/issues/522#issuecomment-811737023 (adding a udev rule to ignore some loopback devices) does not help. Executing systemctl stop --user gvfs-udisks2-volume-monitor can be a temporary workaround + Technical details: k3s uses containerd to run containers. The local-path storageClass mounts local volumes (physically stored in /var/lib/rancher/k3s/storage subfolders) in these containers. + I suppose gnome applications try to scan these mount points. In this case, the solution might be to make them ignore them, a bit like https://github.com/moby/moby/blob/b96a0909f0ebc683de817665ff090d57ced6f981/contrib/udev/80-docker.rules does for docker + NB: Was initially reported on https://github.com/k3s-io/k3s/issues/9093 ** Description changed: On Ubuntu 22.04.3, when running a k3s workload that uses volumes (using default local-path storageClass), process gvfs-disks2-volume-monitor can take around 100% of one CPU core, and process gsd-housekeeping around 25% of one CPU core. Even if the actual k3s workload is idle. Steps To Reproduce: - Use or install a desktop Ubuntu 22.04.3 (with default settings) - Install K3s on it (current version is "v1.28.4+k3s2"), with default settings: "curl -sfL https://get.k3s.io | sh -" - Deploy k8s manifests with many volumes, like https://gitlab.com/-/snippets/3634487: "wget https://gitlab.com/-/snippets/3634487/raw/main/deployment-wit-many-volumes.yaml && sudo k3s kubectl apply -f deployment-wit-many-volumes.yaml" - Check CPU consumption on the host, with top, gnome-system-monitor or anything else Expected behavior: Gnome desktop tools should not interfere with k3s. Actual behavior: Processes gvfs-disks2-volume-monitor and gsd-housekeeping consume a lot of CPU, at least at provisioning time. Same CPU consumption if you then remove the workload ("sudo k3s kubectl delete -f deployment-wit-many-volumes.yaml"), until the PVs are deleted by k3s. I have other workloads (with data in PVs) where this CPU consumption is always there, when the workload is running. Additional context: The symptoms are very similar to https://github.com/k3s-io/k3s/issues/522, but the workaround of comment https://github.com/k3s-io/k3s/issues/522#issuecomment-811737023 (adding a udev rule to ignore some loopback devices) does not help. - Executing systemctl stop --user gvfs-udisks2-volume-monitor can be a + Executing "systemctl stop --user gvfs-udisks2-volume-monitor" can be a temporary workaround Technical details: k3s uses containerd to run containers. The local-path storageClass mounts local volumes (physically stored in /var/lib/rancher/k3s/storage subfolders) in these containers. I suppose gnome applications try to scan these mount points. In this case, the solution might be to make them ignore them, a bit like https://github.com/moby/moby/blob/b96a0909f0ebc683de817665ff090d57ced6f981/contrib/udev/80-docker.rules does for docker NB: Was initially reported on https://github.com/k3s-io/k3s/issues/9093 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gvfs in Ubuntu. https://bugs.launchpad.net/bugs/2047356 Title: gvfs-disks2-volume-monitor and gsd-housekeeping processes can eat a lot of CPU with k3s workload Status in gvfs package in Ubuntu: New Bug description: On Ubuntu 22.04.3, when running a k3s workload that uses volumes (using default local-path storageClass), proce
[Desktop-packages] [Bug 2047356] [NEW] gvfs-disks2-volume-monitor and gsd-housekeeping processes can eat a lot of CPU with k3s workload
Public bug reported: On Ubuntu 22.04.3, when running a k3s workload that uses volumes (using default local-path storageClass), process gvfs-disks2-volume-monitor can take around 100% of one CPU core, and process gsd-housekeeping around 25% of one CPU core. Even if the actual k3s workload is idle. Steps To Reproduce: - Use or install a desktop Ubuntu 22.04.3 (with default settings) - Install K3s on it (current version is "v1.28.4+k3s2"), with default settings: "curl -sfL https://get.k3s.io | sh -" - Deploy k8s manifests with many volumes, like https://gitlab.com/-/snippets/3634487: "wget https://gitlab.com/-/snippets/3634487/raw/main/deployment-wit-many-volumes.yaml && sudo k3s kubectl apply -f deployment-wit-many-volumes.yaml" - Check CPU consumption on the host, with top, gnome-system-monitor or anything else Expected behavior: Gnome desktop tools should not interfere with k3s. Actual behavior: Processes gvfs-disks2-volume-monitor and gsd-housekeeping consume a lot of CPU, at least at provisioning time. Same CPU consumption if you then remove the workload ("sudo k3s kubectl delete -f deployment-wit-many-volumes.yaml"), until the PVs are deleted by k3s. I have other workloads (with data in PVs) where this CPU consumption is always there, when the workload is running. Additional context: The symptoms are very similar to https://github.com/k3s-io/k3s/issues/522, but the workaround of comment https://github.com/k3s-io/k3s/issues/522#issuecomment-811737023 (adding a udev rule to ignore some loopback devices) does not help. Executing systemctl stop --user gvfs-udisks2-volume-monitor can be a temporary workaround NB: Was initially reported on https://github.com/k3s-io/k3s/issues/9093 ** Affects: gvfs (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gvfs in Ubuntu. https://bugs.launchpad.net/bugs/2047356 Title: gvfs-disks2-volume-monitor and gsd-housekeeping processes can eat a lot of CPU with k3s workload Status in gvfs package in Ubuntu: New Bug description: On Ubuntu 22.04.3, when running a k3s workload that uses volumes (using default local-path storageClass), process gvfs-disks2-volume-monitor can take around 100% of one CPU core, and process gsd-housekeeping around 25% of one CPU core. Even if the actual k3s workload is idle. Steps To Reproduce: - Use or install a desktop Ubuntu 22.04.3 (with default settings) - Install K3s on it (current version is "v1.28.4+k3s2"), with default settings: "curl -sfL https://get.k3s.io | sh -" - Deploy k8s manifests with many volumes, like https://gitlab.com/-/snippets/3634487: "wget https://gitlab.com/-/snippets/3634487/raw/main/deployment-wit-many-volumes.yaml && sudo k3s kubectl apply -f deployment-wit-many-volumes.yaml" - Check CPU consumption on the host, with top, gnome-system-monitor or anything else Expected behavior: Gnome desktop tools should not interfere with k3s. Actual behavior: Processes gvfs-disks2-volume-monitor and gsd-housekeeping consume a lot of CPU, at least at provisioning time. Same CPU consumption if you then remove the workload ("sudo k3s kubectl delete -f deployment-wit-many-volumes.yaml"), until the PVs are deleted by k3s. I have other workloads (with data in PVs) where this CPU consumption is always there, when the workload is running. Additional context: The symptoms are very similar to https://github.com/k3s-io/k3s/issues/522, but the workaround of comment https://github.com/k3s-io/k3s/issues/522#issuecomment-811737023 (adding a udev rule to ignore some loopback devices) does not help. Executing systemctl stop --user gvfs-udisks2-volume-monitor can be a temporary workaround NB: Was initially reported on https://github.com/k3s-io/k3s/issues/9093 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/2047356/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2036315] Re: sol takes a long time to start
Thanks nwkee, your solution solved my problem as well. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to aisleriot in Ubuntu. https://bugs.launchpad.net/bugs/2036315 Title: sol takes a long time to start Status in aisleriot package in Ubuntu: Confirmed Bug description: sol takes a long time to start I see a msg: corrado@corrado-n12-mm-0915:~$ sol ;;; note: source file /usr/share/guile/3.0/ice-9/eval.scm ;;; newer than compiled /usr/lib/x86_64-linux-gnu/guile/3.0/ccache/ice-9/eval.go ProblemType: Bug DistroRelease: Ubuntu 23.10 Package: aisleriot 1:3.22.23-1 ProcVersionSignature: Ubuntu 6.5.0-5.5-generic 6.5.0 Uname: Linux 6.5.0-5-generic x86_64 ApportVersion: 2.27.0-0ubuntu2 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Sat Sep 16 17:01:29 2023 InstallationDate: Installed on 2023-09-15 (1 days ago) InstallationMedia: Ubuntu 23.10 "Mantic Minotaur" - Daily amd64 (20230915) ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR= SourcePackage: aisleriot UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aisleriot/+bug/2036315/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp