Why are there ten packages listed later in the current topic here compared to big other-topic list?
Above is about 103 Upgraded packages, plus other changes. One that’s particularly interesting is:
sssd-2.7.3-1.fc35.x86_64
because of
All SSSD client libraries (nss, pam, etc) won’t serialize requests anymore by default, i.e. requests from multiple threads can be executed in parallel. Old behavior (serialization) can be enabled by setting environment variable “SSS_LOCKFREE” to “NO”.
suggests that client libraries from the project include libnss_sss.so, used by clients such as glibc.
Anybody know SSSD well? Anybody know DNF well? There appear to be ways to undo or rollback.
History Command (dnf.readthedocs.io)
although from what I found from Google, it’s uncertain, and is subject to what old versions are kept.
Basically, what’s the Fedora debug/recovery/workaround when one updates it and it breaks things?
EDIT 1:
I suppose one might try ls -lc /lib64/libnss_sss.so.2 to see if time is near the breakage time.
If that’s not it, maybe dnf fishing can give other suspects that changed around when Duplicati broke.
EDIT 2:
Troubleshooting Basics (sssd.io) shows how to use debug logs and other things. Maybe it can help?
Chasing issues deep below Duplicati (all the way on the far side of mono) will need what we can find.
Ultimately, to get a fix from some other project will need a report to it, and preferably a nice test case, preferably (typically) something direct to make it as obvious as possible how the library had been run.
Regarding backing out changes, I don’t know how well Fedora puts up with that, but repology.org has:
Given that 2.7.3 may be very recent, there might be few dependencies on it from other projects so far.
I’m picking on sssd partly because of their 2.7.3 release note, and because that’s the last step shown before pthread_mutex_lock seemingly declared something was wrong (what an assert typically does).