Hi Ian-- Thanks for this note, there's a lot in here.
On Thu 2016-10-13 12:47:14 -0400, Ian Jackson wrote: > The dgit test suite involves setting up a dummy home directory with > some dummy keys and making and verifying some dummy signatures. There > is one of these per test. > > When the test suite is run under adt-run --- adt-virt-schroot, the > agents are automatically started but nothing kills them. > > This results in problems: schroot cannot unmount the chroot and cannot > clean up properly. > > I haven't checked but I am pretty sure that if I run the test suite > natively with gnupg2, it will leak enormous numbers of gpg agent > processes. Right, i can see why this might be a problem :) Does your test suite delete its test homedirs after it is finished? If not, would you be willing to include removal of the test homedirs as part of the tests, or as a final post-test cleanup phase? I ask because upstream intends for gpg-agent and dirmngr to auto-terminate when their sockets are removed, and those patches have been backported into 2.1.15-4 (see debian/patches/0015-agent-Terminate-on-deletion-of-the-socket-file-Linux.patch and debian/patches/0016-dirmngr-Terminate-on-deletion-of-the-socket-file-Lin.patch ). However, hmm, this doesn't seem to work properly; i just tested with: export GNUPGHOME=$(mktemp -d) gpg-connect-agent 'getinfo pid' /bye rm -rf "$GNUPGHOME" sleep 1 pidof gpg-agent I've just reported this problem upstream: https://bugs.gnupg.org/gnupg/issue2756 One thing worth observing is that if the agent's socket is deleted, it will eventually terminate itself after a minute or two anyway. This will happen even without inotify (but obviously the inotify trigger should really work to automate cleanup on platforms that support inotify) > IMO: there should be a way to get gnupg2 to do everything synchronously; > that is, if it needs an agent, to spawn one which does not listen on a > socket, but rather just has an existing connection to its parent and > which will die when the parent does. This could potentially complicate the agent -- at the moment, i think the agent expects to be the only process dealing with $GNUPGHOME/private-keys-v1.d/, and that means that two gpg processes using this approach could potentially trample on each other. > Also gpg agent processes should automatically exit if their HOME > ceases to exist (or if they cease to be the process listening on their > socket for some other reason) yes, this is upstream's intended behavior, and it happens (after some delay), but it's not instantaneous. Getting the inotify stuff fixed will make it much closer to instantaneous. > This problem, and how to deal with it, should be better documented. > (I looked in gpg-agent(1). I searched for "agent" and didn't find > any information that looked helpful; I did find information that > suggests that `drmngr' may be troublesome too.) NB gpg-agent(1) > refers to gpg2(1) and gpgsm(1) which do not exist. The reference to gpg2(1) is an error, and i've sent a patch upstream to gnupg-devel. gpgsm(1) is correct, but you probably don't have the gpgsm package installed. > In particular, `gpgconf --kill gpg-agent' should be documented. Where would you like it documented? it's in gpgconf(1): --kill [component] Kill the given component. Components which support killing are gpg-agent and scdaemon. Components which don't support reloadā ing are ignored. Note that as of now reload and kill have the same effect for scdaemon. If you can suggest what the text should say and where a reasonable person might look for it, i'll happily write a patch and encourage its adoption by upstream. > NB that I don't think that expecting the dgit test suite to run > `gpgconf --kill-agent' after every test is reasonable. Currently > there is _no_ code for running a specific positive command after > running a test. Given the nature of test suites and indeed the nature > of error handling on posix systems, it's not clear that such a thing > would be sensible. If you're not willing to do *anything* (including deletion of the temporary $GNUPGHOME or some sort of session termination event) upon completing the test suite, but before tearing down your builder instance, then i don't know if there's a solution. But at the moment i suspect getting the inotify stuff fixed is the sanest and simplest approach on the platform you and i probably care most about :) --dkg
signature.asc
Description: PGP signature