Bug 1653759

Summary:	sss_cache shouldn't return ENOENT when no entries match
Product:	Red Hat Enterprise Linux 7	Reporter:	German Parente <gparente>
Component:	sssd	Assignee:	SSSD Maintainers <sssd-maint>
Status:	CLOSED ERRATA	QA Contact:	Madhuri <mupadhye>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.6	CC:	grajaiya, jhrozek, lslebodn, mupadhye, mzidek, pbrezina, sgoveas, tscherf
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	sssd-1.16.4-1.el7	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-08-06 13:02:13 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description German Parente 2018-11-27 15:17:48 UTC

Description of problem:

a customer was complaining about sss_cache returning 2, ENOENT ( no entries invalidated in the cache ).

We believe the error code is valid and quite accurate. But perhaps we will need to document this in the man pages of sss_cache.

Or even think about the possibility of always returning 0 since "no entries invalidated" is also successful.

Comment 2 Jakub Hrozek 2018-11-27 20:05:45 UTC

(In reply to German Parente from comment #0)
> Or even think about the possibility of always returning 0 since "no entries
> invalidated" is also successful.

I agree the return code is a bit too strict, that's what I also suggested in the idm-tech thread where this issue was first reported:
http://post-office.corp.redhat.com/archives/idm-tech/2018-November/msg00185.html

but I couldn't reproduce it locally with a quick test.

Comment 4 Jakub Hrozek 2018-12-05 21:18:53 UTC

Upstream ticket:
https://pagure.io/SSSD/sssd/issue/3896

Comment 5 Jakub Hrozek 2019-01-28 20:36:47 UTC

Upstream ticket:
https://pagure.io/SSSD/sssd/issue/3919

Comment 6 Jakub Hrozek 2019-01-29 19:58:15 UTC

* master:
 * 415094687e92789060626176c5ced31d4122692d
 * 71475f1ed78a65d78f75e5ca0fdc6e20cfdf2f39
 * 325df4acae303efeabd96d2247fb5799c728536a
 * 88c0c3fcd1d97bd499bb28c2065ba19d629fa4f7

Comment 7 Jakub Hrozek 2019-01-29 20:00:24 UTC

* sssd-1-16:
 * 7983826c3c3736d71bd4447be5f178521b809d64
 * 498aaac23db9334ec83de72c8b6c4fbf708120b2
 * 0a27a4716adcb2d08e08db3ed719a156691106e7
 * 8e6c52f6b043cb4f7b4065ab6a9012a5c1acbf8f

Comment 12 Madhuri 2019-06-18 09:40:54 UTC

Verified with:
[root@qe-blade-09 ~]# rpm -qa sssd
sssd-1.16.4-21.el7.x86_64

Verification steps:

1) Remove sssd cache
[root@qe-blade-09 ~]# rm -rf /var/lib/sss/db/*

2) Restart sssd
[root@qe-blade-09 ~]# systemctl restart sssd

3) Invalidate all groups cache and check return code

[root@qe-blade-09 ~]# sss_cache -G

[root@qe-blade-09 ~]# echo $?
0

4) Invalidate all users cache and check return code

[root@qe-blade-09 ~]# sss_cache -U

[root@qe-blade-09 ~]# echo $?
0

5) Invalidate everything and check return code

[root@qe-blade-09 ~]# sss_cache -E

[root@qe-blade-09 ~]# echo $?
0

Thus from above steps marking this bug as Verified.

Comment 14 errata-xmlrpc 2019-08-06 13:02:13 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:2177