upgrade of unrelated packges in a chroot leaves dirmngr running in the chroot

[LaMont Jones]

I dist-upgrade a chroot'ed system as part of a process, which now breaks because dirmngr (somewhere) decided that it should be running, regardless of everything. The list below is from apt at the start of the upgrade (specifically, dist-upgrading the current yakkety daily cloud image to top of yakkety-proposed.)

This may or may not affect production images for MAAS, once things land in yakkety. (Production process does not use -proposed.)

Can we just kill dirmngr? Or at least make the user do something to start it?

The following NEW packages will be installed:
  ebtables
The following packages will be upgraded:
  apparmor cloud-guest-utils cloud-initramfs-copymods
  cloud-initramfs-dyn-netconf gcc-6-base gir1.2-glib-2.0 initramfs-tools
  initramfs-tools-bin initramfs-tools-core isc-dhcp-client isc-dhcp-common
  libapparmor-perl libapparmor1 libasn1-8-heimdal libffi6 libgcc1
  libgirepository-1.0-1 libglib2.0-0 libglib2.0-data libgssapi3-heimdal
  libhcrypto4-heimdal libheimbase1-heimdal libheimntlm0-heimdal
  libhx509-5-heimdal libkrb5-26-heimdal libnss-resolve libpam-systemd
  libpython3.5 libpython3.5-minimal libpython3.5-stdlib libroken18-heimdal
  libstdc++6 libsystemd0 libudev1 libwind0-heimdal lxd lxd-client open-iscsi
  overlayroot python3.5 python3.5-minimal snap-confine snapd systemd
  systemd-sysv tzdata ubuntu-core-launcher udev update-notifier-common

[Stéphane Graber (stgraber)]

I agree that it'd be nice if we could have gpg kill dirmngr immediately after it's done with it. Most users have no use for a long running dirmngr process, so this should be opt-in.

[Dimitri John Ledkov (xnox)]

Could you please provide empirical steps to reproduce the issue? Ideally as a script.

I've started a lxd container of xenial, dist-upgraded to yakkety and then to yakkety-proposed.

I do not have any stray dirmngr processes running. The only extra thing running appears to be snapd, which is new default system process.

I do not have session init running, as I did $ lxd exec myinstance bash, rather than ssh-in or login into this container.