Mailing List Archive

On Montag, 6. Dezember 2021 02:28:07 CET Robert J. Hansen via Gnupg-users
wrote:
> rjh@ripley:~$ gpg -vvvv --list-keys
> gpg: using character set 'utf-8'
> gpg: Note: RFC4880bis features are enabled.
> gpg: key 1DCBDC01B44427C7: accepted as trusted key
> gpg: key 1E7A94D4E87F91D5: accepted as trusted key
> gpg: key A3C418D1C6F3453A: accepted as trusted key

Looks like the output on stdout is missing completely.

> ... No output is ever produced: it just hangs without ever giving a hint
> as to what's going on, what's wrong, or how to fix it. This is not the
> behavior I expect from a high-verbosity output. What's going on here?

Doesn't happen here with self-compiled
$ gpg --version
gpg (GnuPG) 2.3.3-beta6
libgcrypt 1.9.4-beta84

Which version exactly are you using?

Try attaching gdb to see where it hangs.

Regards,
Ingo

> Which version exactly are you using?

2.3.3.

> Try attaching gdb to see where it hangs.

(gdb) run
Starting program: /usr/local/bin/gpg --list-keys
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching after fork from child process 41865]
^C
Program received signal SIGINT, Interrupt.
0x00007ffff7c70e87 in __libc_recvmsg (fd=fd@entry=4,
msg=msg@entry=0x7fffffffd490, flags=flags@entry=0)
at ../sysdeps/unix/sysv/linux/recvmsg.c:28
28 ../sysdeps/unix/sysv/linux/recvmsg.c: No such file or directory.
(gdb) backtrace
#0 0x00007ffff7c70e87 in __libc_recvmsg (fd=fd@entry=4,
msg=msg@entry=0x7fffffffd490, flags=flags@entry=0)
at ../sysdeps/unix/sysv/linux/recvmsg.c:28
#1 0x00007ffff7c96437 in __assuan_recvmsg (ctx=ctx@entry=0x555555681ec0,
fd=fd@entry=4, msg=msg@entry=0x7fffffffd490, flags=flags@entry=0)
at system-posix.c:133
#2 0x000055555556eacf in _assuan_npth_recvmsg (ctx=0x555555681ec0, fd=4,
msg=0x7fffffffd490, flags=0) at gpg.c:1037
#3 0x00007ffff7c94923 in uds_reader (ctx=0x555555681ec0, buf=<optimized
out>,
buflen=<optimized out>) at assuan-uds.c:113
#4 0x00007ffff7c8f23f in readline (ctx=ctx@entry=0x555555681ec0,
buf=buf@entry=0x555555682010 "", buflen=buflen@entry=1002,
r_nread=r_nread@entry=0x7fffffffd56c, r_eof=r_eof@entry=0x55555568200c)
at assuan-buffer.c:79
#5 0x00007ffff7c8f419 in _assuan_read_line (ctx=ctx@entry=0x555555681ec0)
at assuan-buffer.c:151
#6 0x00007ffff7c8ea50 in assuan_client_read_response (
ctx=ctx@entry=0x555555681ec0, line_r=line_r@entry=0x7fffffffd660,
linelen_r=linelen_r@entry=0x7fffffffd65c) at client.c:87
#7 0x00007ffff7c8edbb in _assuan_read_from_server (
ctx=ctx@entry=0x555555681ec0, response=response@entry=0x7fffffffd6b0,
off=off@entry=0x7fffffffd6b4, convey_comments=convey_comments@entry=0)
at client.c:209
#8 0x00007ffff7c93f07 in _assuan_connect_finalize (
ctx=ctx@entry=0x555555681ec0, fd=fd@entry=4, flags=flags@entry=1)
at assuan-socket-connect.c:125
#9 0x00007ffff7c942e8 in assuan_socket_connect
(ctx=ctx@entry=0x555555681ec0,
name=<optimized out>,
name@entry=0x555555686de0 "/run/user/1000/gnupg/S.keyboxd",
server_pid=server_pid@entry=0, flags=flags@entry=1)
at assuan-socket-connect.c:343
#10 0x000055555562004b in wait_for_sock (secs=5,
did_success_msg=<synthetic pointer>, ctx=0x555555681ec0, verbose=0,
connect_flags=1, sockname=0x555555686de0
"/run/user/1000/gnupg/S.keyboxd",
module_name_id=13) at asshelp.c:358
#11 start_new_service (r_ctx=r_ctx@entry=0x7fffffffd930,
module_name_id=module_name_id@entry=13,
errsource=errsource@entry=GPG_ERR_SOURCE_GPG,
program_name=<optimized out>, opt_lc_ctype=opt_lc_ctype@entry=0x0,
opt_lc_messages=opt_lc_messages@entry=0x0, session_env=0x0,
autostart=1,
verbose=0, debug=0, status_cb=0x0, status_cb_arg=0x555555684b70)
at asshelp.c:548
#12 0x000055555562025c in start_new_keyboxd
(r_ctx=r_ctx@entry=0x7fffffffd930,
errsource=errsource@entry=GPG_ERR_SOURCE_GPG,
keyboxd_program=<optimized out>, autostart=<optimized out>,
verbose=<optimized out>, debug=<optimized out>, status_cb=0x0,
status_cb_arg=0x555555684b70) at asshelp.c:635
#13 0x000055555558a0ba in create_new_context (r_ctx=0x5555556850d8,
ctrl=0x555555684b70) at call-keyboxd.c:143
#14 open_context (r_kbl=0x555555684c70, ctrl=0x555555684b70)
at call-keyboxd.c:219
#15 keydb_new (ctrl=ctrl@entry=0x555555684b70) at call-keyboxd.c:277
#16 0x00005555555b28fb in list_all (ctrl=ctrl@entry=0x555555684b70,
secret=secret@entry=0, mark_secret=0) at keylist.c:527
--Type <RET> for more, q to quit, c to continue without paging--c
#17 0x00005555555b2f34 in public_key_list
(ctrl=ctrl@entry=0x555555684b70, list=0x0, locate_mode=0, no_local=0) at
keylist.c:146
#18 0x000055555556acf2 in main (argc=<optimized out>, argv=<optimized
out>) at gpg.c:4638


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

