Bug#840680: [pkg-gnupg-maint] Bug#840680: dirmngr: Dirmngr not always responding

[Craig Small]

Hi Daniel,
  I'm not sure if this helps, but using the connect manager gave an odd
result.

If I start connect manager, then gpg --send-key works immediately, it looks
just like your gpg-connect-agent output.
On another screen, I use gpg --send-key and that works. The key gets sent
and all is good.

However if I hit enter on the connect manager it exits but dirmngr keeps
running. gpg --send-key then is like before where it hangs.

This happened in both 2.1.15-4 and 2.1.15-5
However! I downloaded 2.1.15-6 and it sends the key fine, so it looks like
that was the fix for me.

 - Craig

Bug#840680: [pkg-gnupg-maint] Bug#840680: dirmngr: Dirmngr not always responding

[Daniel Kahn Gillmor]

Hi Dhole and Craig--

Thanks for your reports of dirmngr not responding.  I've tried to
reproduce this bug, and actually found it easiest to reproduce with:

 GNUPGHOME=$(mktemp -d) gpg-connect-agent --dirmngr

This should produce the following debugging info, followed by a "> "
prompt:

gpg-connect-agent: no running Dirmngr - starting '/usr/bin/dirmngr'
gpg-connect-agent: waiting for the dirmngr to come up ... (5s)
gpg-connect-agent: connection to the dirmngr established
> 

Instead, it was hanging.

I've just imported an upstream fix for hanging instances of dirmngr and
included it in an upload to unstable as 2.1.15-6, which i've marked as
fixing this bug.  Please try it out in the environments that were
hanging for you, and reopen this bug report if the problems are still
happening.

Many thanks for the reporting, testing, and followup!

Regards,

 --dkg


signature.asc
Description: PGP signature

Bug#840680: dirmngr: Dirmngr not always responding

[Dhole]

Hi,

I'm also experiencing this bug.  I first noticed it while trying to
receive some keys with `gpg --recv-keys`.  It just hangs.  The same
happens with `caff`.

I managed to capture an strace with the following line:
`for i in `seq 0 1000`; do strace -o dirmngr.strace -f -tt -T -p $(pgrep 
dirmngr); done`

I'm attaching the strace capture as well as the dirmngr.log

Notice that I killed dirmngr at the end, so both the trace and the log
show a SIGTERM.

Funnily enough, while running strace the probability of `gpg` and `caff`
succeeding increases: while capturing the traces I managed to finally
sign a key with `caff`.

Just to give more info, this is the strace of gpg hanging:

