Control: tag 801247 + moreinfo On Sun 2016-02-21 21:02:28 +0100, Wilmer van der Gaast wrote: > I just had the same problem. I've straced gpg-agent and its child > processes which resulted in a 5.1MByte strace dump though I'd rather not > share it blindly. > > I do see the following things in it: > > 7105 connect(9, {sa_family=AF_LOCAL, sun_path=@"/tmp/dbus-xNLgc87fg9"}, > 23) = -1 ECONNREFUSED (Connection refused) > 7103 write(2, "\n** (pinentry:7103): WARNING **: couldn't create prompt > for gnupg passphrase: Could not connect: Connection refused\n", 116) = 116 > 7102 write(3, "2016-02-21 19:56:43 gpg-agent[4656] DBG: error calling > pinentry: Operation cancelled <Pinentry", 94) = 94 > > Some of that is in logs as you can see, but the connection refused to > being dbus may be helpful information. I have no file named /tmp/dbus-* > though to me the @ looks like it's actually the anonymous Unix domain > socket namespace?
thanks for the dump. Do you actually have a dbus session running? (e.g. a separate dbus process for your user account)? what does echo $DBUS_SESSION_BUS_ADDRESS show? (if it contains unix:abstract=/tmp/dbus-xNLgc87fg9, that would be good to know). If DBUS_SESSION_BUS_ADDRESS is set to some other value, can you make gpg-agent successfully use pinentry-gnome3 by killing the agent (gpgconf --kill gpg-agent) and then re-invoking whatever command triggered gpg-agent? what commands are you using to trigger gpg-agent? if you're using gpg 1.4.x to talk to the agent, what is the output of "dpkg -l gnupg" ? > Happy to look at other things if it helps. For now fortunately I've got > my SSH auth working again with pinentry-gtk-2. glad you have this workaround for now, and sorry for the hassle. --dkg
signature.asc
Description: PGP signature