[SSSD] [sssd PR#5539][comment] [WIP] NSS: Clear negative cache when SIGHUP received

[alexey-tikhonov]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: [WIP] NSS: Clear negative cache when SIGHUP received

alexey-tikhonov commented:
"""

Two lock files would be overkill. One is enough and can be used for both - memcache and negcache. The purpose of this file is to identify SIGHUP received from sss_cache command as only this one should trigger cache clearing.

I'm not sure that's the main purpose.
I think the purpose also was to have a way to notify `sss_cache` that operation is finished.
But as I wrote, I'm not convinced this is really needed.
"""

See the full comment at https://github.com/SSSD/sssd/pull/5539#issuecomment-802807347

[elkoniu]

URL: https://github.com/SSSD/sssd/pull/5539
Author: elkoniu
Title: #5539: [WIP] NSS: Clear negative cache when SIGHUP received
Action: synchronized

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/5539/head:pr5539
git checkout pr5539

[elkoniu]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: [WIP] NSS: Clear negative cache when SIGHUP received

elkoniu commented:
"""

And please, if you think some comments are worth addition, feel free to do so but please keep this as a separate patch. This would make `diff` easier to understand.

I will split it into few commits when we agree that technical part is working correct.

But I would question "why" the same signal SIGHUP was re-used both for log rotation and mem-cache clearance. As a result, sss_cache triggers logs rotation. Is it intentional?

This is a good point, I think it may also contribute to the whole "slow files provider" issue. But I think this should be addressed in separated PR / Issue.

And for the purpose of backward notification (if needed at all) sss_cache could monitor mem-cache files itself.

I think approach with flag file was just simplest one. Also this way sss_cache needs to care only about one file no mater how many cache files will be on SSSD side and how they will be implemented.

You don't need to touch permanent entries to resolve this issue.

Here let me quote @sumit-bose [https://github.com/SSSD/sssd/issues/4973]
```
Hi,

you should check with @mzidek about his plans.

About the tricky part, the memory used by the in-memory tdb is not freed if individual entries are removed
so you have to close and open the tbd to get back the memory. Now you should not forget to add
the permanent entries again, but calling sss_ncache_reset_repopulate_permanent() should be sufficient here.

HTH

bye,
Sumit
```
"""

See the full comment at https://github.com/SSSD/sssd/pull/5539#issuecomment-802946884

[alexey-tikhonov]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: [WIP] NSS: Clear negative cache when SIGHUP received

alexey-tikhonov commented:
"""

Two lock files would be overkill. One is enough and can be used for both - memcache and negcache. The purpose of this file is to identify SIGHUP received from sss_cache command as only this one should trigger cache clearing.

I don't think that's the purpose.
I think the purpose is to have a way to notify `sss_cache` that operation is finished.
But as I wrote, I'm not convinced this is really needed.
"""

See the full comment at https://github.com/SSSD/sssd/pull/5539#issuecomment-802807347

[elkoniu]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: [WIP] NSS: Clear negative cache when SIGHUP received

elkoniu commented:
"""

And please, if you think some comments are worth addition, feel free to do so but please keep this as a separate patch. This would make `diff` easier to understand.

I will split it into few commits when we agree that technical part is working correct.

But I would question "why" the same signal SIGHUP was re-used both for log rotation and mem-cache clearance. As a result, sss_cache triggers logs rotation. Is it intentional?

This is a good point, I think it may also contribute to the whole "slow files provider" issue. But I think this should be addressed in separated PR / Issue.

And for the purpose of backward notification (if needed at all) sss_cache could monitor mem-cache files itself.

I think approach with flag file was just simplest one. Also this way sss_cache needs to care only about one file no mater how many cache files will be on SSSD side and how they will be implemented.

You don't need to touch permanent entries to resolve this issue.

Here let me quote @sumit-bose [https://github.com/SSSD/sssd/issues/4973]
```
Hi,

you should check with @mzidek about his plans.

About the tricky part, the memory used by the in-memory tdb is not freed if individual entries are removed so you have
to close and open the tbd to get back the memory. Now you should not forget to add the permanent entries again,
but calling sss_ncache_reset_repopulate_permanent() should be sufficient here.

HTH

bye,
Sumit
```
"""

See the full comment at https://github.com/SSSD/sssd/pull/5539#issuecomment-802946884

[elkoniu]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: [WIP] NSS: Clear negative cache when SIGHUP received

elkoniu commented:
"""
```
<interface name="sssd.Responder.NegativeCache">
<annotation name="codegen.Name" value="resp_negcache" />
<annotation name="codegen.SyncCaller" value="false" />
<method name="ResetUsers" key="True" />
<method name="ResetGroups" key="True" />
</interface>
```
@alexey-tikhonov If I understand correct you suggest to update `sssd.Responder.NegativeCache` with `RepopulatePermament` and then use this API instead of generic `sssd.service` one (`"clearMemcache"` / `"clearNegCache"`)?
"""

See the full comment at https://github.com/SSSD/sssd/pull/5539#issuecomment-802365243

[elkoniu]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: [WIP] NSS: Clear negative cache when SIGHUP received

elkoniu commented:
"""

And please, if you think some comments are worth addition, feel free to do so but please keep this as a separate patch. This would make `diff` easier to understand.

I will split it into few commits when we agree that technical part is working correct.

But I would question "why" the same signal SIGHUP was re-used both for log rotation and mem-cache clearance. As a result, sss_cache triggers logs rotation. Is it intentional?

This is a good point, I think it may also contribute to the whole "slow files provider" issue. But I think this should be addressed in separated PR / Issue.

And for the purpose of backward notification (if needed at all) sss_cache could monitor mem-cache files itself.

I think approach with flag file was just simplest one. Also this way sss_cache needs to care only about one file no mater how many cache files will be on SSSD side and how they will be implemented.

You don't need to touch permanent entries to resolve this issue.

Here let me quote @sumit-bose [https://github.com/SSSD/sssd/issues/4973]
```
Hi,

you should check with @mzidek about his plans.

About the tricky part, the memory used by the in-memory tdb is not freed if individual entries are removed so you have to close and open the tbd to get back the memory. Now you should not forget to add the permanent entries again, but calling sss_ncache_reset_repopulate_permanent() should be sufficient here.

HTH

bye,
Sumit
```
"""

See the full comment at https://github.com/SSSD/sssd/pull/5539#issuecomment-802946884

[alexey-tikhonov]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: [WIP] NSS: Clear negative cache when SIGHUP received

alexey-tikhonov commented:
"""

The purpose of this file is to identify SIGHUP received from sss_cache command as only this one should trigger cache clearing.

You are correct that this is one of purposes (besides notification that operation completed).

99c99e5570

But I would question "why" the same signal SIGHUP was re-used both for log rotation and mem-cache clearance. As a result, `sss_cache` triggers logs rotation. Is it intentional?

Decoupling this would make this purpose obsolete.
And for the purpose of backward notification (if needed at all) sss_cache could monitor mem-cache files itself.

This might be out of the scope of this ticket. But useful to keep in mind.
"""

See the full comment at https://github.com/SSSD/sssd/pull/5539#issuecomment-802857641

[elkoniu]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: [WIP] NSS: Clear negative cache when SIGHUP received

elkoniu commented:
"""

This PR missing flag / lock file implementation. Will be updated soon and then suitable for review.

I'm not convinced it is really needed. And especially I wouldn't like to duplicate this code, i.e. to have two lock files created/watched by single SIGHUP.

Two lock files would be overkill. One is enough and can be used for both - memcache and negcache. The purpose of this file is to identify SIGHUP received from sss_cache command as only this one should trigger cache clearing.
"""

See the full comment at https://github.com/SSSD/sssd/pull/5539#issuecomment-802359827

[alexey-tikhonov]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: [WIP] NSS: Clear negative cache when SIGHUP received

alexey-tikhonov commented:
"""
And please, if you think some comments are worth addition, feel free to do so but please keep this as a separate patch. This would make `diff` easier to understand.
"""

See the full comment at https://github.com/SSSD/sssd/pull/5539#issuecomment-802860519

[alexey-tikhonov]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: [WIP] NSS: Clear negative cache when SIGHUP received

alexey-tikhonov commented:
"""

This PR missing flag / lock file implementation. Will be updated soon and then suitable for review.

I'm not convinced it is really needed. And especially I wouldn't like to duplicate this code, i.e. to have two lock files created/watched by single SIGHUP.
"""

See the full comment at https://github.com/SSSD/sssd/pull/5539#issuecomment-802099860

[alexey-tikhonov]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: [WIP] NSS: Clear negative cache when SIGHUP received

alexey-tikhonov commented:
"""

Post by elkoniu

But I would question "why" the same signal SIGHUP was re-used both for log rotation and mem-cache clearance. As a result, sss_cache triggers logs rotation. Is it intentional?

This is a good point, I think it may also contribute to the whole "slow files provider" issue.

How?

Post by elkoniu

You don't need to touch permanent entries to resolve this issue.

```
About the tricky part, the memory used by the in-memory tdb is not freed if individual entries are removed
so you have to close and open the tbd to get back the memory. Now you should not forget to add
the permanent entries again, but calling sss_ncache_reset_repopulate_permanent() should be sufficient here.
```

If you don't touch permanent entries then you don't need to add it back again.

If you want to do a full cycle with close/open to partially resolve another ticket mentioned (about mem leak), then this comment apply. But in your patch you don't do this.
"""

See the full comment at https://github.com/SSSD/sssd/pull/5539#issuecomment-802971608

[elkoniu]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: [WIP] NSS: Clear negative cache when SIGHUP received

elkoniu commented:
"""
This PR missing flag / lock file implementation. Will be updated soon and then suitable for review.
"""

See the full comment at https://github.com/SSSD/sssd/pull/5539#issuecomment-802063411

[alexey-tikhonov]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: [WIP] NSS: Clear negative cache when SIGHUP received

alexey-tikhonov commented:
"""
Hi,

@pbrezina , do you remember the reason to have ["clearMemcache" method](https://github.com/SSSD/sssd/blob/master/src/sss_iface/sss_iface.xml#L22) in generic "sssd.service" interface instead of dedicated ["sssd.nss.MemoryCache" interface](https://github.com/SSSD/sssd/blob/master/src/sss_iface/sss_iface.xml#L176)?

Perhaps the idea was that monitor should treat all services as "generic" service, but that's not the case anyway:
https://github.com/SSSD/sssd/blob/master/src/monitor/monitor.c#L1351

What happens if this method is called but service doesn't implement it? Is there "stub" handler or just NULL in method table?

---

@elkoniu , I understand it's tempting to copy what is done wrt mem-cache (though I would suggest to check if there is a need/opportunity to improve things a bit), but even in this case:
- IIUC, your implementation of `nss_clear_negcache()` isn't correct (see comment inline)
- please take a look at those functions: https://github.com/SSSD/sssd/blob/master/src/responder/common/negcache.h#L150 (and [existing interface](https://github.com/SSSD/sssd/blob/master/src/sss_iface/sss_iface.xml#L169))
"""

See the full comment at https://github.com/SSSD/sssd/pull/5539#issuecomment-802304774

[alexey-tikhonov]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: [WIP] NSS: Clear negative cache when SIGHUP received

alexey-tikhonov commented:
"""

Post by elkoniu
```
<interface name="sssd.Responder.NegativeCache">
<annotation name="codegen.Name" value="resp_negcache" />
<annotation name="codegen.SyncCaller" value="false" />
<method name="ResetUsers" key="True" />
<method name="ResetGroups" key="True" />
</interface>
```
@alexey-tikhonov If I understand correct you suggest to update `sssd.Responder.NegativeCache` with `RepopulatePermament` and then use this API instead of generic `sssd.service` one (`"clearMemcache"` / `"clearNegCache"`)?

No, I suggested to figure out if we can use responder's interface in monitor code and if "yes" then just re-use existing ResetUsers/ResetGroups. You don't need to touch permanent entries to resolve this issue.
"""

See the full comment at https://github.com/SSSD/sssd/pull/5539#issuecomment-802808502

[alexey-tikhonov]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: NSS: Clear negative cache when SIGHUP received

alexey-tikhonov commented:
"""
Thanks for the updates. This version definitely looks better and should do what is functionally required.

What feels a little bit loose: patch relies on the order of method invocations in the monitor to assure sss_cache is blocked until all operations are done. But I think proper resolution should include decoupling of log rotation and cache reset, and since you said you wouldn't like to do this within this PR, then proper comment would be enough.

As a more important note:
- instead of addition of a new method in "sssd.service" interface you could check if it’s possible to reuse existing methods of "sssd.Responder.NegativeCache"
- while not strictly necessary to be done within this PR, imo it also makes sense to do the same with clearMemcache() method - either move it to “sssd.nss.MemoryCache” or just get rid of it and reuse existing InvalidateAll*() (but the latter would require verification that it does the same)

"""

See the full comment at https://github.com/SSSD/sssd/pull/5539#issuecomment-808515095

[elkoniu]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: NSS: Clear negative cache when SIGHUP received

elkoniu commented:
"""

Post by alexey-tikhonov
Thanks for the updates. This version definitely looks better and should do what is functionally required.
What feels a little bit loose: patch relies on the order of method invocations in the monitor to assure sss_cache is blocked until all operations are done. But I think proper resolution should include decoupling of log rotation and cache reset, and since you said you wouldn't like to do this within this PR, then proper comment would be enough.

I am almost sure that negative cache can be cleared without any blocker, also I did not wanted to add another file blocker.
Existing blocker is part of legacy code. I would like to open separated PR to remove it, split log rotate and cache cleaning and then handle whole thing using DBUS command send from sss_cache directly, rather than sending SIGHUP to monitor.
I will add a comment in the code that I am sort-of reusing existing file blocker for new function "just in case".

Post by alexey-tikhonov
* instead of addition of a new method in "sssd.service" interface you could check if it’s possible to reuse existing methods of "sssd.Responder.NegativeCache"
* while not strictly necessary to be done within this PR, imo it also makes sense to do the same with clearMemcache() method - either move it to “sssd.nss.MemoryCache” or just get rid of it and reuse existing InvalidateAll*() (but the latter would require verification that it does the same)

I decided to add a new method to the code to be more consistent with existing implementation. If it is possible I would like to move DBUS methods refactoring to separated PR. Pavel mentioned [1] that there is a plan to get rid of monitor in favor of systemd. I guess DBUS methods refactoring will be part of it too.

[1] https://github.com/SSSD/sssd/pull/5552#issuecomment-814906355


"""

See the full comment at https://github.com/SSSD/sssd/pull/5539#issuecomment-815370299

[elkoniu]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: NSS: Clear negative cache when SIGHUP received

elkoniu commented:
"""
When I am trying to access `sssd.Responder.NegativeCache.ResetUsers` or `sssd.Responder.NegativeCache.ResetGroups`
they are missing on the connector used by NSS by default:
```
(2021-04-08 11:57:05): [nss] [sbus_method_handler] (0x2000): Received D-Bus method sssd.Responder.NegativeCache.ResetUsers on /sssd
(2021-04-08 11:57:05): [nss] [sbus_method_handler] (0x0020): Unknown interface!
```
"""

See the full comment at https://github.com/SSSD/sssd/pull/5539#issuecomment-815732250

[elkoniu]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: NSS: Clear negative cache when SIGHUP received

elkoniu commented:
"""

Post by alexey-tikhonov
instead of addition of a new method in "sssd.service" interface you could check if it’s possible to reuse existing methods of "sssd.Responder.NegativeCache"

When I am trying to access `sssd.Responder.NegativeCache.ResetUsers` or `sssd.Responder.NegativeCache.ResetGroups`
they are missing on the connector:
```
(2021-04-08 11:57:05): [nss] [sbus_method_handler] (0x2000): Received D-Bus method sssd.Responder.NegativeCache.ResetUsers on /sssd
(2021-04-08 11:57:05): [nss] [sbus_method_handler] (0x0020): Unknown interface!
```
"""

See the full comment at https://github.com/SSSD/sssd/pull/5539#issuecomment-815732250

[alexey-tikhonov]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: NSS: Clear negative cache when SIGHUP received

alexey-tikhonov commented:
"""

Post by elkoniu
When I am trying to access `sssd.Responder.NegativeCache.ResetUsers` or `sssd.Responder.NegativeCache.ResetGroups`
```
(2021-04-08 11:57:05): [nss] [sbus_method_handler] (0x2000): Received D-Bus method sssd.Responder.NegativeCache.ResetUsers on /sssd
(2021-04-08 11:57:05): [nss] [sbus_method_handler] (0x0020): Unknown interface!
```

I guess this means responders do not register this interface on monitor's bus and

Post by elkoniu

Post by alexey-tikhonov
@pbrezina , do you remember the reason to have ["clearMemcache" method](https://github.com/SSSD/sssd/blob/master/src/sss_iface/sss_iface.xml#L22) in generic "sssd.service" interface instead of dedicated ["sssd.nss.MemoryCache" interface](https://github.com/SSSD/sssd/blob/master/src/sss_iface/sss_iface.xml#L176)?

Legacy reasons. It looks like it can be moved to sssd.nss interface.

we actually can't...


Well, ok, I will let other take a look.


"""

See the full comment at https://github.com/SSSD/sssd/pull/5539#issuecomment-815850539

[alexey-tikhonov]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: NSS: Clear negative cache when SIGHUP received

alexey-tikhonov commented:
"""

Post by alexey-tikhonov
Well, ok, I will let other take a look.

I mean, patch should do what is functionally required. But I'd like somebody else to take a look in case we overlooked a more neat solution.
"""

See the full comment at https://github.com/SSSD/sssd/pull/5539#issuecomment-816066519

[alexey-tikhonov]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: NSS: Clear negative cache when SIGHUP received

alexey-tikhonov commented:
"""

Looks good to me. I just wonder if it shouldn't reset all record types - not only users and groups but also netgroups, services, etc?

From general point of view - probably yes.
But practically, AFAIK, the only use case for this reset - when sss_cache is invoked from useradd/userdel.
"""

See the full comment at https://github.com/SSSD/sssd/pull/5539#issuecomment-817701316

[pbrezina]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: NSS: Clear negative cache when SIGHUP received

pbrezina commented:
"""

Post by elkoniu

Post by alexey-tikhonov
Thanks for the updates. This version definitely looks better and should do what is functionally required.
What feels a little bit loose: patch relies on the order of method invocations in the monitor to assure sss_cache is blocked until all operations are done. But I think proper resolution should include decoupling of log rotation and cache reset, and since you said you wouldn't like to do this within this PR, then proper comment would be enough.

I am almost sure that negative cache can be cleared without any blocker, also I did not wanted to add another file blocker.
Existing blocker is part of legacy code. I would like to open separated PR to remove it, split log rotate and cache cleaning and then handle whole thing using DBUS command send from sss_cache directly, rather than sending SIGHUP to monitor.
I will add a comment in the code that I am sort-of reusing existing file blocker for new function "just in case".

Post by alexey-tikhonov
```
* instead of addition of a new method in "sssd.service" interface you could check if it’s possible to reuse existing methods of "sssd.Responder.NegativeCache"
* while not strictly necessary to be done within this PR, imo it also makes sense to do the same with clearMemcache() method - either move it to “sssd.nss.MemoryCache” or just get rid of it and reuse existing InvalidateAll*() (but the latter would require verification that it does the same)
```

Ideally, this kind of stuff should not be implemented as a method call but rather as a dbus signal. For that however, we need to have single message bus.

Post by elkoniu
I decided to add a new method to the code to be more consistent with existing implementation. If it is possible I would like to move DBUS methods refactoring to separated PR.

I'm fine with this.
"""

See the full comment at https://github.com/SSSD/sssd/pull/5539#issuecomment-817730108

[pbrezina]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: NSS: Clear negative cache when SIGHUP received

pbrezina commented:
"""

Post by alexey-tikhonov

Looks good to me. I just wonder if it shouldn't reset all record types - not only users and groups but also netgroups, services, etc?

From general point of view - probably yes.
But practically, AFAIK, the only use case for this reset - when sss_cache is invoked from useradd/userdel.

It's your and Pawels call. I'm not going to block these patches by it. Ack from me.

"""

See the full comment at https://github.com/SSSD/sssd/pull/5539#issuecomment-817730731

[elkoniu]

URL: https://github.com/SSSD/sssd/pull/5539
Author: elkoniu
Title: #5539: NSS: Clear negative cache when SIGHUP received
Action: synchronized

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/5539/head:pr5539
git checkout pr5539

[alexey-tikhonov]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: NSS: Clear negative cache when SIGHUP received

Label: -Waiting for review

[alexey-tikhonov]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: NSS: Clear negative cache when SIGHUP received

Label: +Changes requested

[elkoniu]

URL: https://github.com/SSSD/sssd/pull/5539
Author: elkoniu
Title: #5539: NSS: Clear negative cache when SIGHUP received
Action: synchronized

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/5539/head:pr5539
git checkout pr5539

[elkoniu]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: NSS: Clear negative cache when SIGHUP received

Label: -Changes requested

[elkoniu]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: NSS: Clear negative cache when SIGHUP received

Label: +Waiting for review

[alexey-tikhonov]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: NSS: Clear negative cache when SIGHUP received

Label: -Waiting for review

[alexey-tikhonov]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: NSS: Clear negative cache when SIGHUP received

Label: +Accepted

[alexey-tikhonov]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: NSS: Clear negative cache when SIGHUP received

alexey-tikhonov commented:
"""
Thanks. ACK.
"""

See the full comment at https://github.com/SSSD/sssd/pull/5539#issuecomment-818672826

[pbrezina]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: NSS: Clear negative cache when SIGHUP received

Label: +Ready to push

[pbrezina]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: NSS: Clear negative cache when SIGHUP received

pbrezina commented:
"""
Pushed PR: https://github.com/SSSD/sssd/pull/5539

* `master`
* 7a4974c876ad5a8558dbd8897c7111a18aad47b1 - nss: Clear negative cache when SIGHUP received
* 6195ac70bd4aa18fee30477af8918b7848ca939a - nss: Add negcache clearing sbus callback
* e69943594994e458508fcd443e3ba3865a643b1e - utils: Add description for CLEAR_MC_FLAG define
* 4f3734274ce7c5ec84c4c244139cb35d2da40e78 - ncache: Fix misleading function comment

"""

See the full comment at https://github.com/SSSD/sssd/pull/5539#issuecomment-818705894

[pbrezina]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: NSS: Clear negative cache when SIGHUP received

Label: -Accepted

[pbrezina]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: NSS: Clear negative cache when SIGHUP received

Label: +Pushed

[pbrezina]

URL: https://github.com/SSSD/sssd/pull/5539
Title: #5539: NSS: Clear negative cache when SIGHUP received

Label: -Ready to push

[pbrezina]

URL: https://github.com/SSSD/sssd/pull/5539
Author: elkoniu
Title: #5539: NSS: Clear negative cache when SIGHUP received
Action: closed

To pull the PR as Git branch:
git remote add ghsssd https://github.com/SSSD/sssd
git fetch ghsssd pull/5539/head:pr5539
git checkout pr5539