docker-compose destroys current TTY session

[mradcliffe]

Issue Type

• Support Request
  -- Purpose: Drupal VM Docker testing/user feedback

Your Environment

bash-4.3$ . env/bin/activate
(env) bash-4.3$ python --version
Python 3.4.6
(env) bash-4.3$ docker --version
Docker version 1.13.1, build 092cba3727bb9b4a2f0e922cd6c0f93ea270e363
(env) bash-4.3$ docker-compose --version
docker-compose version 1.12.0, buil db31ff33

docker-compose.yml:

version: "3"

services:

  drupal-vm:

    # Switch the image to `geerlingguy/drupal-vm` to use Drupal VM defaults.
    image: geerlingguy/drupal-vm
    # Comment out 'image' and uncomment the line below if customizing Drupal VM
    # with a project-specific Dockerfile in the same directory as this file.
    # build: .

    # Set this to your project's machine name (e.g. example-com)
    container_name: drupal8-dev

    ports:
      - 80:80
      - 443:443
      - 3306:3306
      - 8025:8025

    # Not strictly required, but custom DNS settings can help with stability.
    dns:
      - '8.8.8.8'
      - '8.8.4.4'

    # Use of the `delegated` option currently requires the Docker Edge release.
    volumes:
      - ./:/var/www/drupalvm/:rw
    #  - ./:/var/www/drupalvm/:rw,delegated

    privileged: true
    command: /lib/systemd/systemd

    networks:
      drupalvm:
        # Set this IP address to something different if you already have another
        # service running on the default IP address. If you change the subnet,
        # you need to also change the bridge network IP and subnet below.
        ipv4_address: 192.168.88.88

networks:

  # This custom network allows Drupal VM to be accessed on an IP address.
  drupalvm:
    driver: bridge
    driver_opts:
      ip: 192.168.88.1
    ipam:
      config:
        - subnet: "192.168.88.0/16"

Your OS

• Linux (4.9.19)

Full console output

bash-4.3$ . env/bin/activate
(env) bash-4.3$ docker-compose up -d
Starting drupal8-dev
(env) bash-4.3$ docker-compose down
Stopping drupal8-dev ... done
Removing drupal8-dev ... done
Removing network drupalvm_drupalvm

Summary

Running docker-compose up -d kills my current session (running x.org with a terminal running tmux with several windows and panes), and sends me to a TTY console for Drupal VM. Not sure what username or password to use from there. Should I expect to lose my current X session when running docker-compose? I upgraded from an older version of docker, and my familiarity with it was that running docker start <container> wouldn't do anything drastic, but I'm not sure what I should be expecting with Drupal VM run outside of a VM or what I should do after that.

I also tried SSH from a laptop, running the command, and that still kicked my main linux session back to TTY with Debian login prompt.

I think that the eventual expectation is that I should be able to run my IDE and then run docker-compose up on the same box?

[mradcliffe]

Hmm... Maybe that's what /lib/systemd/systemd does? I'm not familiar with how systemd works as a Slackware user.

[mradcliffe]

Removing the command causes the container to shut down running up, but at least it doesn't kill my :X session. Tried `command: /bin/bash, but that didn't really do anything.

[mradcliffe]

It looks like it's something to do with the combination of the following:

  privileged: true
  command: /lib/systemd/systemd

[geerlingguy]

@mradcliffe - It looks like you're running docker-compose up -d, which is correct. On my Mac, that brings up the container, then drops me back into my normal shell... I wonder if something about slackware linux or your local terminal environment might be causing an issue?

I haven't yet tested this on anything other than my Mac or on Travis CI.

[mradcliffe]

Thanks, @geerlingguy. I wanted to provide some feedback. I finally got to looking at things since you're work at DrupalCon.

What does "drops me back into my normal shell" mean in Terminal.app on MacOS? Does that mean some sort of significant visual change to your terminal window, or merely the command in bash completing and ready for the next interaction?

I think my next step to investigate would be to look at keeping the container unprivileged and figuring out why the container immediately stops after starting. Maybe a command I need to run instead of /lib/systemd/systemd?

[geerlingguy]

merely the command in bash completing and ready for the next interaction?

This.

And the reason systemd is run is because inside the container, the way I have it set up (to make it work similar on Docker as it runs on a VM) is to use systemd to manage all the different internal processes (MySQL, Apache, PHP-FPM, etc.).

If you change it to something else, whatever that thing is would need to make sure that everything's running inside the Docker container.

[mradcliffe]

Okay, hmm... So apparently I have the container running when running unprivileged and it's running /lib/systemd/systemd, but not correctly. Probably because it's unprivileged. I was able to run docker exec -ti <ID> /bin/bash and get into the container, but couldn't do anything because systemd wasn't init'd correctly. Still working on it...

