From vollkorn at cryptobitch.de  Tue Jan  1 16:37:15 2019
From: vollkorn at cryptobitch.de (Jan Girlich)
Date: Tue, 1 Jan 2019 16:37:15 +0100
Subject: =?UTF-8?Q?Wie_h=c3=a4ngenden_gpg-Prozess_debuggen=3f?=
Message-ID: <7de85912-b95b-1cbf-70e9-c9d970fc9716@cryptobitch.de>

Frohes Neues,

wenn ich versuche gpg zu nutzen, dann geht das nicht, da ein Lock existiert:

% gpg --encrypt --recipient 0x12345678 --armor nachricht.txt
gpg: "Trust-DB" wird überprüft
gpg: waiting for lock (held by 4866) ...
gpg: waiting for lock (held by 4866) ...
^C
gpg: signal Interrupt caught ... exiting

Das habe ich auch schon mal ne Stunde laufen lassen, ohne, dass sich
etwas geändert hätte.

Der Prozess lebt:

% ps -ef | grep 4866

                                   jan       4866  1997  0  2018 ?
 00:00:34 gpg --batch --no-sk-comments --lc-messages de_DE.UTF-8
--lc-ctype de_DE.UTF-8 --status-fd 15 --no-tty --charset utf8
--enable-progress-filter --exit-on-status-write-error --display :0
--with-colons --list-keys --

Und es scheint er wurde durch systemd gestartet:

% pstree -p -s 4866
systemd(1)???systemd(1997)???gpg(4866)

Jetzt frage ich mich wie ich herausfinden kann warum dieser Prozess
nicht fertig wird. Wie kann ich das nachschauen? Gibt es eine
Möglichkeit bei einem laufenden Prozess sich ranzuhängen und mit
watchgnupg oder so reinzuschauen?

Gruß
Jan


From kardan at riseup.net  Tue Jan  1 19:22:35 2019
From: kardan at riseup.net (kardan)
Date: Tue, 1 Jan 2019 13:22:35 -0500
Subject: Wie =?UTF-8?B?aMOkbmdlbmRlbg==?= gpg-Prozess debuggen?
In-Reply-To: <7de85912-b95b-1cbf-70e9-c9d970fc9716@cryptobitch.de>
References: <7de85912-b95b-1cbf-70e9-c9d970fc9716@cryptobitch.de>
Message-ID: <20190101132235.359102ab@debian>

On Tue, 1 Jan 2019 16:37:15 +0100
Jan Girlich <vollkorn at cryptobitch.de> wrote:

> Frohes Neues,

Ebenso!

> Jetzt frage ich mich wie ich herausfinden kann warum dieser Prozess
> nicht fertig wird. Wie kann ich das nachschauen? Gibt es eine
> Möglichkeit bei einem laufenden Prozess sich ranzuhängen und mit
> watchgnupg oder so reinzuschauen?

Bestimmt hilft strace:

strace gpg --encrypt --recipient 0x12345678 --armor nachricht.txt

oder

strace -p 4866

Viel Erfolg!


From vollkorn at cryptobitch.de  Sun Jan  6 17:50:25 2019
From: vollkorn at cryptobitch.de (Jan Girlich)
Date: Sun, 6 Jan 2019 17:50:25 +0100
Subject: =?UTF-8?B?Z251cGcgaMOkbmd0IGJlaSAid3JpdGUoMTUsICJbR05VUEc6XSBLRVlf?=
 =?UTF-8?Q?CONSIDERED_12345678=22=2e=2e=2e=2c_67=22?=
In-Reply-To: <20190101132235.359102ab@debian>
References: <7de85912-b95b-1cbf-70e9-c9d970fc9716@cryptobitch.de>
 <20190101132235.359102ab@debian>
Message-ID: <5b165710-2464-8e4e-8b97-5b1fa3909ba4@cryptobitch.de>

Moin,

hat ein paar Tage gedauert, bis ich wieder einen hängenden Prozess
hatte, aber jetzt ist es passiert.

% sudo strace -p 11696

                                     strace: Process 11696 attached
