Minor What were you trying to do that didn't work?
After sssd update, sssd fails to start with error
[sss_cache] [sysdb_domain_cache_connect] (0x0010): DB version too old [0.23], expected [0.24]
Please provide the package NVR for which bug is seen:
sssd-2.9.4-3.el8_10.x86_64
Steps to reproduce
- Upgrade sssd from a version that uses older DB version
- try to start sssd
- sssd fails with
[sss_cache] [sysdb_domain_cache_connect] (0x0010): DB version too old [0.23], expected [0.24] for domain implicit_files! Higher version of database is expected! In order to upgrade the database, you must run SSSD. Removing cache files in /var/lib/sss/db should fix the issue, but note that removing cache files will also remove all of your cached credentials.
Expected results
If cache is invalid for currently installed sssd version, there is little sense to keeping it. We should either remove it automatically, or back it up and create new cache.
Actual results
SSSD fails until manual intervention
- duplicates
-
RHEL-56352 Disable shadow-utils/SSSD integration by default
-
- Closed
-
- is blocked by
-
-
- Closed
-
[RHEL-52842] SSSD DB version too old after upgrade
All the tickets around `sss_cache` unexpected logs when called from shadow-utils are quite annoying.
We can't just suppress those messages because we do want them when `sss_cache` is called manually (there are also issues to fix but that's another story).
But we really don't want them when called from user/group add/del etc.
Getting `getppid()` and then reading /proc/$ppid to check if we run from shadow-utils is too cumbersome (and a number of tools that call sss_cache is too high)
More reliable option is to close stdout or provide command line arg / env variable from shadow to sss_cache (to let it know to avoid writing any logs). But this requires shadow-utils patch (upstream or downstream only) for a functionality that we want to eventually remove completely – wasted effort.
I think the best way is to disable shadow-utils/sssd integration in RHEL9 (RHEL-56352, RHEL-56786) starting 9.4.z (it is already disabled in RHEL 10).
Issue won't be fixed in RHEL8 (as a reminder: a trivial resolution is `sudo rm -rf /var/lib/sss/db/*`)
Alexey Tikhonov
added a comment - - edited All the tickets around `sss_cache` unexpected logs when called from shadow-utils are quite annoying.
We can't just suppress those messages because we do want them when `sss_cache` is called manually (there are also issues to fix but that's another story).
But we really don't want them when called from user/group add/del etc.
Getting `getppid()` and then reading /proc/$ppid to check if we run from shadow-utils is too cumbersome (and a number of tools that call sss_cache is too high)
More reliable option is to close stdout or provide command line arg / env variable from shadow to sss_cache (to let it know to avoid writing any logs). But this requires shadow-utils patch (upstream or downstream only) for a functionality that we want to eventually remove completely – wasted effort.
I think the best way is to disable shadow-utils/sssd integration in RHEL9 ( RHEL-56352 , RHEL-56786) starting 9.4.z (it is already disabled in RHEL 10).
Issue won't be fixed in RHEL8 (as a reminder: a trivial resolution is `sudo rm -rf /var/lib/sss/db/*`) 
Klaas Demter
added a comment - > instead just do `rm -rf /var/lib/sss/db/*`. Actually entire `Resolution` can be simplified to this.
I recommended the same in a comment on the kbase article, maybe you can figure out internally (I am not a red hat employee) who is in charge of that article and get him to change it, there is another kbase article related to this issue: https://access.redhat.com/solutions/3407081 which seems to be more about sssd not updating it's cache which I guess was a bug some version of sssd in rhel7?
> Because if SSSD runs it will upgrade cache automatically. If it doesn't run there is no need to keep the cache.
if that is the case you can just check for sssd running (or sssd configured) in rpm post scripts and remove those files, right?
Klaas Demter
added a comment - > instead just do `rm -rf /var/lib/sss/db/*`. Actually entire `Resolution` can be simplified to this.
I recommended the same in a comment on the kbase article, maybe you can figure out internally (I am not a red hat employee) who is in charge of that article and get him to change it, there is another kbase article related to this issue: https://access.redhat.com/solutions/3407081 which seems to be more about sssd not updating it's cache which I guess was a bug some version of sssd in rhel7?
> Because if SSSD runs it will upgrade cache automatically. If it doesn't run there is no need to keep the cache.
if that is the case you can just check for sssd running (or sssd configured) in rpm post scripts and remove those files, right?
Alexey Tikhonov
added a comment - > and the related kbase article https://access.redhat.com/solutions/7031304
As I pointed out elsewhere I disagree with the recommendation
```
Note: When there is no /etc/sssd/sssd.conf, you need to make it as follows and you should delete it later.
```
– instead just do `rm -rf /var/lib/sss/db/*`. Actually entire `Resolution` can be simplified to this.
Because if SSSD runs it will upgrade cache automatically. If it doesn't run there is no need to keep the cache.
Alexey Tikhonov
added a comment - > and the related kbase article https://access.redhat.com/solutions/7031304
As I pointed out elsewhere I disagree with the recommendation
```
Note: When there is no /etc/sssd/sssd.conf, you need to make it as follows and you should delete it later.
```
– instead just do `rm -rf /var/lib/sss/db/*`. Actually entire `Resolution` can be simplified to this.
Because if SSSD runs it will upgrade cache automatically. If it doesn't run there is no need to keep the cache. Klaas Demter
added a comment - If sssd is not running/configured you should definitely remove the cache files unconditionally
If sssd is running and working I would expect sssd to migrate the cache files to a new version because the expected behavior is that the cached credentials are there until they expire, not until someone updates sssd, right?
Klaas Demter
added a comment - If sssd is not running/configured you should definitely remove the cache files unconditionally
If sssd is running and working I would expect sssd to migrate the cache files to a new version because the expected behavior is that the cached credentials are there until they expire, not until someone updates sssd, right? Klaas Demter
added a comment - and the related kbase article https://access.redhat.com/solutions/7031304
Klaas Demter
added a comment - and the related kbase article https://access.redhat.com/solutions/7031304 Klaas Demter
added a comment - related customer case 03890423 > try to start sssd
> sssd fails with
But log is from 'sss_cache' (not from SSSD)
Reason of "issue":
- default value of `enable_files_domain` changed to false
- so that not-explicitly-configured SSSD doesn't run automatically anymore
- but left over cache files are present on the disk
- `sss_cache` (being called from shadow-utils' user add/del) complains that version of cache db is too old
This is harmless and work-around is trivial - `rm -rf /var/lib/sss/db/*`
Alexey Tikhonov
added a comment - - edited > try to start sssd
> sssd fails with
But log is from 'sss_cache' (not from SSSD)
Reason of "issue":
default value of `enable_files_domain` changed to false
so that not-explicitly-configured SSSD doesn't run automatically anymore
but left over cache files are present on the disk
`sss_cache` (being called from shadow-utils' user add/del) complains that version of cache db is too old
This is harmless and work-around is trivial - `rm -rf /var/lib/sss/db/*` 
https://access.redhat.com/solutions/7031304 still has an incorrect solution