upgrade of unrelated packges in a chroot leaves dirmngr running in the chroot
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| gnupg2 (Ubuntu) |
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
cloud-
initramfs-
libapparmor-perl libapparmor1 libasn1-8-heimdal libffi6 libgcc1
libgireposito
libhcrypto4-
libhx509-
libpython3.5 libpython3.
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-
Stéphane Graber (stgraber) wrote : | #1 |
Changed in gnupg2 (Ubuntu): | |
status: | New → Triaged |
importance: | Undecided → Critical |
assignee: | nobody → Dimitri John Ledkov (xnox) |
tags: | added: gnupg2 |
Dimitri John Ledkov (xnox) wrote : | #2 |
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 |
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.