Unique event for automatic container restarts would be useful

[slaupster]

Currently there is no unique event for when a container is automatically restarted by the daemon. Such an event can be determined from the sequence of events for a container:

• restart - die, start, restart
• stop - die, stop
• start - start
• abend - die, start

Trick is to simply track "die, start" sequences and check for at some later time the absence or presence of a restart event for the container in question (ugly). A unique event would be nice, eg:

• abend - die, start, autorestarted or whatever

Use case is that docker does a nice job of hiding containers that abend by just restarting them. It would be nice to trap that event to get an idea that it is happening.

Discussed here on forum:

https://forums.docker.com/t/docker-events-when-container-automatically-restarted/356

[SvenDowideit]

I'm hoping that #8662 will add some information wrt the exit code of a container's PID1

[circular-dark]

#dibs

[bboreham]

Let me extend @slaupster's table to cover a process exiting of its own volition where the restart policy doesn't apply:

• restart - die, start, restart
• stop - die, stop
• start - start
• abend - die, start
• exit - die

For my purposes, it would be nicer to get some notification of 'restart' or 'autorestart' before the 'die' event. I am tracking some extra information about containers, and have to retain it beyond a 'die' event to see if a 'start' comes later.

[cpuguy83]

See #11827 which introduces an exit event after die when the process exits unexpectedly.

[bboreham]

Thanks for the pointer, but I can't see that the proposed exit covers what I need. In the auto-restart case Docker would send "die, exit, start", so I would still need to retain my information for a while to see if the 'start' is coming.

As mentioned there, adding information to the die event would be another way to get what I need.

[cpuguy83]

@bboreham Having a unique event for automatic restart doesn't change this either. You still have to wait for the event when the container is restarted.
In addition, if the container has a restart policy you can bet it will be restarted, and for that matter you can just check every so often if the container actually is started rather than relying on events for this.

[bboreham]

Maybe if I said it another way: I am asking for something like:

• restart - (start is coming!) die, start, restart
• stop - die, stop
• start - start
• abend - (start is coming!) die, start
• exit - die

where the "start is coming!" is either an extra event or extra data on the die event.

Knowing about a restart policy (and interpreting the on-failure cases) doesn't help the docker restart case; at present I still need to wait to see if it's coming.

[cpuguy83]

@bboreham The state information for a container already provides this information.

[bboreham]

OK, thanks for pointing that out. So this issue should be closed then?

[cpuguy83]

We can wait until the exit event is merged (and it should close this automatically when merged).

[bboreham]

As far as I can see, State.Restarting only covers the "abend" case, not the restart-by-command case.

[cpuguy83]

@bboreham But there is an event for restart by command already.

[bboreham]

I know. The one thing I was trying to add to this issue is that I, in my code, want to know a restart is pending at or before the time the die event comes. It made sense to say this if someone is implementing a fix to this issue; if this issue is being closed with a different fix elsewhere then it's somewhat off-topic.

[cpuguy83]

@bboreham But how can we know that it is going to be restarted before the die event?
die occurs when the process has stopped. We can't know before that.

[bboreham]

When Docker is controlling both the stop and the start because it is actioning a restart command, then it knows.

[sriranganathan]

#dibs

[krasi-georgiev]

@thaJeztah I think you can close this

seems that it has been added ?
#15669