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

Bug #1629054 reported by LaMont Jones
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gnupg2 (Ubuntu)
Incomplete
Critical
Dimitri John Ledkov

Bug Description

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

Tags: gnupg2
Revision history for this message
Stéphane Graber (stgraber) wrote :

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.

Changed in gnupg2 (Ubuntu):
status: New → Triaged
importance: Undecided → Critical
assignee: nobody → Dimitri John Ledkov (xnox)
tags: added: gnupg2
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

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.

Changed in gnupg2 (Ubuntu):
status: Triaged → Incomplete
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.