[mradcliffe]

I tried adding tmpfs and a bind mount for cgroup...

   volumes:
      - ./:/var/www/drupal-vm/:rw
      - /sys/fs/cgroup:/sys/fs/cgroup:ro

    tmpfs:
      - /run
      - /run/lock
      - /tmp

[geerlingguy]

Did that work? I'm away from my home office, where I could do some testing on a Linux machine, so I'm only able to test against Mac right now.

[mradcliffe]

No, I did not have any success with that though supposedly that is supposed to work. I also tried adding

  cap_add:
    - SYS_ADMIN
  security_opt:
    - seccomp:unconfined

Although I'm unsure if any of that did anything because there does not seem to be any verbose logging from docker-compose :(

[mradcliffe]

I did not have any success today trying to get systemd to run in an unprivileged container despite trying to setup my system similar to what I learned in

• Failed to get D-Bus connection: No connection to service manager - CentOS 7 moby/moby#7459
• Running systemctl in container fails with "Failed to get D-Bus connection" moby/moby#2296
• Ubuntu 16.04 host: cannot run systemd inside unprivileged container moby/moby#28614
  -- It's possible that jessie using an older systemd isn't compatible with unprivileged containers or any of rhatdan's red hat tricks working on non-systemd hosts. I tried to update to stretch to test, and got completely different errors similar to the ones in this issue, but none of the listed resolutions solve anything.

Finally I found docker-systemctl-replacement, which looks promising. If I install that and then run ansible-playbook /etc/ansible/drupal-vm/provisioning/playbook.yml in an unprivileged container, then it runs up until geerlingguy.postfix, which starts looping and spawning off endless processes (See github gist for ansible-playbook output).

I'm guessing this issue should be moved to https://github.com/geerlingguy/docker-debian8-ansible ?

Edit: shouldn't @ people without permission.

[geerlingguy]

Yikes, and yes, we can take the discussion over there. Although my https://github.com/geerlingguy/docker-ubuntu1604-ansible image contains similar configuration to the Debian 8 one...

Note that I could also modify the postfix role (and perhaps others too, which manage services with initv/systemd) to have a flag that could turn off the service management, because I'm guessing that's where the problem crops up.

[mradcliffe]

I'm sorry I have not followed up on this yet to either create an issue in one of the docker-**-ansible repositories. I got busy with other things and have not had a chance to hack around.

[tanner-bruce]

@geerlingguy @mradcliffe we experienced this in a completely different environment but with a similar outcome: add --machine-id 12345 as a flag when calling systemd, and it should work.

[mradcliffe]

Thank you for the advice @tanner-bruce. However I was not able to see any difference when I added the following in docker-compose.yml:

    privileged: false
    command: 
      - "/lib/systemd/systemd --machine-id 12345"

I tried quoted or unquoted and provision still failed.

More recently I was pointed to docker4drupal, but I have not tried it yet. That approach seems to be the multiple app container approach instead of a singular container approach.

[Jasu]

I managed to get this to work in privileged mode without destroying user session:

Dockerfile additions:

RUN systemctl mask dev-mqueue.mount dev-hugepages.mount \
    systemd-remount-fs.service sys-kernel-config.mount \
    sys-kernel-debug.mount sys-fs-fuse-connections.mount \
    systemd-logind.service getty.service getty.target

# systemd stops with SIGRTMIN+3, not SIGTERM
STOPSIGNAL SIGRTMIN+3

docker-compose.yml additions:

volumes:
  - ./:/var/www/drupalvm/:rw,delegated
  - /var/lib/mysql
  - /sys/fs/cgroup:/sys/fs/cgroup:ro
  - /var/log/journal
tmpfs:
  - /run

Quite likely, masking either systemd-logind.service, getty.service, or getty.target is alone sufficient to prevent drupal-vm from taking over the system. Masking the other services which mess with machine-level stuff might still be wise though.

[nikolowry]

This happened to me on Arch and the normal shortcut to return to my X session didn't work -- had to power down and reboot

[geerlingguy]

Going to close this ticket as it has a few potential workarounds documented, and seems to only be an issue on certain Linux distros.

Additionally, the way Drupal VM does Docker may either change a bit in the future, or might be deprecated at some point...

[triwats]

Still hitting this exactly on Ubuntu 19.04 for some reason tested numerous ways. Works fine on my work mac though, which is very frustrating...

No suggesting we reopen. I'll report back if I can find more concrete stuff as to WHY it does this. I spent a lot of time trying different methods, but ultimately if you need to tinker with something that has a service file, you're going to need systemd.