>> Try attaching gdb to see where it hangs.
>
> (gdb) run
> Starting program: /usr/local/bin/gpg --list-keys
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [Detaching after fork from child process 41865]
> ^C

"gpgconf --kill all" solved my problem, but I'd still advise y'all to
look into where it got wedged and why -- this was an incredibly annoying
problem to solve, and the total lack of debugging output elevated it to
tremendously frustrating.

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

> "gpgconf --kill all" solved my problem, but I'd still advise y'all to
> look into where it got wedged and why -- this was an incredibly annoying
> problem to solve, and the total lack of debugging output elevated it to
> tremendously frustrating.

I'm such an idiot, I forgot I was sshed into another machine.

Nope, problem still exists, and gpgconf hangs just like everything else.
GnuPG is still unusable.

=====

rjh@ripley:~$ gdb --args gpgconf --kill all

[boilerplate stripped]

(gdb) run
Starting program: /usr/local/bin/gpgconf --kill all
[Detaching after fork from child process 101626]
[Detaching after fork from child process 101629]
[Detaching after fork from child process 101632]
[Detaching after fork from child process 101634]
^C
Program received signal SIGINT, Interrupt.
0x00007ffff7d2b83a in __GI___wait4 (pid=pid@entry=101634,
stat_loc=stat_loc@entry=0x7fffffffdd24, options=options@entry=0,
usage=usage@entry=0x0) at ../sysdeps/unix/sysv/linux/wait4.c:30
30 ../sysdeps/unix/sysv/linux/wait4.c: No such file or directory.
(gdb) backtrace
#0 0x00007ffff7d2b83a in __GI___wait4 (pid=pid@entry=101634,
stat_loc=stat_loc@entry=0x7fffffffdd24, options=options@entry=0,
usage=usage@entry=0x0) at ../sysdeps/unix/sysv/linux/wait4.c:30
#1 0x00007ffff7d2b7fb in __GI___waitpid (pid=pid@entry=101634,
stat_loc=stat_loc@entry=0x7fffffffdd24, options=options@entry=0)
at waitpid.c:38
#2 0x0000555555570610 in gnupg_wait_process (
pgmname=pgmname@entry=0x555555589eb0
"/usr/local/bin/gpg-connect-agent",
pid=101634, hang=hang@entry=1, r_exitcode=r_exitcode@entry=0x0)
at exechelp-posix.c:672
#3 0x000055555555e0a3 in keyboxd_runtime_change (killflag=1)
at gpgconf-comp.c:919
#4 0x000055555555d5e4 in do_runtime_change (component=3,
killflag=killflag@entry=1) at gpgconf-comp.c:1018
#5 0x000055555555e5de in gc_component_kill (component=<optimized out>)
at gpgconf-comp.c:1027
#6 0x000055555555bcbf in main (argc=<optimized out>, argv=<optimized out>)
at gpgconf.c:793

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Montag, 6. Dezember 2021 09:41:51 CET Robert J. Hansen via Gnupg-users
wrote:
> > Which version exactly are you using?
>
> 2.3.3.
>
> > Try attaching gdb to see where it hangs.
>
> #12 0x000055555562025c in start_new_keyboxd
> (r_ctx=r_ctx@entry=0x7fffffffd930,
> errsource=errsource@entry=GPG_ERR_SOURCE_GPG,
> keyboxd_program=<optimized out>, autostart=<optimized out>,
> verbose=<optimized out>, debug=<optimized out>, status_cb=0x0,
> status_cb_arg=0x555555684b70) at asshelp.c:635

The problem seems to be caused by the new experimental keyboxd. Try disabling
it. Unfortunately, you may lose all keys stored by the daemon because it
doesn't use the keyrings.

Regards,
Ingo