#1045 SIGUSR2 should force SSSD to reread resolv.conf as well
Closed: wontfix 4 years ago by pbrezina. Opened 12 years ago by jhrozek.

It is possible to send SIGUSR2 to the SSSD monitor process to force going online. It might be beneficial if receiving SIGUSR2 triggered rereading of /etc/resolv.conf as well.

This would help users that are stuck with the try_inotify option, for instance -- they would be able to manually send SIGUSR2 once their VPN goes up.


Fields changed

description: It is possible to send SIGUSR2 to the SSSD monitor process to force going online. It might be beneficial if receiving SIGUSR2 triggered rereading of /etc/resolv.conf as well.

This would help users that are stuck with the try_inotify option, for instance -- they would be able to manually send SIGUSR2 once their VPN goes up, for instance. => It is possible to send SIGUSR2 to the SSSD monitor process to force going online. It might be beneficial if receiving SIGUSR2 triggered rereading of /etc/resolv.conf as well.

This would help users that are stuck with the try_inotify option, for instance -- they would be able to manually send SIGUSR2 once their VPN goes up.

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.9.0
priority: major => minor

"Nice to have" for 1.9.

blockedby: =>
blocking: =>

Fields changed

feature_milestone: =>
milestone: SSSD 1.9.0 => SSSD Deferred
type: defect => enhancement

Fields changed

rhbz: => 0

Fields changed

keywords: => easyfix

Fields changed

owner: somebody => arielb
status: new => assigned

Metadata Update from @jhrozek:
- Issue assigned to arielb
- Issue set to the milestone: SSSD Patches welcome

7 years ago

Metadata Update from @jhrozek:
- Assignee reset
- Custom field patch reset (from 0)
- Custom field testsupdated reset (from 0)
- Issue close_status updated to: None
- Issue tagged with: easyfix

6 years ago

(Amit asked about this ticket on IRC)

First, I would test if maybe sssd already does what is advertised - if you disable the inotify support with try_inotify=false and change resolv.conf, does sssd already re-read resolv.conf immediately and does it recreate the c-ares context in the sssd_be process?

If not and the bug is still valid, then I think fixing it might be as easy as calling service_signal_dns_reload from signal_offline_reset where we already call service_signal_reset_offline. But really, this ticket needs to be tested first..

Metadata Update from @jhrozek:
- Custom field patch reset (from false)
- Custom field testsupdated reset (from false)

6 years ago

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

4 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/2087

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata