I’m having the exact same problem with pam as well, and this is really frustrating, because it really affects a LOT of aspects of the system, and contrary to that post, restarting the units do not fix the problem at all.
First of all, the obvious ones include the 30s sudo authentication delay and 30s freezes on the lock screen. Additionally, gnome-calendar will not launch anymore because systemd-timedated.service is failing, gnome-control-center will also lock up for 30s if I click on some tabs such as “Sharing”, gnome’s dock and application menu will stay blank for 30s on startup as well.
This is a fresh F32 installation that is only 3 weeks old, I don’t know why it’s already breaking down. I’m pretty sure this is a selinux related problem but I have no experience with selinux, so I don’t know where should I begin to start the troubleshooting process. Please let me know if you need more info.
$ systemctl list-units --state=failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● fprintd.service loaded failed failed Fingerprint Authentication Daemon
● systemd-timedated.service loaded failed failed Time & Date Service
$ sudo systemctl status systemd-timedated.service
● systemd-timedated.service - Time & Date Service
Loaded: loaded (/usr/lib/systemd/system/systemd-timedated.service; static; vendor preset: disabled)
Active: failed (Result: exit-code) since 4min 42s ago
Docs: man:systemd-timedated.service(8)
man:localtime(5)
https://www.freedesktop.org/wiki/Software/systemd/timedated
Process: 11314 ExecStart=/usr/lib/systemd/systemd-timedated (code=exited, status=226/NAMESPACE)
Main PID: 11314 (code=exited, status=226/NAMESPACE)
CPU: 10ms
systemd[1]: Starting Time & Date Service...
systemd[11314]: systemd-timedated.service: Failed to set up mount namespacing: /run/systemd/unit-root/: Permission denied
systemd[11314]: systemd-timedated.service: Failed at step NAMESPACE spawning /usr/lib/systemd/systemd-timedated: Permission denied
systemd[1]: systemd-timedated.service: Main process exited, code=exited, status=226/NAMESPACE
systemd[1]: systemd-timedated.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Time & Date Service.
$ sudo systemctl status fprintd.service
● fprintd.service - Fingerprint Authentication Daemon
Loaded: loaded (/usr/lib/systemd/system/fprintd.service; static; vendor preset: disabled)
Active: failed (Result: exit-code) since 5min ago
Docs: man:fprintd(1)
Process: 11285 ExecStart=/usr/libexec/fprintd (code=exited, status=226/NAMESPACE)
Main PID: 11285 (code=exited, status=226/NAMESPACE)
CPU: 7ms
systemd[1]: Starting Fingerprint Authentication Daemon...
systemd[1]: fprintd.service: Main process exited, code=exited, status=226/NAMESPACE
systemd[1]: fprintd.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Fingerprint Authentication Daemon.
Welcome to the forum! Please read the “Getting Started” topic to be up to date on how to best get help and help others here.
You said this is a new install so:
Have you done a full update since the install? If not then please do so.
“sudo dnf update -y” will handle that.
If the problem is still there then try the steps below.
If you suspect selinux then the first thing I would suggest is to do is check that out.
a) Check the status of selinux. “sudo getenforce” will return the current status, which should be one of enforcing, permissive, or disabled
If that result is “enforcing” you can temporarily disable enforcing to see if that changes anything by doing “sudo setenforce 0” then see if there are changes in the system response. The next reboot will reset selinux to the default enforcing type as defined in /etc/selinux/config.
b) try relabeling the system in case selinux has something to do with causing the hangs. “sudo touch /.autorelabel” followed by a reboot will handle that.
c) To change the default selinux setting you can change the value in /etc/selinux/config to which ever type you want, enforcing, permissive, or disabled.
For detailed information on selinux and how to manage it you can look at the man pages for selinux, setenforce, getenforce, and others that will tell you how to use them.
I just did that and rebooted right before I wrote the post to make sure it wasn’t something that has already been fixed, so I’m sure everything is up to date.
Switching selinux to permissive made the two failing systemd services able to be started once again, which got rid of the sudo and lockscreen delays as expected, and gnome-calendar works once again. However, gnome-control-center is still hanging if I click on the “Sharing” tab, and I haven’t tested the blank dock/application menu because I haven’t rebooted yet.
Additionally, I wasn’t aware of the /.autorelabel thing before, so I simply tried reinstalling selinux-policy-targeted, which did not work. I’ll reboot in a bit and see if relabelling the fs (with /.autorelabel placed) fixes the problem.
The filesystem has been relabeled but the situation did not improve, I’m seeing 3 failing units now:
$ systemctl list-units --state=failed
UNIT LOAD ACTIVE SUB DESCRIPTION
● fprintd.service loaded failed failed Fingerprint Authentication Daemon
● systemd-hostnamed.service loaded failed failed Hostname Service
● systemd-timedated.service loaded failed failed Time & Date Service
After setting selinux back to permissive, and restarting the 3 services, everything works once again. I really don’t want to disable selinux permanently, is there anything else I can try other than reinstalling?
If you set selinux to permissive it will still give you warnings about errors. That would at least allow the system to operate while you identify the cause.
There is the possibility that the install somehow caused an error that is triggering selinux to halt the services and a reinstall could fix that.
There is also the possibility that a disk error caused it, and you might be able to test for that using smartctl and look for errors already reported or run a test yourself just in case.
Having a new service that is failing causes me to suspect some form of filesystem corruption that may be growing…
Additionally, I did check the SMART and there are no errors. I don’t have any disk/fs related problems in the kernel log buffer either. Since my / is on btrfs, I also did a scrub, and that returned clean as well.
Update: the units have started failing once again on next reboot. I did dnf reinstall *selinux* and another autorelabel, now it’s working fine again. I’m pretty sure units will start failing once again on next reboot.
If your problems continue you might look at several of the helps that can be found by a quick google search for “selinux troubleshooter fedora” this is one that popped up for me. As you know you can see the errors posted by selinux by using the cli command
Those errors will lead you to the specific problem if you read them but other than telling you what the error is they are not a lot of help.
I find selinux tools that can be very helpful are the troubleshooter and toolbox. “sudo dnf install setroubleshoot setools”.
These are tools that will help you identify and fix problems related to selinux. If you are using the gnome desktop and have both those installed they should give you alerts when they occur, and suggest how to fix the problem.
This is more detailed info on how to troubleshoot selinux and tools to help.
Something is wrong in your file system if you have files with the unlabled_t type. In this blog post Dan Walsh discusses a number of possible causes. I don’t know if any might apply to you.
Unfortunately, your AVC:s don’t mention more exactly what it is that is unlabeled. When I’ve seen it previously, the message has typically included a path or inode that could be used to find the problem. I’m not sure why you don’t see it. A brute force method would be
sudo find / -context '*unlabeled_t*'
Run this in when in enforcing mode, so the mount will actually fail.
I set selinux back to enforcing, restarted all 3 aforementioned services, but they don’t seem to be failing anymore. I tried looking for unlabelled files under / but didn’t find any:
This problem is incredibly intermittent and I still have not been able to pin it down. I have set selinux to permissive for now because I don’t really have enough time to waste on this at the moment.
Problem here is that anything under /run/media should not prevent the aforementioned 3 services from starting at all. These are mounts that typically a DE would mount drives to. My files on these removable drives certainly do not have the correct selinux context, but why should they? I’m not running any binaries or having any system services depend on my files on there.
Having binaries or system services dependent upon the files has no relevance to the need for selinux context. Simply look at the files in and under your user home directory with “ls -lZ” and you will see what I mean. I do not think the DE handles the mounting there, but rather I think systemd is involved in that.
Selinux enforces the security context on all files possible on all accessible devices and warns you or prevents access if the context is not correct. It obviously cannot write the context to files in vfat or ntfs formatted filesystems, but it can warn or prevent access there dependent upon the policy in effect.
Try booting with the USB devices unplugged; then, after you have signed in, attach them and see if the same errors occur. It seems possible that selinux may be interfering before it fully initializes the system if it cannot properly read the device during startup.
Wow, I really wasn’t expecting that but when I removed the USB SD card reader I had plugged in and rebooted, it all started working again. I was having the exact same failed units as @ahrb but now settings/lock screen/sudo are back to normal speed.