su call in postinst fails with "Killed" when not running from a logind shell

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

Notes to self: Faster way of iterating: Instead of rebooting the VM, run

  sudo pkill -e systemd-logind; sudo rm -r /run/systemd/user/33

(33 is www-data). This will bring the system back into the state when su gets "killed".

strace of su that is being killed

I could never reproduce it with "real" logins, so for now I suspect that this is due to the rather unusual way of running processes in a VM directly on a root shell on ttyS1, which circumvents any PAM/logind. I remember that this also breaks some other tests which expect automatic ACLs and other things that a proper PAM session provides, so I fixed autopkgtest to provide a PAM session in all cases: http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=5d45a5999

This bug was fixed in the package autopkgtest - 3.8.1

---------------
autopkgtest (3.8.1) unstable; urgency=medium

  * If the testbed does not have root privileges (e. g. missing sudo
    password), install click packages with pkcon and skip the AppArmor rule
    adjustment. This makes non-root click tests at least work for
    non-Autopilot cases. (LP: #1384417)
  * Make --shell-fail also apply to test dependency installation failure.
  * Run root tests through "su" as well (if possible), to ensure that these
    also get a proper PAM/logind session with all runners. (LP: #1393474)
  * Skip the test_tmp_install tests if apt-get download does not work. This
    might happen in some build environments which completely disable
    networking or don't have working apt-get download for some reason.
    (Closes: #769687)
  * Don't put the log FIFO into the output directory. This avoids keeping it
    in --output-dir, which fails if the output dir happens to be in the tested
    tree itself. (LP: #1393426)
  * adt-setup-vm: Don't purge man-db. It uninstalls way too much on images
    which aren't just minimal environments.
  * adt-setup-vm: Drop bogus "X-Start-Before" line in generated init.d script.
    (Closes: #770517)
  * Respect DEB_BUILD_OPTIONS=nocheck (side issue in #769687)

 -- Martin Pitt <email address hidden> Thu, 27 Nov 2014 10:54:02 +0100