process accumulation when using ephemeral homedirs

[Daniel Kahn Gillmor]

There are some GnuPG use cases that warrant the use of ephemeral
$GNUPGHOME, and some of those use cases need keyserver interaction.

If they're done repeatedly with gnupg 2.1, each invocation ends up
spawning its own dirmngr process.  even if those ephemeral homedirs are
destroyed, the dirmngr process appears to just live forever.

consider this (admittedly contrived) example:

  pidof dirmngr
  for x in $(seq 1 10); do
    export GNUPGHOME=$(mktemp -d)
    gpg --keyserver keys.gnupg.net --recv 0xD8692123C4065DEA5E0F3AB5249B39D24F25E3B6
    gpg --list-keys
    rm -rf "$GNUPGHOME"
  done

When it's done, there will be 10 more dirmngr processes running on the
system, with no clear way to get at them besides finding them in the
process table and killing them by a signal.

Do we have a good story for this use case?  The pattern of ephemeral
homedirs is not an uncommon one, and i'm starting to hear reports from
people who are getting into trouble because dirmngr processes are piling
up.

obviously, in the script above, we could add an explicit "gpgconf --kill
dirmngr" or "gpg-connect-agent --dirmngr killdirmngr /bye", but that
seems like it shouldn't be necessary.

On a system with a kernel that supports inotify (any modern linux), we
could have dirmngr watch its own socket and terminate if it disappears.
Any interest in a patch for that?  It's only a partial fix (only for
some OSes, only for some ephemeral use cases where the ephemeral homedir
is cleaned up) but it'd be a start at least.

Other thoughts about the best way to avoid this kind of process
accumulation?

   --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL: </pipermail/attachments/20160901/ebc0e5d8/attachment.sig>