wait is a service that just has a python script with time.sleep.
backend/ only has a dockerfile in it:
FROM alpine:latest
CMD ["echo","Hello world!"]
Now, in terminal 1: docker compose up --build
And in terminal 2:
first command: docker compose up -d â No echo appears in terminal 1
docker compose up -d â Echo does correctly appear in terminal 1
When I check the docker desktop logs, i can see the echo from terminal 1. Why does it not appear the first time?
Here are the logs from terminal 1:
broken docker compose up
[+] Running 2/2
â Container broken-backend-1 Created 0.0s
â Container broken-wait-1 Created 0.0s
Attaching to backend-1, wait-1
backend-1 | Hello world!
backend-1 exited with code 0
backend-1 exited with code 0
backend-1 | Hello world!
backend-1 exited with code 0
As you can see there are a total of 2 âHello worldâ, when in my understanding there should be 3 (From all 3 terminal commands). The missing one is from the first command of terminal 2.
You shared the same commands. I assume the right command is what you shared later without the -d flag which is --detach, meaning the containers will start but you will not get the output. Completely normal and expected and it is the command you would want to use in most cases. Then you usedocker compose logs or docker logs containername to get the logs.
Otherwise you could would never get your prompt back until you stop the container.
No actually, both commands had the -d flag. They are being run in terminal 2, but the logs appear in terminal 1. This is what is super weird, only the first time i am running the command was I having this error. EVen making a new project and testing this out this happened, I am curious if others can reproduce this with the steps I have provided.
When i check the docker logs in the desktop app both the logs appear.
(I think I may have posted this NOT as a reply, I dont mean to spam you I just believe you may not have been notified the first time)
Sorry, Iâm not sure I can follow you. The code snippet doesnât make sense to me. If compose really shows the exit code and the the output twice that alone is weird bug that I canât explain, but you say that both of your commands were the same with -d, but it is not in your code snippet. Also there is only âbackend-1â in the output and not âwaitâ. And the whole point of passing -d is that there is no output in the same terminal and you can only get the output if you run a docker compose logs command for example.
Then you also wrote previously
Which I canât understand either. What do you call terminal command? You can run a docker compose command in a terinal and that terminal will be where the output can appear or not. And of course anywhere where you get the logs like in Docker Desktop. And every time you have a single container that echos a single line should be a single output, not two, not three.
I even tried your files that you shared and could not reproduce any of the weird behaviours.
The only thing that comes to my mind is how python handles output which I wrote about here:
But that has nothing to do with how the docker commands show their own output and how many times that appears.
If you can share the all the files you used to reproduce the issue, I can try., but so far I fail to understand what you are doing exactly.
And please, also follow the guide in the below question template to learn more about your environment:
We usually need the following information to understand the issue:
What platform are you using? Windows, Linux or macOS? Which version of the operating systems? In case of Linux, which distribution?
How did you install Docker? Sharing the platform almost answers it, but only almost. Direct links to the followed guide can be useful.
On debian based Linux, the following commands can give us some idea and recognize incorrectly installed Docker:
docker info
docker version
Review the output before sharing and remove confidential data if any appears (public IP for example)
I think I was, but I didnât understand your post then either and wanted to understand it later. You can always post a new message as a reminder and asking if we had time to read the message, even without deleting your previous message.
I do not see any sensitive information in these output logs. Sorry for the late reply, the docker forum notifications were being marked as junk in my inbox.
Thank you for the video. I managed to reproduce the issue. It seems like a mix of VSCode bug and an actual compose bug. I had no output on the standard output twice, only the exit message was shown when I tried the commands from an independent terminal, not vscode. Actually it was the same in vscode until I tried the compose version you had. Even then, I could reproduce the standard output issue only in vscode.
The âexitâ message still appeared in the first terminal multiple times. So I guess there is a bug in compose and new releases partially fixed it, so the standard output did not appear multiple times in vscode either, but it did when I used an older compose version. Or maybe I did something differently and the issue still exists.
It only happened to me when I didnât wait until the wait container finished its process so I assume compose was still listening to the containers logs and showed it to you in the terminal where you still had a runnint compose in the same project. It is not common to run compose up in different terminals in the same project. It would not have happened if you used a different project-name like:
docker compose --project-name test2 up -d
If you run the same project in different terminals, you run the same containers and if a container is still running, there is no difference as there is nothing to start, it is already up and running. But when the container was already stopped, itt runs again and the question is whether Docker compose listens to those logs or not. Normally you would not have noticed this.
This could also help: Containers are not running in your terminal. Your client in the terminal just communicates with the docker daemon and that will run the containers.
It is still an interesting observation so if you want, you could report it on GitHub:
I actually have the same bug even in other terminals, (I am using zshrc in mac terminal). I also tried in âitermâ another terminal. Same output for all three.
Just for context, the reason I discovered this was because I had a project with 3 containers:
main application
seeder function
Database
The seeder function was expensive and populated some tables in the database of the main application. I used a profile for this, so I would call the seeder function using docker compose âprofile seeder upWhile the main application was already running in a container.
I wonder if you think this is a bad way of doing this kind of thing? It made sense to me because:
Compose automatically puts the services in the same docker network (So they can talk to the same db)
I like that compose automatically builds and runs the containers, so its a one command population
Perhaps I will open an issue, but as you say maybe it is a useless edge case with virtually no applications. Thanks so much for your time!
If the main application exits and you rerun it, isnât that the real problem? In the test you uploaded to GitHub, the backend was just a simple echo, but I donât see how a process running in the foreground in the container would have the same behaviour. I tried an nginx container and there were no duplicate outputs. I also tried to use profiles and it worked without issues when all services had profiles, but when a service has no profiles, even if you activate a profile, services without profiles would still start again. So if your main application has to stop, you can either assign a profile to that as well, or when you run the seeder specify the service name too, so other services will not run again
I realize I have terribly named the services in the github repo. My apologies! âwaitâ (Which is just time.sleep) would correspond to our main application. âbackendâ (echo âhello worldâ) would correspond to the seeder function. So it is the seeder which is exiting after running, not the main application. So this naming should probably be inverted.
I would have the main app running (âwaitâ), and run the seeder function (âbackendâ) from another terminal but I was not seeing log outputs, which confused me.