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
When using a service inside a group stanza, the check.check_restart.grace timer starts as soon as the allocation is created, while the workloads are still in the "starting" phase. This behavior works as intended, but there are some inconsistencies when a task is provided for that service
Users can define a task in either the service or check stanza (by default, the check inherits the value from service.task if defined). The problem is that if a task benefits from a sidecar or an init container, the grace period starts for the overall allocation rather than waiting for the specific task to start
What is happening:
The grace timer starts at allocation creation, not after the task that the check is designed for
For tasks that use a sidecar or an init container, this means the grace timer is already counting down even before the main task is still waiting for its lifecycle phase
Expected Behavior:
If the service or check stanza defines a task attribute, Nomad should wait for the "task started" event from that task before starting the grace timer
Additional Notes:
The issue occurs with both Nomad and Consul service providers
When the service is defined inside a task stanza, the grace period works as intended, starting after the "task started" event
For services using the Consul provider with "consul-connect", the sidecar container may have a slow start/warmup, resulting in inconsistent grace periods across replicas and occasional premature restarts
Steps to Reproduce:
Deploy the job definition below
By using the UI, observe that Nomad fires a restart event for the service.task before the task has started, as it waits for the init container lifecycle to complete
When using a
service
inside agroup
stanza, thecheck.check_restart.grace
timer starts as soon as the allocation is created, while the workloads are still in the "starting" phase. This behavior works as intended, but there are some inconsistencies when a task is provided for that serviceUsers can define a
task
in either the service or check stanza (by default, thecheck
inherits the value fromservice.task
if defined). The problem is that if a task benefits from a sidecar or an init container, the grace period starts for the overall allocation rather than waiting for the specific task to startWhat is happening:
Expected Behavior:
If the
service
orcheck
stanza defines atask
attribute, Nomad should wait for the "task started" event from that task before starting the grace timerAdditional Notes:
task
stanza, the grace period works as intended, starting after the "task started" eventSteps to Reproduce:
service.task
before the task has started, as it waits for the init container lifecycle to completeJob file
Environment information
Nomad version (client)
Nomad v1.9.6
BuildDate 2025-02-11T18:55:10Z
Revision 7f8b44963d36d025520348d7f24735774d26f13b+CHANGES
Nomad version (server)
Nomad v1.9.5
BuildDate 2025-01-14T18:35:12Z
Revision 0b7bb8b60758981dae2a78a0946742e09f8316f5+CHANGES
The text was updated successfully, but these errors were encountered: