-: In all these commands we've been running with
Docker create and start,
there's kind of one oddity
that I wanna show you really quickly.
Let's do a container creation and then a start,
and you'll see some kinda weird behavior.
I'm gonna run Docker, create BusyBox,
and then we're gonna set up that ping command again.
So I'll say ping google.com.
That's gonna create the container.
I can then copy the ID right here and do Docker start,
and paste that ID.
And you'll notice that I did not put in the -a,
so I have not attached this container.
When I run that command,
I see the ID of the container echoed back to me,
and then I can do a docker logs and paste that ID in,
and I'll see that, yep
it is in fact running the ping command.
And if I do the docker ps command, I can see, yep
that container is running and it's continuing
to execute the ping command.
Now, there's just one kind of odd thing here.
How do we actually stop this container?
Remember, the ping command is going
to essentially go on forever,
and we have to actually send it a signal
and tell it, "Hey, ping command, please stop,
like you're all done.
No need to reach out to Google anymore."
So we need to figure out a way
to stop this running container.
In the past,
we've just been hitting control-C on our keyboard,
or we've allowed the container to automatically stop itself,
as was the case with the echo command.
So in order to stop a container that seems to
be running amuck, on its own, we can issue
either the docker stop command
or the docker kill command.
Both these are gonna stop the running container,
but they look like they kinda do the same thing here,
so what's the difference between them?
Well, here's what happens behind the scenes.
When you issue a docker stop command, a hardware signal is
sent to the process or the primary process
inside that container.
In the case of docker stop, we send a SIGTERM message,
which is short for a terminate signal.
It's a message that's gonna be received by the process,
telling it essentially to shut down on its own time.
SIGTERM is used anytime that you want to stop a process
inside of your container and shut the container down,
and you want to give that process inside there a little bit
of time to shut itself down and do a little bit of cleanup.
A lot of different programming languages have the ability
for you to listen for these signals
inside of your code base.
And as soon as you get that signal, you could attempt
to do a little bit of cleanup or maybe save some file,
or emit some message, or something like that.
On the other hand, the docker kill command issues
a SIGKILL or kills signal to the primary running process
inside the container.
SIGKILL essentially means you have to shut down right now,
and you do not get to do any additional work.
So ideally, we always stop a container
with the docker stop command
in order to give the running process
inside of it a little bit of time to shut itself down.
Otherwise, if it feels like the container has locked up
and it's not responding to the docker stop command,
then we could issue docker kill instead.
Now, one kind of little oddity
or interesting thing about docker stop,
when you issue docker stop to a container,
if the container does not automatically stop in 10 seconds,
then Docker is going to automatically fall back
to issuing the docker kill command.
So essentially, docker stop is us being nice,
but it has only got 10 seconds to actually shut down.
So let's now try using these commands
on that kind of runaway container that we have right now.
So I'll again do docker ps,
and I'll see that the ping google.command, or excuse me
ping google.com container is still running.
So we're gonna take the ID right there
and I'll issue docker stop, and then I'll paste that ID in.
And then we're gonna wait.
And notice how we're kinda waiting here.
We're gonna end up waiting just about 10 seconds.
We're waiting 10 seconds because
it turns out that the ping command does not properly respond
to a SIGTERM message.
The ping command doesn't really have the ability to say,
"Oh yeah, I understand you want me to shut down."
The ping command is rather, I dunno, what's the term for it?
The ping command wants to do its own thing,
and it just wants to run forever.
And so after we waited those 10 seconds,
eventually the kill signal was sent to it
telling it, "Hey, ping, you're done.
Get outta here.
Shut yourself down,"
and so that's why we had to wait a couple of seconds.
Let's now take that container ID again,
we're gonna start the container backup
and try killing it this time with using docker kill.
So I'll first start the container backup with docker start,
and I'll paste the ID in, and then I'll issue
a docker kill and paste the ID again.
And then this time you're gonna see
that's it, instantly dead.
No grace period,
just get outta here.
All right, so that's it.
That's the two commands that we're going to use
for closing down containers that are running.
Remember, you can always get the ID of the container ahead
of time with docker ps, you can copy the ID
and then run either docker stop or docker kill.
And in general, I do recommend to use docker stop
to give the processes inside there a chance to shut down.
And if they don't shut down nicely, as we saw
with the ping command, eventually Docker is gonna fall back
to issuing a kill on the container instead.
All right, so that's pretty much it.
Let's take another brief pause
and continue in the next section.