Well my Fedora 33 workstation desktop kept freezing and crashing whether I used KDE Plasma, Cinnamon, MATE or Gnome desktop environments this happened with various applications. I suspected my Nvidia Quadro K1200 drivers and was going to really dive into that when I had time. I first updated to Fedora 34 which I wanted to do anyway and had the same issues so looking through the logs and then noticed some selinux alerts I simply ran the sealerts listed and created selinux policies suggested and now my workstation’s desktop is noticeably more responsive and stable.

This is what I found in the logs:

SELinux is preventing gnome-shell from write access on the sock_file dbus-O849AHv64T.

Plugin catchall (100. confidence) suggests *

If you believe that gnome-shell should be allowed write access on the dbus-O849AHv64T sock_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:

ausearch -c ‘gnome-shell’ –raw | audit2allow -M my-gnomeshell

semodule -X 300 -i my-gnomeshell.pp

Additional Information:
Source Context system_u:system_r:xdm_t:s0-s0:c0.c1023
Target Context system_u:object_r:tmp_t:s0
Target Objects dbus-O849AHv64T [ sock_file ]
Source gnome-shell
Source Path gnome-shell
Port
Host mamba
Source RPM Packages
Target RPM Packages
SELinux Policy RPM selinux-policy-targeted-34.14-1.fc34.noarch
Local Policy RPM selinux-policy-targeted-34.14-1.fc34.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name mamba
Platform Linux mamba 5.13.4-200.fc34.x86_64 #1 SMP Tue Jul
20 20:27:29 UTC 2021 x86_64 x86_64
Alert Count 223
First Seen 2021-07-12 22:03:50 PDT
Last Seen 2021-07-23 22:38:07 PDT
Local ID c4845b11-2638-4728-8e79-27e115f54210

Raw Audit Messages
type=AVC msg=audit(1627105087.981:551): avc: denied { write } for pid=27398 comm=”gsd-power” name=”dbus-O849AHv64T” dev=”tmpfs” ino=657 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmp_t:s0 tclass=sock_file permissive=0

Hash: gnome-shell,xdm_t,tmp_t,sock_file,write

For this alert I simply followed directions after changing directories into my security folder I store my selinux policies and then ran:

# ausearch -c 'gnome-shell' --raw | audit2allow -M my-gnomeshell
#semodule -i my-gnomeshell.pp

There appeared to be another sealert that I found that also affected my desktops stability and possibly spoke to issues with the Nvidia driver:

SELinux is preventing gdb from read access on the chr_file card1.

Plugin catchall (100. confidence) suggests *

If you believe that gdb should be allowed read access on the card1 chr_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:

ausearch -c ‘gdb’ –raw | audit2allow -M my-gdb

semodule -X 300 -i my-gdb.pp

Additional Information:
Source Context system_u:system_r:abrt_t:s0-s0:c0.c1023
Target Context system_u:object_r:dri_device_t:s0
Target Objects card1 [ chr_file ]
Source gdb
Source Path gdb
Port
Host mamba
Source RPM Packages
Target RPM Packages
SELinux Policy RPM selinux-policy-targeted-34.14-1.fc34.noarch
Local Policy RPM selinux-policy-targeted-34.14-1.fc34.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name mamba
Platform Linux mamba 5.13.4-200.fc34.x86_64 #1 SMP Tue Jul
20 20:27:29 UTC 2021 x86_64 x86_64
Alert Count 384
First Seen 2021-07-12 22:04:07 PDT
Last Seen 2021-07-23 22:38:06 PDT
Local ID 88f4d8fa-ca05-404e-8449-bd42cfc3bedb

Raw Audit Messages
type=AVC msg=audit(1627105086.850:543): avc: denied { read } for pid=27221 comm=”gdb” name=”card1″ dev=”devtmpfs” ino=523 scontext=system_u:system_r:abrt_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dri_device_t:s0 tclass=chr_file permissive=0

Hash: gdb,abrt_t,dri_device_t,chr_file,read

Once again I just followed the notice from selinux and ran the following:

#ausearch -c 'gdb' --raw | audit2allow -M my-gdb
#semodule -i my-gdb.pp

For the second alert addressing the “gdb” issue I discovered a number of people are having similar issues that are listed in bug alerts at Red Hat: https://bugzilla.redhat.com/show_bug.cgi?id=1896648

I decided to look up the first sealert as well and there are a number of bug listings for that as well plus a forum discussion I found: https://ask.fedoraproject.org/t/selinux-is-preventing-gnome-shell-from-write-access-on-the-sock-file-dbus-xodxlwour5/14515

https://bugzilla.redhat.com/show_bug.cgi?id=1942775

I also went ahead migrated virtual systems from one XCP-ng to another updated both XCP-ng hosts hypervisor systems after the migrations and then moved the virtual systems back to their respective hosts after performing the updates on each physical host. During the migration of the relays server that brief microsecond may have affected people streaming Snakeice’s House of Beats without a media streaming player that buffers and does not attempt restarts after minor interruptions .. All in all a very productive morning now time for breakfast.