write(15, "[GNUPG:] KEY_CONSIDERED 12345678"..., 67

Und da hängt der Prozess. Keine weitere Ausgabe.

Da der Prozess hängt und jeder Aufruf von gpg nur zu folgender Ausgabe
führt, kann ich auch nicht nachschauen was für ein Key das ist, der dort
genannt wird. Ist aber nicht auf den Servern zu finden. Also scheinbar
ein Key, den ich mal importiert habe. Daher habe ich den unkenntlich
gemacht.

Es scheint auch wieder genau der gleiche Aufruf zu sein:

% ps -ef | grep 11696
jan      11696  2180  0 11:01 ?        00:00:37 gpg --batch
--no-sk-comments --lc-messages de_DE.UTF-8 --lc-ctype de_DE.UTF-8
--status-fd 15 --no-tty --charset utf8 --enable-progress-filter
--exit-on-status-write-error --display :0 --with-colons --list-keys --

% pstree -p -s 11696
systemd(1)???systemd(2180)???gpg(11696)

Zu "KEY_CONSIDERED" finde ich nur haufenweise FOSS-Projekte, die einen
Bug-Report dazu haben, dass sie den Status noch abfangen müssen. Was
sagt mir, dass gnupg beim Versuch diese Zeile rauszuschreiben hängen bleibt?

Hier noch meine genaue Version:

% gpg --version
gpg (GnuPG) 2.2.4
libgcrypt 1.8.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/jan/.gnupg
Unterstützte Verfahren:
Öff. Schlüssel: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Verschlü.: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
           CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Komprimierung: nicht komprimiert, ZIP, ZLIB, BZIP2

Gruß
Jan




From vollkorn at cryptobitch.de  Sun Jan  6 18:28:24 2019
From: vollkorn at cryptobitch.de (Jan Girlich)
Date: Sun, 6 Jan 2019 18:28:24 +0100
Subject: =?UTF-8?B?UmU6IGdudXBnIGjDpG5ndCBiZWkgIndyaXRlKDE1LCAiW0dOVVBHOl0g?=
 =?UTF-8?B?S0VZX0NPTlNJREVSRUQgMTIzNDU2NzgiLi4uLCA2NyI=?=
In-Reply-To: <5b165710-2464-8e4e-8b97-5b1fa3909ba4@cryptobitch.de>
References: <7de85912-b95b-1cbf-70e9-c9d970fc9716@cryptobitch.de>
 <20190101132235.359102ab@debian>
 <5b165710-2464-8e4e-8b97-5b1fa3909ba4@cryptobitch.de>
Message-ID: <20658e66-9ab4-1dc0-0eec-32a42bdec48d@cryptobitch.de>

Moin,

ich habe ein paar weitere Details gefunden.

Der hängende Prozess hat mehrere Dateien geöffnet:

% ls -l /proc/11696/fd
insgesamt 0
lrwx------ 1 jan jan 64 Jan  6 11:01 0 -> /dev/null
l-wx------ 1 jan jan 64 Jan  6 11:01 1 -> 'pipe:[176454]'
l-wx------ 1 jan jan 64 Jan  6 11:01 15 -> 'pipe:[176453]'
lrwx------ 1 jan jan 64 Jan  6 11:01 2 -> /dev/null
lrwx------ 1 jan jan 64 Jan  6 11:01 3 -> /home/jan/.gnupg/trustdb.gpg
lr-x------ 1 jan jan 64 Jan  6 11:01 4 -> /home/jan/.gnupg/pubring.gpg
l-wx------ 1 jan jan 64 Jan  6 11:01 5 -> /home/jan/.gnupg/pubring.gpg.tmp
lr-x------ 1 jan jan 64 Jan  6 11:01 6 -> /home/jan/.gnupg/pubring.gpg
lr-x------ 1 jan jan 64 Jan  6 11:01 7 -> /home/jan/.gnupg/pubring.gpg

Bemerkenswert finde ich, dass die pipes in meiner zsh rot dargestellt
werden, aber ich weiß nicht was das bedeutet. Sind die Pipes gestorben?

% lsof | grep 176454

                                     seahorse  11654
jan   16r     FIFO               0,12       0t0     176454 pipe
dconf\x20 11654 11661              jan   16r     FIFO               0,12
      0t0     176454 pipe
gmain     11654 11662              jan   16r     FIFO               0,12
      0t0     176454 pipe
gdbus     11654 11665              jan   16r     FIFO               0,12
      0t0     176454 pipe
gpg       11696                    jan    1w     FIFO               0,12
      0t0     176454 pipe

% lsof | grep 176453
seahorse  11654                    jan   13r     FIFO               0,12
      0t0     176453 pipe
dconf\x20 11654 11661              jan   13r     FIFO               0,12
      0t0     176453 pipe
gmain     11654 11662              jan   13r     FIFO               0,12
      0t0     176453 pipe
gdbus     11654 11665              jan   13r     FIFO               0,12
      0t0     176453 pipe
gpg       11696                    jan   15w     FIFO               0,12
      0t0     176453 pipe

Es sieht für mich so aus als hat er sich tatsächlich beim Auflisten von
Public Keys aufgehängt. Verstehe ich das richtig, dass
Seahorse/dconf/gmain/gdbus versuchen sich die Keys auflisten zu lassen?

Und gnupg hat sich beim Schreiben in die Pipe 176453 aufgehängt? (15w,
siehe auch strace: "write(15, ...")

Es gibt zeitgleich ein paar weitere gnupg-Prozesse, die aber alle laut
strace auf /home/jan/.gnupg/pubring.gpg.lock warten.

Gruß
Jan