Compose: key sequence to detach from `docker-compose up`

I too would cast a vote in this direction. For example, to see that everything is starting up as expected I often do docker-compose up without detaching (rather than having to inspect all logs). Another alternative would perhaps be to have a flag that makes Ctrl-c detach?

hi, did you find any solution?

There seems to be a key-sequence for attached docker-containers (Ctrl-p Ctrl-c).

Actually, the key sequence is Ctrl-p Ctrl-q. Example source.

ctrl-z appears to work version 3

Woudln't ctrl-z stop the process?

Ctrl+z stops the docker-compose process so the terminal is no more attached to any containers but they continue to run.

Ctrl+p, Ctrl+q doesn’t work for me…

Docker version 17.09.0-ce, build afdb6d4
docker-compose version 1.17.1, build 6d101fb

@M4rotte docker-compose is weird. Thanks for explanation and tip!

@M4rotte, Ctrl + Z puts the process to background. The process is no longer running, but is still using resources such (i.e. system memory). So i don't think it is a good idea to use ctr + z.

@M4rotte I don't know why it doesn't work for you, however my linked question (to Stack Overflow) has 22 upvotes at the time of this post, while my comment here magically gained 3 downvotes. There's something clearly wrong, which is left as an exercise to the reader.

@thiagowfx you are talking about docker, but we here talk about docker-compose, which is lacking the feature docker natively provides.

Did you try to :
ctrl+z : stop the process
bg : resume the last stopped process in the background ?

I often do that when I forget to specify the '-d' switch with docker-compose up

@MetaBarj0 and still you have docker-compose up running in background. This is a workaround rather than a fix. This thread is a feature-request, not a question on how to overcome the problem, when you forgot the -d switch. Thanks to all who pointed out how to use unix tools to gain access to the consoles without stopping all started containers. Please vote if you find a key-sequence useful although you do not need it (like you do not need a car or a computer).

@useltmann

first: your right and i voted for ctrl-p, ctrl-c as suggested by @smoebody.

second: @useltmann and @smoebody don't happen to be the very same person, right? the fact that your both sharing a quite seldom name and vita is just a coincidence I suppose.

@piranha79 yes, you are right: identical person. One is work, the other is private.

simply putting the process to the background is no solution as streams stay attached in this case. I have some very chatty containers, so this is an issue. +1 for a "real" detach.

Please consider adding this soon

As a workaround, what I do is create an alias so I never forget:

alias dcup="docker-compose up -d"

I will cast an anti-vote here.

Key sequences often conflict with custom settings with window managers like tmux and screen (including possible custom configurations), can clash with operating system hotkeys. I believe they're an anti-pattern for interfaces, even if Docker itself natively supports it.

Perhaps a method to tell docker-compose to detach from another terminal?

I am a little confused :) Docker supports the functionality so this isn't adding anything new -- it is just exposing functionality that already exists in the core tooling. If there is a feeling that this isn't a good approach wouldn't it make sense to look at removing it from docker itself rather than effectively breaking existing functionality?

Considering this has gotten 105 upvotes at the time of this writing, I think the original thread's assertion that this isn't really well desired is... no longer accurate. Not having some way to detach once I've accidentally forgotten the -d, makes it EXTREMELY hard for me to even consider using docker-compose for anything other then basic testing. Even there I'm unlikely to use it because it then doesn't match how I deal with production.

Even if I background the instance I've forgotten to do it in, and start an instance with it. when I come back to the first instance, shutting it down STILL kills all containers (even ones that it didn't start!). That makes it one of the most unforgiving commands in the UNIX world, only slightly less so then dd!

CTRL-Z, then disown %1 to release the job

That still leaves the local process running, just not owned by the current shell. What we are asking for is a way to detach the remote instance and completely end the local process.

Until a good solution is found for this I resorted to giving myself a safety net by adding this to my ~/.bashrc:

function docker-compose() {
    if [ "$1" == "up" -a "$#" -eq 1 ]
    then
        echo "Are you sure you want to run 'dc up' without -d?"
        echo "Run then:"
        echo "   command docker-compose up"
        return 0
    fi
    command docker-compose "$@"
}

