kitchen create with systemd as run_command affects OS session

[bogn83]

On ubuntu having run_command: /lib/systemd/systemd in kitchen.yml and calling kitchen test or kitchen create will spawn a new systemd "session".

At first I thought I was being logged out and on some runs graphics got messed up completely. But then I found out that switching through Linux' different tty terminals (Ctrl+Alt+F1-F7) I could actually get back to my graphical session with everything still running.

Currently this setup is not usable I would say:
kubuntu 18.04
systemd 237 with /lib/systemd/systemd as run_command
kitchen-docker 2.9.0
kitchen-salt 0.6.0
kitchen-sync 2.2.1
test-kitchen 2.0.1

I was thinking maybe those are recent incompatibilities between the kitchen-* gems and switched to the versions that were recent when the article I was following was published (Jan 7). But these didn't help either:

gem 'kitchen-salt', '0.4.0'                                                                                                                                                                                                                                                                                                                                           
gem 'kitchen-docker', '2.7.0'                                                                                                                                                                                                                                                                                                                                         
gem 'kitchen-sync', '2.2.1'

[keeakita]

I'm running into this as well trying to run an Ubuntu container on Arch.

My kitchen.yml:

platforms:
  - name: ubuntu-18.04
    # Special config since we need to start systemd
    driver_config:
      run_command: /sbin/init
      privileged: true
      provision_command:
        - sed -i 's/UsePAM yes/UsePAM no/g' /etc/ssh/sshd_config
        - systemctl enable ssh.service
      forward: 443

• kitchen-docker (2.8.0)
• test-kitchen (1.24.0)

In my case, I can't even get back to my x11 session; it disconnects and the system becomes unusable. I'm thinking this might be an issue with docker specifically, but I don't know how to dig further. Is there a way to see exactly what dockerfile and docker command docker-kitchen is generating?

[keeakita]

I found a solution! This behavior was also reported upstream on Docker: docker/for-linux#106 (comment)

The TL;DR is: don't use privileged: true, which is what a ton of guides on the internet say to do. Use cap_add: - SYS_ADMIN. Taking the info I linked above, my working kitchen.yml looks like this:

platforms:
  - name: ubuntu-18.04
    # Special config since we need to start systemd
    driver_config:
      run_command: /sbin/init
      cap_add:
        - SYS_ADMIN
      run_options:
        env: container=docker
      volume:
        - /sys/fs/cgroup:/sys/fs/cgroup
      provision_command:
        - sed -i 's/UsePAM yes/UsePAM no/g' /etc/ssh/sshd_config
        - systemctl enable ssh.service

I don't know if that env: container=docker part is necessary, but the other person brought it up and it works.

[palfrey]

Based on the link above, I found https://github.com/systemd/systemd/blob/aa0c34279ee40bce2f9681b496922dedbadfca19/src/basic/virt.c#L434 and the ubuntu Dockerfile (https://github.com/tianon/docker-brew-ubuntu-core/blob/bcdd3818e932eda677301ae5d81c80e010793c91/bionic/Dockerfile) which made me need to add mkdir -p /run/systemd && echo 'docker' > /run/systemd/container to provision_command to get that setup working with a stock Debian image

[B1ue-W01f]

Im following exactly the Saltstack Formula test platforms and I get this issue too, tried the options above and no luck so far.