#1045 SIGUSR2 should force SSSD to reread resolv.conf as well

Created 6 years ago by jhrozek
Modified 3 months ago

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

8 months ago

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

3 months 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

(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..

3 months ago

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

Login to comment on this ticket.

enhancement

SSSD

1.6.1

false

false

0

easyfix

cancel