Comment 1 for bug 1393474

This isn't reproducible with a direct "apt-get install -y keystone" in an ssh shell in a vivid VM with "-smp 2". It smells like this depends on whether the command is being run under a logind session or not. When the command is run in autopkgtest's direct root shell (on ttyS1), it happens:

  $ kvm -smp 2 -snapshot -m 2048 -drive file=/srv/vm/adt-vivid-amd64-cloud.img,if=virtio -nographic -monitor none -serial stdio -serial unix:/tmp/ttyS1,server,nowait

and in another shell

  $ nc -U /tmp/ttyS1
  # apt-get install -y keystone
  [...]
  Setting up keystone (1:2014.2-0ubuntu1) ...
  Killed

At the same time, I notice this in the kernel log:

[ 26.025557] systemd-logind[1961]: Failed to start user service: Unknown unit: user@107.service

user 107 is the "keystone" system user. This is bug 1359439 (but thought of as being only cosmetical so far).

I SIGTERMed apt-get install in the middle, edited /var/lib/dpkg/info/keystone.postinst to add a set -x, and get

Setting up keystone (1:2014.2-0ubuntu1) ...
+ grep -q ^connection.*sqlite.* /etc/keystone/keystone.conf
+ su -s /bin/sh -c exec keystone-manage db_sync keystone
+ su -s /bin/sh -c exec keystone-manage pki_setup keystone
Killed

which confirms that it's indeed related to PAM/su.

I found a quicker way to reproduce this: Boot the VM as above, and then run this:

$ nc -U /tmp/ttyS1
# su -s /bin/sh -c whoami www-data; su -s /bin/sh -c whoami www-data
www-data
Killed
www-data