You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This request is related to point 5. of #3088. It aims to decrease downtime when adding new validator keys. Requiring Nimbus to do a full restart to pick-up new validator keys may become problematic for people running many validators.
We think this proposal complements #3088, but does not replace it.
A possible approach to reduce validation downtime is to implement a "reload" mechanism that simply reloads validator keys whenever a signal (typically SIGHUP) is received. This pattern is fairly common for long-running daemons. Some examples:
Another possible strategy is to listen for filesystem changes on specific files/directories (e.g. the validator keys directory), using a mechanism such as inotify. Whenever changes are detected, Nimbus could reload the keys. Some daemons that implement a similar strategy:
This second approach might be superior to sending a signal as it may work better in a multi-container scenario. For example, imagine we have two containers: control_container and nimbus_container (where Nimbus is running). If control_container wants to notify Nimbus to restart, it would require that both control_container and nimbus_container share the same PID namespace.
Yet another approach is to listen for commands on a UNIX socket used exclusively for administrative tasks (e.g. reload, restart, etc.)
The text was updated successfully, but these errors were encountered:
This request is related to point 5. of #3088. It aims to decrease downtime when adding new validator keys. Requiring Nimbus to do a full restart to pick-up new validator keys may become problematic for people running many validators.
We think this proposal complements #3088, but does not replace it.
A possible approach to reduce validation downtime is to implement a "reload" mechanism that simply reloads validator keys whenever a signal (typically
SIGHUP
) is received. This pattern is fairly common for long-running daemons. Some examples:Another possible strategy is to listen for filesystem changes on specific files/directories (e.g. the validator keys directory), using a mechanism such as inotify. Whenever changes are detected, Nimbus could reload the keys. Some daemons that implement a similar strategy:
This second approach might be superior to sending a signal as it may work better in a multi-container scenario. For example, imagine we have two containers:
control_container
andnimbus_container
(where Nimbus is running). Ifcontrol_container
wants to notify Nimbus to restart, it would require that bothcontrol_container
andnimbus_container
share the same PID namespace.Yet another approach is to listen for commands on a UNIX socket used exclusively for administrative tasks (e.g. reload, restart, etc.)
The text was updated successfully, but these errors were encountered: