Bug#923068: [pkg-gnupg-maint] Bug#923068: pinentry-gtk2 takes more than twenty seconds to appear
Dear Daniel, On 3/1/19 8:48 PM, Daniel Kahn Gillmor wrote: > On Fri 2019-03-01 16:54:45 +0100, fulvio ciriaco wrote: >> I opened another session from VT with startx and >> exec dbus-launch awesome >> and the delay reappeared. >> >> The delay does not reappear with >> exec awesome > > ok, so it works without "dbus-launch". in the scenario where you are > *not* using dbus-launch, what does: > >systemctl --user status dbus.service > > show you? > systemctl shows the same info in both cases. I attach it. Thank you Fulvio > if it's "active (running)" then i suspect the issue is that you were > running multiple dbus user sessions, and gpg-agent was connected to a > different dbus user session than the active gpg process. > > In general, you want a single dbus user session. so it sounds like > simplifying your .xsession is the way to go :) > > I'm closing this bug report (though you can still comment on it if > you've got more followup) because it sounds like the diagnosis is: > > Deliberately running multiple concurrent dbus user sessions will > confuse gpg-agent and gpg. > > and the resolution is: > > Do not start up a separate dbus user session! > > If you find that the removal of dbus-launch from your ~/.xsession is a > problem, and not something you can sustain going forward, please re-open > this bug report and explain what incompatibilities you're running into, > so we can try to figure it out further. > > thanks all for your testing and diagnosis and feedback here! > >--dkg > ● dbus.service - D-Bus User Message Bus Loaded: loaded (/usr/lib/systemd/user/dbus.service; static; vendor preset: enabled) Active: active (running) since Thu 2019-02-14 17:10:24 CET; 2 weeks 1 days ago Docs: man:dbus-daemon(1) Main PID: 1297 (dbus-daemon) CGroup: /user.slice/user-1000.slice/user@1000.service/dbus.service ├─ 1297 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only ├─ 7097 /usr/lib/dconf/dconf-service ├─ 7617 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets ├─13709 /usr/bin/kactivitymanagerd start-daemon └─13719 /usr/bin/kglobalaccel5 signature.asc Description: OpenPGP digital signature
Bug#923068: [pkg-gnupg-maint] Bug#923068: pinentry-gtk2 takes more than twenty seconds to appear
On Fri 2019-03-01 16:54:45 +0100, fulvio ciriaco wrote: > I opened another session from VT with startx and > exec dbus-launch awesome > and the delay reappeared. > > The delay does not reappear with > exec awesome ok, so it works without "dbus-launch". in the scenario where you are *not* using dbus-launch, what does: systemctl --user status dbus.service show you? if it's "active (running)" then i suspect the issue is that you were running multiple dbus user sessions, and gpg-agent was connected to a different dbus user session than the active gpg process. In general, you want a single dbus user session. so it sounds like simplifying your .xsession is the way to go :) I'm closing this bug report (though you can still comment on it if you've got more followup) because it sounds like the diagnosis is: Deliberately running multiple concurrent dbus user sessions will confuse gpg-agent and gpg. and the resolution is: Do not start up a separate dbus user session! If you find that the removal of dbus-launch from your ~/.xsession is a problem, and not something you can sustain going forward, please re-open this bug report and explain what incompatibilities you're running into, so we can try to figure it out further. thanks all for your testing and diagnosis and feedback here! --dkg signature.asc Description: PGP signature
Bug#923068: [pkg-gnupg-maint] Bug#923068: pinentry-gtk2 takes more than twenty seconds to appear
Dear Daniel, On 3/1/19 2:52 PM, Daniel Kahn Gillmor wrote: > [ privately to you, because your last message was just to me and not to > the BTS -- i'd prefer to have the conversation on the BTS though, so > it would help others in the future as well. I would be happy if you > wanted to post any followup there, and don't mind if you post any of > my text in this thread back to the bug report ] > > On Fri 2019-03-01 13:54:41 +0100, fulvio ciriaco wrote: >> I changed my .xsession: >> -- exec dbus-launch awesome >> ++ awesome >> >> The delay disappeared. > > interesting! does the delay come back if you re-introduce dbus-launch? > or if you just have "exec awesome" ? > >--dkg > I opened another session from VT with startx and exec dbus-launch awesome and the delay reappeared. The delay does not reappear with exec awesome Fulvio
Bug#923068: [pkg-gnupg-maint] Bug#923068: pinentry-gtk2 takes more than twenty seconds to appear
On Thu 2019-02-28 16:13:27 +0100, fulvio ciriaco wrote: >> gpg-connect-agent 'get_confirmation abc123' /bye >> >> does it have a delay on the system in question? > > Yes, it has the same long delay. Ok, i think this identifies that the hang is happening in gpg-agent itself. >> do you have dbus-user-session installed on both of these systems? how >> does "exec dbus-launch awesome" itself get executed? from a VT, or from >> some other automated process? > > I login through lightdm, it is the last line of my .xsession you didn't answer whether you have dbus-user-session installed. can you confirm? As a test, if you rename ~/.xsession to something else, log out, and then log back in, do you see the same delay? --dkg signature.asc Description: PGP signature
Bug#923068: [pkg-gnupg-maint] Bug#923068: pinentry-gtk2 takes more than twenty seconds to appear
Dear Daniel, On 2/27/19 8:16 AM, Daniel Kahn Gillmor wrote: > Control: reassign 923068 gpg-agent 2.2.12-1 > > On Wed 2019-02-27 07:30:39 +0100, fulvio ciriaco wrote: > >> the delay does not happen when getpin is called directly as in >> echo getpin | pinentry-gtk2 > > ok, so that means that the issue isn't in pinentry itself. It's > probably in gpg-agent or elsewhere. > > So the next diagnostic step is to get other things out of the loop, like > gpg itself, and just try to debug the agent and how it interoperates > with pinentry. > > For example, this command should cause an immediate popup confirmation > dialog box: > > gpg-connect-agent 'get_confirmation abc123' /bye > > does it have a delay on the system in question? > Yes, it has the same long delay. >> I read the thread for bug 800032 you pointed me to and noticed that on >> another machine >> I have there is no delay. I noticed that on the other machine, my wm awesome >> is launched >> directly, on the machine where the delay happens it is called through: >> exec dbus-launch awesome >> so I guess dbus-launch has to do with the problem. > > do you have dbus-user-session installed on both of these systems? how > does "exec dbus-launch awesome" itself get executed? from a VT, or from > some other automated process? > I login through lightdm, it is the last line of my .xsession Fulvio > --dkg > signature.asc Description: OpenPGP digital signature
Bug#923068: [pkg-gnupg-maint] Bug#923068: pinentry-gtk2 takes more than twenty seconds to appear
Control: reassign 923068 gpg-agent 2.2.12-1 On Wed 2019-02-27 07:30:39 +0100, fulvio ciriaco wrote: > the delay does not happen when getpin is called directly as in > echo getpin | pinentry-gtk2 ok, so that means that the issue isn't in pinentry itself. It's probably in gpg-agent or elsewhere. So the next diagnostic step is to get other things out of the loop, like gpg itself, and just try to debug the agent and how it interoperates with pinentry. For example, this command should cause an immediate popup confirmation dialog box: gpg-connect-agent 'get_confirmation abc123' /bye does it have a delay on the system in question? > I read the thread for bug 800032 you pointed me to and noticed that on > another machine > I have there is no delay. I noticed that on the other machine, my wm awesome > is launched > directly, on the machine where the delay happens it is called through: > exec dbus-launch awesome > so I guess dbus-launch has to do with the problem. do you have dbus-user-session installed on both of these systems? how does "exec dbus-launch awesome" itself get executed? from a VT, or from some other automated process? --dkg signature.asc Description: PGP signature
Bug#923068: [pkg-gnupg-maint] Bug#923068: pinentry-gtk2 takes more than twenty seconds to appear
Dear Daniel, the delay does not happen when getpin is called directly as in echo getpin | pinentry-gtk2 but it happens when for example I invoke pass show something I read the thread for bug 800032 you pointed me to and noticed that on another machine I have there is no delay. I noticed that on the other machine, my wm awesome is launched directly, on the machine where the delay happens it is called through: exec dbus-launch awesome so I guess dbus-launch has to do with the problem. Best regards Fulvio On 2/26/19 8:49 AM, Daniel Kahn Gillmor wrote: > Control: tags 923068 + moreinfo > > Hi fc-- > > On Sat 2019-02-23 20:16:03 +0100, fc wrote: >> When pinentry-gtk2 is started, the input window appears after more >> than twenty seconds. For comparison pinentry-gnome3 and pinentry-qt >> appear in less than two seconds for the same request. > > Can you take a look at https://bugs.debian.org/800032 to see whether > anything there looks like it might be a functioning workaround for you? > > also, it's not clear to me whether you've tried pinentry-gtk2 directly, > or whether you're measuring a delay from the use of (for example) gpg or > gpgsm, via gpg-agent. > > to test pinentry-gtk2 on its own, i'd recommend doing the following from > a terminal: > > echo getpin | pinentry-gtk-2 > > This should prompt you (immediately!) for a passphrase, and then echo > that passphrase to stdout. for example: > > 0 dkg@alice:~$ echo getpin | pinentry-gtk-2 > OK Pleased to meet you > D abvc > OK > 0 dkg@alice:~$ > > Does that cause the delay for you? If not, what steps *do* cause the > delay? > > Regards, > > --dkg >
Bug#923068: [pkg-gnupg-maint] Bug#923068: pinentry-gtk2 takes more than twenty seconds to appear
Control: tags 923068 + moreinfo Hi fc-- On Sat 2019-02-23 20:16:03 +0100, fc wrote: > When pinentry-gtk2 is started, the input window appears after more > than twenty seconds. For comparison pinentry-gnome3 and pinentry-qt > appear in less than two seconds for the same request. Can you take a look at https://bugs.debian.org/800032 to see whether anything there looks like it might be a functioning workaround for you? also, it's not clear to me whether you've tried pinentry-gtk2 directly, or whether you're measuring a delay from the use of (for example) gpg or gpgsm, via gpg-agent. to test pinentry-gtk2 on its own, i'd recommend doing the following from a terminal: echo getpin | pinentry-gtk-2 This should prompt you (immediately!) for a passphrase, and then echo that passphrase to stdout. for example: 0 dkg@alice:~$ echo getpin | pinentry-gtk-2 OK Pleased to meet you D abvc OK 0 dkg@alice:~$ Does that cause the delay for you? If not, what steps *do* cause the delay? Regards, --dkg