I suggest that the default to be detached mode, and add the option to run in attached, or logging to a file.

The nastiest thing is - if the containers are already running happily in background, an accidental docker-compose up will attach to all of them and bring them all to foreground, so then when killed, will kill them all.

Fix this already for crying out loud.

@rustyx I agree wholeheartedly. As someone already mentioned above, this is one of the most unforgiving mistakes one can make while using docker-compose. Heck, probably one of the most in all of the Unix world. If at least one could send a USR1 signal or something to make it detach after realizing you've made a mistake, there would be a way out.

Perhaps remove the attach feature completely and replace it with a printed note about running docker-compose logs -f? Or make docker-compose up fork when done to the logs -f command?

Another workaround:

#$ killall -9 docker-compose

kills all docker-compose process with SIGKILL which will kill them immediately and will not give it the time to stop the containers.

@smoebody Cool! I just tried it and it does work :+1:

It still feels aggressive not giving the command a way to gracefully detach and finish. But at least is a way of recovering from this mistake. Also, I recommend taking the time to look up the PID of the exact docker-compose up process to kill if you don't want to affect other instances that may be doing something else.

killall -9 docker-compose is the way to go (as insane as that is). Thanks, @smoebody!

This is a crazy miss. An "oh crap" way out like picking up on USR1 would be a nice option (as @ateijelo suggested).

My guess is that -d is used more often than not, so I'd think that many people would like a built in safety net if at all possible.

If it doesn't exist already, a ~/.docker-compose.rc file for basic settings like this (always_detach=true, anyone?) would be much appreciated over the various workarounds people have to come up with.

At least don't kill the containers that were already running. I.e. if docker-compose up didn't start the container, then also don't kill it on exit.

I always use -d no matter what. Then if i want to attach to one or all of them, later i will use docker attach ID to get into the running container, which then lets me C-p, C-q to detach again

I know it’s not a keyboard sequence, and maybe this is a total noob thing to say, but can’t you just close the terminal window/pane and open a new one? Won’t that kill the process without stopping the containers?

Alternatively, I’ve gotten in the habit of using

> docker compose start [<container-1> <container-2> …]

instead of docker compose up. I suppose that’s only helpful if the containers have already been created. Then for the ones I actually want to pay attention to, I’ll just use something like this:

> docker compose logs -ft --tail=200 app web

Something you can safely ctrl-c out of without inadvertently stopping any containers.

If docker-compose up attached, ctrl+c should detach, not kill.

If docker-compose up attached, ctrl+c should detach, not kill.

After all, I can always docker-compose stop or docker-compose down if I'd want to kill them.

Maybe a switch -kd, --kill-detached would be nice if I knew I'd like to kill them on detach beforehand

A slightly safer variant of running killall -9 docker-compose in a separate terminal is this:

$ dc up         # oops, forgot the -d, can't detach gracefully
Ctrl+Z          # stop and send dc up to the background
$ kill -9 %1    # send SIGKILL **only** to this dc up

This leaves all other docker-compose processes unaffected and the containers running, of course.

How do we detach from docker attach {service}??? ctrl+p ctrl+q doesnt work for attach

Based on the solution from @ateijelo you can also add the following to ~/.bashrc:

function docker-compose() {
    if [ "$1" == "up" -a "$#" -eq 1 ]
    then
      command docker-compose up -d
      command docker-compose logs -f
    else
      command docker-compose "$@"
    fi
}

This makes docker-compose behave like normal, but you can detach with Crtl+C.

@HTPC-Schrauber, good idea. Now if you add "$@" to the up and logs commands too, even dc up something will be detachable.

And for those which are not in docker group and thus are using sudo:

function sudo() {
    if [ "$1" == "docker-compose" -a "$2" == "up" -a "$#" == "2" ]
    then
      command sudo docker-compose up -d
      command sudo docker-compose logs -f
    else
      command sudo "$@"
    fi
}

Based on the comments here, I have created a wrapper that transparently changes the default behavior to be detached. :tada:

The sudo function at the bottom is for those who are not in the docker group (as @HTPC-Schrauber pointed out).

https://gist.github.com/x3rAx/6d34687657c7679326f04cf0acb4a838

