Heya. After an unknown point in the recent month or so, I’ve encountered that I can no longer log in to my Cockpit dashboard. When accessing it over a domain name, it displays Internal server error, and acessing it from the local network says The cockpit package is not installed.
I’ve double checked that it is in fact installed and that the service is running, and tried updating it and related packages. Nothing changed. Systemctl logs show nothing other successful start messages.
Now, running journalctl -f when trying to log in displays this:
Error log
systemd[81362]: setroubleshootd.service: Failed to execute /usr/sbin/setroubleshootd: Permission denied
systemd[81362]: setroubleshootd.service: Failed at step EXEC spawning /usr/sbin/setroubleshootd: Permission denied
systemd-logind[2445]: Removed session 7.
systemd[1]: setroubleshootd.service: Main process exited, code=exited, status=203/EXEC
systemd[1]: setroubleshootd.service: Failed with result 'exit-code'.
systemd[1]: Failed to start SETroubleshoot daemon for processing new SELinux denial logs.
Which points to some sort of issue with setroubleshootd. Running systemctl status setroubleshootd gives the same output as above. I’ve tried updating and reinstalling the package to no avail. Running /usr/sbin/setroubleshootd as root gives this:
org.freedesktop.DBus.Error.AccessDenied: Request to own name refused by policy
My only assumption is that something went wrong with SELinux, but I have no expertise in it, so can’t tell for sure. I’ve tried running sudo semanage fcontext -l | grep setroubleshootd, and this was the result, which seems to be perfectly fine:
Error log
/usr/sbin/setroubleshootd regular file system_u:object_r:setroubleshootd_exec_t:s0
/usr/share/setroubleshoot/SetroubleshootFixit\.py* regular file system_u:object_r:setroubleshoot_fixit_exec_t:s0
/var/lib/setroubleshoot(/.*)? all files system_u:object_r:setroubleshoot_var_lib_t:s0
/var/log/setroubleshoot(/.*)? all files system_u:object_r:setroubleshoot_var_log_t:s0
/var/run/setroubleshoot(/.*)? all files system_u:object_r:setroubleshoot_var_run_t:s0
This was the case until I ran a full system update just while writing this. The funny thing is that I’ve also done one between the start of the issue and today, and it didn’t help then.
Posting this anyway, just so that it’s easier to search this error in the future, and in case anyone has any valuable input as to what the cause might have been.