[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:
[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
[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),
[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