It even changes the --help output :sweat_smile:
```
$ docker-compose up --help
[...]
Usage: up [options] [--scale SERVICE=NUM...] [SERVICE...]

Options:
--attach Attached mode: Run containers in the foreground.
Required for --abort-on-container-exit.
--no-color Produce monochrome output.
[...]

That's a nice workaround, but still: Why on earth has this not been fixed yet? This is exactly the kind of unexpected not-sane application behavior that should be avoided at all costs.

Started using docker-compose, went to google expecting to find a way to detach after the fact and...
well, I ended up here.

Agreed, I'm shocked this isn't a thing, and that this issue is still running. +1

Thanks for the workarounds though ^^

Wrote a bash function to add a -d and then run logs immediately after:

countPosition()
{
  local NEEDLE=$1
  shift
  local IDX=1
  while test $# -gt 0
  do
    if echo $1 | grep -q "$NEEDLE"; then
      echo "$IDX"
    fi
    IDX=$(echo "$IDX+1" | bc)
    shift
  done
}

docker-compose()
{
  if [[ $@ == *"up"* ]]; then
    if [[ $@ == *"-d"* ]]; then
      command docker-compose "$@"
    else
      # Restore original command, just with -d added
       POSITION=$(countPosition "up" "$@")
       POSPLUS1=$(echo $POSITION+1|bc)
       set -- "${@:1:$POSITION}" "-d" "${@:$POSPLUS1}"

       command docker-compose "$@" && docker-compose logs -f 
    fi
  else
    command docker-compose "$@"
  fi
}

Rather than a key sequence, perhaps simply a signal handler that exits compose without terminating the containers. You could then maybe arrange for docker-compose detach to be run from another shell to make it more user friendly

Rather than a key sequence, perhaps simply a signal handler that exits compose without terminating the containers. You could then maybe arrange for docker-compose detach to be run from another shell to make it more user friendly

Yes, I'd prefer it like this... I usually want to start the containers using docker-compose up (just to see some logs for a bit). Then I want to be able to detach. I usually have more than one shell session open to the server anyway - and would like to docker-compose detach [something].

I attached to a docker compose managed container running puppet (pupperware) and realised I couldn't detach. I logged in separately, found the process running "docker attach" and killed it, and this got the other shell window detached without killing the container.

The following sequences are not working on docker v19.03.5:
1) ctrl + p, ctrl + q
2) ctrl + z
3) ctrl + p, ctrl + d
4) ctrl + c

The following sequences are not working on docker v19.03.5:

1. ctrl + p, ctrl + q
2. ctrl + z
3. ctrl + p, ctrl + d
4. ctrl + c

CTRL+C works, but if you try CTRL+Z before, it will enter a dummy state and won't respond to anything else :eyes:

The following sequences are not working on docker v19.03.5:

1. ctrl + p, ctrl + q
2. ctrl + z
3. ctrl + p, ctrl + d
4. ctrl + c

CTRL+C works, but if you try CTRL+Z before, it will enter a dummy state and won't respond to anything else 👀

@burzum85 great notice. I'll check it

1. ctrl+z to stop the process
2. bg to restart the process in the background
3. disown %1 or whatever number process it is so that you can quit the terminal

### lots
### of
### container 
### logs
^Z
[1]  + 6926 suspended  docker-compose up

$ bg
[1]  + 6926 continued  docker-compose up

$ jobs
[1]  + running    docker-compose up

$ disown %1

$ jobs
# nothing here

Rather than suspending the process, resuming it in the background, then killing it with kill -9 %1, consider also that docker-compose will also respond to SIGQUIT by exiting immediately without bringing down the running containers.

This is usually bound to Ctrl+\, which gives you a quick way to exit the process whilst keeping the containers running.

Note however that this will cause the docker-compose process to dump core on systems configured for such, but cleaning up a core file (or just leaving it) may be a price worth paying.

docker-compose seems to ignore SIGQUIT, as far as I can tell.

I use ctrl+\. and it works well on linux. However on Mac OS, it will pop up a "crash report" dialog.

@zhongjiewu - can confirm works on linux!
"Quit (core dumped)" - is this a SIGKILL?
For goodness sake - why isn't this fixed.