reload config on SIGHUP & /-/reload, implement /-/healthy
#121
Conversation
|
Hmm, I'm not sure I like re-exec as a way to do this. |
|
@SuperQ , do you have any specific concern about the approach? I may be able to look into it. This is not an uncommon solution in Unix, but I noticed that in the prometheus related programs world, the most common solution is purely programmatically resetting the state manually. However, I'm not sure that approach is followed because of some analysis of tradeoffs between re-exec or programmatic in every case. I understand if you prefer to close this PR, and look into a solution more aligned with the rest of prometheus related programs for uniformity, or into a solution that fulfills some functional requirements better. |
|
While dealing with another program, I thought of something. It would be best if the HUP signal would try to reload the config, and if it fails, keep using the previous one while outputting the error. That's not solved in this PR. Let me see if I can work on a better solution here. |
|
Yes, take a look at some of the other Prometheus exporters that support SIGHUP. There are some reasonable reload patterns. |
Fixes: SuperQ#118 Signed-off-by: Carlos Rodriguez-Fernandez <carlosrodrifernandez@gmail.com>
* `/-/healthy` indicates that the http server successfully started, and consequentially the config was successfully parsed. * `/-/reload` allows to attempt to reload the config, which is expected to be called by a sidecar that watches for config file changes Signed-off-by: Carlos Rodriguez-Fernandez <carlosrodrifernandez@gmail.com>
|
I also included a commit for |
carlosrodfern
changed the title
SIGHUP & /-/reload, implement /-/healthy
|
Looks like there's a minor lint issue. |
Signed-off-by: Carlos Rodriguez-Fernandez <carlosrodrifernandez@gmail.com>
Signed-off-by: Carlos Rodriguez-Fernandez <carlosrodrifernandez@gmail.com>
* [FEATURE] Support runtime config reload #121 Signed-off-by: SuperQ <superq@gmail.com>
* [FEATURE] Support runtime config reload #121 Signed-off-by: SuperQ <superq@gmail.com>
| pingers = append(pingers, pinger) | ||
| } | ||
| } | ||
| sc.Unlock() |
There was a problem hiding this comment.
The prepare function can return (with error) before it unlocks the mutex, leaving it perpetually locked. Since smokerpingers is reused within the main function, this could result in a deadlock when the prepare function is called a subsequent time. I suggest a defer sc.Unlock() immediately after the sc.Lock() line earlier.
There was a problem hiding this comment.
Good catch, anyone want to open a PR for this fix?
There was a problem hiding this comment.
Good catch, indeed. I'll fix it.
There was a problem hiding this comment.
I opened PR #148 with the fix.
Thank you!
Fixes: #118