Vscode-remote-release: Stop container using default timeout

[Alaric84]

• VSCode Version: 1.43.0
• Local OS Version: Debian Linux
• Remote OS Version: Debian LInux
• Remote Extension/Connection Type: Docker

Steps to Reproduce:

1. Reopen Workspace in a remote container
   The Entrypoint script traps "trap 'cleanup' SIGINT SIGTERM SIGKILL"
   As the name says ... we want to do some cleanup when exiting the container
2. a) If I stop the container from the terminal everything is fine and the cleanup is called
   b) If I "reopen the container locally" from vscode, the cleanup is not called

What is the difference beween 2a and 2b?

Thanks a lot!
Andy

[chrmarti]

We stop it with a zero timeout. Is the cleanup called when you do docker stop -t 0 <container-id>?

[vscodebot[bot]]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

[Alaric84]

@chrmarti Sorry for being late here but to answer your question:
Even with stopping the container (started by vs code) manually with docker stop -t 0 <container-id> the trap and the called function work - so this is not the reason.
Any other idea?

[chrmarti]

One detail: The container is stopped only after 10 seconds (with -t 0). This is to allow for VS Code to reconnect quickly when doing only a reload of the window.

[vscodebot[bot]]

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!

[Alaric84]

@chrmarti the issue has been closed again ... but I don't think I missed to supply any more info. Did I?

[chrmarti]

@Alaric84 Could you attach a simple script, Dockerfile and devcontainer.json demonstrating the problem? I'm not sure this is something we can control, maybe it's just a timing issue - e.g. if the cleanup doesn't run quick enough it will just be terminated.

[Alaric84]

Here you go:
CleanupTest.zip

1) Just open the workspace and reopen in the remote container.
2) Watch the content of "entrypoint.log"
3) Reopen locally and see the log again - problem: nothing new.
4) Reopen again in the remote container
5) Stop the container manually "docker stop devenv"
6) See the log: The cleanup entry is there

I hope I just do sth wrong ...

The cleanup is as fast as it could be - just echo and logfile writing.

[chrmarti]

When I manually stop the container with -t 0 I don't see the trap message. Only when I let it have the normal timeout does the trap run.

[PavelSosin-320]

Hi Marti, You can look at docker ps -all to see how the container was
exited - if Sig is not trapped it is propagated to the exit code. There is
the special docker ps filter by the exit code. I'm not sure that swarm,
which is integrated into Docker desktop today, reacts on stop and kill to
keep the required number of tasks. I am afraid the Orchestration engine
doesn't send stop to the container at all if it contradicts the replication
target - I didn't succeed to stop the last task of the service if replicas
= 1.

On Mon, May 18, 2020 at 12:19 PM Christof Marti [e-mail]
wrote:

When I manually stop the container with -t 0 I don't see the trap
message. Only when I let it have the normal timeout does the trap run.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode-remote-release/issues/2641#issuecomment-630056600,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM7YVKAURBCAJ3FUA24WM33RSD4RVANCNFSM4LWQJDVA
.

[qqq689]

I mean, I will enter my phone number in this link, correct, but how will I
receive the code ???? ☹
في الاثنين، ١٨ أيار، ٢٠٢٠ ١١:٢٨ م PavelSosin-320 [e-mail]
كتب:

Hi Marti, You can look at docker ps -all to see how the container was
exited - if Sig is not trapped it is propagated to the exit code. There is
the special docker ps filter by the exit code. I'm not sure that swarm,
which is integrated into Docker desktop today, reacts on stop and kill to
keep the required number of tasks. I am afraid the Orchestration engine
doesn't send stop to the container at all if it contradicts the replication
target - I didn't succeed to stop the last task of the service if replicas
= 1.

On Mon, May 18, 2020 at 12:19 PM Christof Marti [e-mail]
wrote:

When I manually stop the container with -t 0 I don't see the trap
message. Only when I let it have the normal timeout does the trap run.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<
https://github.com/microsoft/vscode-remote-release/issues/2641#issuecomment-630056600
,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AM7YVKAURBCAJ3FUA24WM33RSD4RVANCNFSM4LWQJDVA

.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode-remote-release/issues/2641#issuecomment-630417839,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APUECRMIPAI73ZARXUD4ITTRSGK5DANCNFSM4LWQJDVA
.

[Alaric84]

Thanks for that hint ... I had to remove the "-rm" Argument from the devcontainer.json

If I stop the container from vs code or stop -t 0 I get: Exited (137)
If I do a default stop: Exited (0)

Why do you need to force the container down with -t 0?
Why not giving it the freedom to shutdown - at least for some seconds. Is this configurable?

[PavelSosin-320]

Sorry, because it is personal! This is Job interview question: why there is
no Service stop? Because it is impossible! Service can be scaled to 0
replicas and to 1 replica back. This is the Service restart. Scheduler
sends SIGTERM and then SIGKILL after the grace period. Docker ps shows
exited (137) etc. To kill the last replica in the service the target number
has to be 0.

On Tue, May 19, 2020 at 2:38 PM Alaric84 [e-mail] wrote:

Thanks for that hint ... I had to remove the "-rm" Argument from the
devcontainer.json

If I stop the container from vs code or stop -t 0 I get: Exited (137)
If I do a default stop: Exited (0)

Why do you need to force the container down with -t 0?
Why not giving it the freedom to shutdown - at least for some seconds. Is
this configurable?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode-remote-release/issues/2641#issuecomment-630762859,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM7YVKFSCRMUQRMOAEC5OLDRSJVT7ANCNFSM4LWQJDVA
.