stat("/run/user/1000/gnupg/S.dirmngr", 0x7ffdcd5bf3a0) = -1 ENOENT (No such 
file or directory)
socket(AF_UNIX, SOCK_STREAM, 0) = 3
stat("/run/user/1000/gnupg/S.dirmngr", 0x7ffdcd5bf3a0) = -1 ENOENT (No such 
file or directory)
connect(3, {sa_family=AF_UNIX, sun_path="/run/user/1000/gnupg/S.dirmngr"}, 
32) = -1 ENOENT (No such file or directory)
close(3)= 0
getuid()= 1000
geteuid()   = 1000
access("/usr/bin/dirmngr", X_OK)= 0
clone(child_stack=NULL, 
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7f740051f9d0) = 9988
wait4(9988, NULL, 0, NULL)  = 9988
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=9988, 
si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
nanosleep({1, 0}, 0x7ffdcd5bf550)   = 0
stat("/run/user/1000/gnupg/S.dirmngr", {st_mode=S_IFSOCK|0700, st_size=0, 
...}) = 0
socket(AF_UNIX, SOCK_STREAM, 0) = 3
stat("/run/user/1000/gnupg/S.dirmngr", {st_mode=S_IFSOCK|0700, st_size=0, 
...}) = 0
connect(3, {sa_family=AF_UNIX, sun_path="/run/user/1000/gnupg/S.dirmngr"}, 
32) = 0
read(3, 

Thanks for the great job you're doing maintaining GnuPG :)

Cheers,
-- 
Dhole
7740  00:53:42.279421 futex(0x7f67b9f3b200, 
FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL,  
7739  00:53:42.279472 pselect6(5, [0 4], NULL, NULL, {1, 985389545}, {[], 8} 

7740  00:53:42.279496 <... futex resumed> ) = -1 EAGAIN (Resource temporarily 
unavailable) <0.27>
7740  00:53:42.279521 futex(0x7f67b9f3b200, FUTEX_WAKE_PRIVATE, 1) = 0 
<0.07>
7740  00:53:42.279546 pselect6(1, [], NULL, NULL, {1, 99919}, {NULL, 8} 

7739  00:53:43.260796 <... pselect6 resumed> ) = 1 (in [4], left {1, 4173282}) 
<0.981294>
7739  00:53:43.261047 futex(0x7f67b9f3b200, FUTEX_WAKE_PRIVATE, 1) = 0 
<0.79>
7739  00:53:43.261289 accept(4, {sa_family=AF_UNIX}, [110->2]) = 1 <0.73>
7739  00:53:43.261546 mmap(NULL, 8392704, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f67b69d9000 <0.25>
7739  00:53:43.261656 mprotect(0x7f67b69d9000, 4096, PROT_NONE) = 0 <0.19>
7739  00:53:43.261729 clone(child_stack=0x7f67b71d8ff0, 
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
 parent_tidptr=0x7f67b71d99d0, tls=0x7f67b71d9700, child_tidptr=0x7f67b71d99d0) 
= 7745 <0.59>
7739  00:53:43.261863 open("/proc/self/task/7745/comm", O_RDWR 
7745  00:53:43.261905 set_robust_list(0x7f67b71d99e0, 24) = 0 <0.19>
7739  00:53:43.261952 <... open resumed> ) = 2 <0.55>
7745  00:53:43.261973 futex(0x7f67b9f3b200, 
FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL,  
7739  00:53:43.261997 write(2, "conn fd=1", 9) = 9 <0.34>
7739  00:53:43.262079 close(2)  = 0 <0.14>
7739  00:53:43.262121 pselect6(5, [0 4], NULL, NULL, {1, 2653195}, {[], 8}) = 0 
(Timeout) <1.003769>
7739  00:53:44.266071 pselect6(5, [0 4], NULL, NULL, {2, 1047}, {[], 8} 

7740  00:53:44.281660 <... pselect6 resumed> ) = 0 (Timeout) <2.002084>
7740  00:53:44.281816 pselect6(1, [], NULL, NULL, {2, 456}, {NULL, 8} 

7739  00:53:46.268272 <... pselect6 resumed> ) = 0 (Timeout) <2.002118>
7739  00:53:46.268442 pselect6(5, [0 4], NULL, NULL, {2, 807}, {[], 8} 

7740  00:53:46.283965 <... pselect6 resumed> ) = 0 (Timeout) <2.002092>
7740  00:53:46.284137 pselect6(1, [], NULL, NULL, {2, 393}, {NULL, 8} 

7739  00:53:48.270655 <... pselect6 resumed> ) = 0 (Timeout) <2.002154>
7739  00:53:48.270849 pselect6(5, [0 4], NULL, NULL, {2, 1153}, {[], 8} 

7740  00:53:48.286356 <... pselect6 resumed> ) = 0 (Timeout) <2.002156>
7740  00:53:48.286567 pselect6(1, [], NULL, NULL, {2, 578}, {NULL, 8} 

7739  00:53:50.273123 <... pselect6 resumed> ) = 0 (Timeout) <2.002189>
7739  00:53:50.273349 pselect6(5, [0 4], NULL, NULL, {2, 1229}, {[], 8} 

7740  00:53:50.288830 <... pselect6 resumed> ) = 0 (Timeout) <2.002181>
7740  00:53:50.289037 pselect6(1, [], NULL, NULL, {2, 554}, {NULL, 8} 

7739  00:53:52.275644 <... pselect6 resumed> ) = 0 (Timeout) <2.002206>
7739  00:53:52.275819 pselect6(5, [0 4], NULL, NULL, {2, 1029}, {[], 8} 

7740  00:53:52.291312 

Bug#840680: dirmngr: Dirmngr not always responding

[Craig Small]

Package: dirmngr
Version: 2.1.15-4
Followup-For: Bug #840680

Possibly the same problem but --send-keys hangs most of the time and
never times out. At the same time dirmngr-client --ping also hangs.

I never seen so many ENOSYS before, this is stracing an existing
dirmngr so perhaps its the strace that is strange:

write(5, "conn fd=4", 9)= -1 ENOSYS (Function not implemented)
close(5)= -1 ENOSYS (Function not implemented)
futex(0x7f8bdf71e200, FUTEX_WAKE_PRIVATE, 1) = -1 ENOSYS (Function not 
implemented)
pselect6(4, [3], NULL, NULL, {1, 998948396}, {[], 8}) = -1 ENOSYS (Function not 
implemented)
futex(0x7f8bdf71e200, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, 
) = -1 ENOSYS (Function not implemented)


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dirmngr depends on:
ii  adduser3.115
ii  libassuan0 2.4.3-1
ii  libc6  2.24-5
ii  libgcrypt201.7.3-2
ii  libgnutls303.5.5-2
ii  libgpg-error0  1.24-1
ii  libksba8   1.3.5-2
ii  libldap-2.4-2  2.4.42+dfsg-2+b3
ii  libnpth0   1.2-3
ii  lsb-base   9.20161016

Versions of packages dirmngr recommends:
ii  gnupg  2.1.15-4

Versions of packages dirmngr suggests:
pn  tor  

-- no debconf information

Bug#840680: dirmngr: Dirmngr not always responding

[Vincent Lefevre]

On 2016-10-14 03:12:44 +0800, Shengjing Zhu wrote:
> After upgrade to 2.1.15-4, I find dirmngr is not always responding
> which makes command like `gpg --refresh-keys` stuck.

Same problem on a machine I upgraded a few days ago.

This does not occur on a machine which I have not upgraded yet
(I saw the bug with apt-listbugs) to 2.1.15-4.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#840680: dirmngr: Dirmngr not always responding

[Daniel Leidert]

Package: gnupg
Version: 2.1.15-4
Followup-For: Bug #840680

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

I'm also affected. For the time being: `killall dirmngr' seems to help.
Unfortunately I didn't get any useful output setting the log level yet;
will try to provide some.

Regards, Daniel



- -- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnupg depends on:
ii  gnupg-agent2.1.15-4
ii  libassuan0 2.4.3-1
ii  libbz2-1.0 1.0.6-8
ii  libc6  2.24-3
ii  libgcrypt201.7.3-2
ii  libgpg-error0  1.24-1
ii  libksba8   1.3.5-2
ii  libreadline7   7.0-1
ii  libsqlite3-0   3.14.2-1+b1
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages gnupg recommends:
ii  dirmngr 2.1.15-4
ii  gnupg-l10n  2.1.15-4

Versions of packages gnupg suggests:
pn  parcimonie  
pn  xloadimage  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJYA0YKAAoJEEvNBWfCltBdij0QAIw+dvvElEhb/4lv4jBJxeQ7
gTnDIlg927lP58fl/XyMnu0qgCQl8lnWZWYa0g147MKw/kG7XAIzVbnDzwp199ZD
LNRQSuL9VjufS+4h9t8UdLEQrxFiMBxBkDZs5bPmsQLxI3D/1Bms2of7B/ZnIivF
dw34gh8/jdBWbn9yMuhUKJ5hyqIBnX6YHEolW0aaUC5A14jdqVKhseMPTECpMezy
Ubr+4B8mGdMmKPHtGTcgLZofmSLKlf9EJhq/cPUJOLFRcnd8DiGTwMx9x9USRZsb
fAn/PvGQjpEzTHrLiNASu6SHtCYQBGWIRrieazX9WHWT4OZ3g9gkwKMTgRNHY5w/
S5q7rD45+Bf6viUh7kWn9sCEJ2QO6giVbmqrBEnI9eR/0hnNO3CWf6y5kZJRtKJC
b6I8TtN79TPKzbXBZXDSPgLCZrFY1LpeIaPn3SuhzZpmnSVR67c9XnupDKQO77mb
eo4oZ5RFqENy3BIcd3uolRTiMdBuT0yLyTXfzYmGMJT4Tdzmi9RyRyQAghCYIcAP
rKqG+keXYZTy5d88iZRImynt9lvHPzprjQmcny5l7rKtkxZoz5CncvWL0wKJdQfL
5/X9+mRuA723xg1MfP0q2UJY5NVQrbbDBlue6j09+nJtzZrzyHxkXXPOLKuNtjh8
yKxFwPXq2Yzk7ponsKYo
=j32Q
-END PGP SIGNATURE-

Processed: Re: [pkg-gnupg-maint] Bug#840680: dirmngr: Dirmngr not always responding

[Debian Bug Tracking System]

Processing control commands:

> severity -1 grave
Bug #840680 [dirmngr] dirmngr: Dirmngr not always responding
Severity set to 'grave' from 'important'

-- 
840680: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840680
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#840680: [pkg-gnupg-maint] Bug#840680: dirmngr: Dirmngr not always responding

[Daniel Kahn Gillmor]

Control: tags 840680 + unreproducible moreinfo
Control: severity 840680 important

hi Shengjing--

Thanks for this report.  it sounds frustrating!  I hope we can debug it:

On Thu 2016-10-13 15:12:44 -0400, Shengjing Zhu wrote:
> After upgrade to 2.1.15-4, I find dirmngr is not always responding
> which makes command like `gpg --refresh-keys` stuck.

is this "always not responding" or "sometimes not responding"?  I
haven't observed the same behavior with dirmngr myself, so i'm not sure
how to best proceed...

> I test dirmngr with the following steps:
>
> First run `gpg-connect-agent --dirmngr /bye`
> It should immediately return but it's stuck.
>
> But I open another shell to run `gpg-connect-agent --dirmngr /bye`
> again. The first gpg-connect-agent returns and the second still is
> stuck.
>
> And I run again `gpg-connect-agent` and the previous one returns.

this is definitely strange behavior!  have you tried attaching strace to
the dirmngr process to see what it's doing while it's not answering you?
or have you tried increasing the logging of dirmngr to see what it's
doing while it's not responding?

if the process id of dirmngr is $DIRMNGR_PID, you can use:

strace -o dirmngr.strace -f -tt -T -p $DIRMNGR_PID

to get an strace dump.

You can increase the logging by adding these lines to
~/.gnupg/dirmngr.conf and then restarting dirmngr:

log-file /tmp/dirmngr.log
debug-level advanced

If you've got dirmgnr logs or strace output that you think might be
worth sharing, but are maybe too sensitive to post to this public bug
report, feel free to send them privately to me (you can encrypt to
0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 if you like).

> So I guess only another process access to the dirmngr socket, the
> previous connect will be got processed.

I'm not sure what you mean by this.  can you explain?

  --dkg


signature.asc
Description: PGP signature

Processed: Re: [pkg-gnupg-maint] Bug#840680: dirmngr: Dirmngr not always responding

[Debian Bug Tracking System]

Processing control commands:

> tags 840680 + unreproducible moreinfo
Bug #840680 [dirmngr] dirmngr: Dirmngr not always responding
Added tag(s) unreproducible and moreinfo.
> severity 840680 important
Bug #840680 [dirmngr] dirmngr: Dirmngr not always responding
Severity set to 'important' from 'grave'

-- 
840680: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840680
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#840680: dirmngr: Dirmngr not always responding

[Shengjing Zhu]

Package: dirmngr
Version: 2.1.15-4
Severity: grave
Justification: renders package unusable

Dear Maintainer,

After upgrade to 2.1.15-4, I find dirmngr is not always responding
which makes command like `gpg --refresh-keys` stuck.

I test dirmngr with the following steps:

First run `gpg-connect-agent --dirmngr /bye`
It should immediately return but it's stuck.

But I open another shell to run `gpg-connect-agent --dirmngr /bye`
again. The first gpg-connect-agent returns and the second still is
stuck.

And I run again `gpg-connect-agent` and the previous one returns.

So I guess only another process access to the dirmngr socket, the
previous connect will be got processed.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dirmngr depends on:
ii  adduser3.115
ii  libassuan0 2.4.3-1
ii  libc6  2.24-3
ii  libgcrypt201.7.3-1
ii  libgnutls303.5.4-2
ii  libgpg-error0  1.24-1
ii  libksba8   1.3.5-2
ii  libldap-2.4-2  2.4.42+dfsg-2+b3
ii  libnpth0   1.2-3
ii  lsb-base   9.20160629

Versions of packages dirmngr recommends:
ii  gnupg  2.1.15-4

Versions of packages dirmngr suggests:
pn  tor  

-- no debconf information


signature.asc
Description: PGP signature