[PavelSosin-320]

config/containers/multi-service_container/
https://docs.docker.com/config/containers/multi-service_container/

On Tue, May 19, 2020 at 5:58 PM Pavel Sosin [e-mail] wrote:

Sorry, because it is personal! This is Job interview question: why there
is no Service stop? Because it is impossible! Service can be scaled to 0
replicas and to 1 replica back. This is the Service restart. Scheduler
sends SIGTERM and then SIGKILL after the grace period. Docker ps shows
exited (137) etc. To kill the last replica in the service the target number
has to be 0.

On Tue, May 19, 2020 at 2:38 PM Alaric84 [e-mail] wrote:

Thanks for that hint ... I had to remove the "-rm" Argument from the
devcontainer.json

If I stop the container from vs code or stop -t 0 I get: Exited (137)
If I do a default stop: Exited (0)

Why do you need to force the container down with -t 0?
Why not giving it the freedom to shutdown - at least for some seconds. Is
this configurable?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode-remote-release/issues/2641#issuecomment-630762859,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM7YVKFSCRMUQRMOAEC5OLDRSJVT7ANCNFSM4LWQJDVA
.

[Alaric84]

... thank you for trying to help - but I think I missed the point:
I don't think I have a multi service container - do I?
So I would have failed with the job interview - so please explain:
What is the point? And why can't you just do a docker stop (without -t 0)?

[chrmarti]

@Alaric84 I can look into removing -t 0.

[PavelSosin-320]

No, you can't . Swarm will restart it unless you provide code which is
ignored by Swarm according to the Serviçe definition. But if you scale the
service to.zero Swarm will shutdown the container using. sigTerm and
SigKill and will never restart it until scaleUp

בתאריך יום ד׳, 20 במאי 2020, 10:25, מאת Alaric84 ‏<[email protected]

:

... thank you for trying to help - but I think I missed the point:
I don't think I have a multi service container - do I?
So I would have failed with the job interview - so please explain:
What is the point? And why can't you just do a docker stop (without -t 0)?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode-remote-release/issues/2641#issuecomment-631289233,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM7YVKGAU2HU4SQZCZZP26DRSOAVTANCNFSM4LWQJDVA
.

[chrmarti]

@PavelSosin-320 This is about docker stop, you might be referring to a different CLI.

[PavelSosin-320]

No, this is CLI independent. Today docker-compose is used both by
Docker-compose and Docker stack deploy because it defines Services.
Services require Swarm, at least, or Kubernetes. Swarm is deployed by
Docker Desktop CE/EE current version by default. Service defines how Docker
containers Stack is deployed and exposed to clients and must have at least
1 replica. This is also the default. Service can't be killed, it can be
scaled to zero and back. Services are managed using the same CLI Docker but
different command Docker stack deploy, docker service ls, docker service
ps, docker service scale, ... This is the replacement for the old script
processor docker-compose. Everything is moving toward microservice mesh
architecture.

On Tue, May 26, 2020 at 9:50 AM Christof Marti [e-mail]
wrote:

@PavelSosin-320 https://github.com/PavelSosin-320 This is about docker
stop, you might be referring to a different CLI.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode-remote-release/issues/2641#issuecomment-633839849,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM7YVKEL4WKON6PSBBQ5M3TRTNRCRANCNFSM4LWQJDVA
.

[Alaric84]

chrmarti:

@Alaric84 I can look into removing -t 0.

Maybe this could be just another config value?

[chrmarti]

I prefer fixing the default behavior to adding a config value. We can remove -t 0 if we make sure that the main process terminates in response to SIGTERM (otherwise a default timeout will have to run out before SIGKILL is used).

[PavelSosin-320]

Yes ! The time can differ from case to case. It may take a long time to stop some processes which wait for the end of their own threads - see Tomcat.

[chrmarti]

This is also about us finding commands that will keep running and respond to SIGTERM when we remove -t 0 from docker stop. The majority of DevContainers will run with what Remote-Containers uses as command by default.

E.g., if we use the array form ["sleep", "infinity"] docker stop finishes quickly because that can handle SIGTERM. Using the single string variation also adds a shell process that will not handle SIGTERM because it is waiting for sleep to finish.

For compatibility with sleep that does not support infinity (most recent Alpine apparently does support it) we can use:

trap "exit 0" 15; while sleep 1 & wait $!; do :; done

@Chuxel I think there are a few docker-compose.yml that would need to switch to the array variant of sleep infinity.

Still weighing the odds if we should indeed remove the zero timeout.

[chrmarti]

It turns out that sleep infinity does not respond to SIGTERM either (I was mislead by my Mac showing a different behavior). Investigating now if we can fix this just for the single container case and leave the Docker Compose case as-is for now.

[connor4312]

@chrmarti can you add verification steps?

[chrmarti]

In a single container config with Dockerfile set:

    "overrideCommand": false,
    "shutdownAction": "stopContainer" // the default

And add this CMD to the end of the Dockerfile:

CMD echo Container started ; trap "echo SIGTERM caught >>/shutdown.txt; sleep 2; echo exiting >>/shutdown.txt; exit 0" 15; while sleep 1 & wait $!; do :; done

• Run command: Rebuild and Reopen in Container.
• Run command: Reopen Folder Locally.
• Verify that the container is stopped after ~15 seconds.
• Run command: Reopen in Container.
• Verify that the file /shutdown.txt contains both lines:
  
  
  
  • SIGTERM caught
  
  
  • exiting
  
  

Previously only the first line, if any, made it to the file.