scdaemon (possible?) lockup
Fabio Coatti
fabio.coatti at gmail.com
Tue Oct 4 15:15:05 CEST 2016
Hi All,
I'm experiencing some lockups on scdaemon and searching around yelded no
hints.
Description: (gnupg 2.1.15)
I have a HP laptop with a smartcard reader - identified as Alcor AU9540 that I
use with a gnupgcard.
I have power settings for the reader set to "auto", that means that it gets
powered off by the kernel when not in use (kernel 4.7.6)
What happens can be summarized as if follows:
- card inserted
cova at calvin ~ $ gpg --card-status
gpg: selecting openpgp failed: Errore della scheda
gpg: OpenPGP card not available: Errore della scheda
(basically, card error)
If I remove the card I get the same error instead of "Card not present".
If I kill scdaemon,
cova at calvin ~ $ killall scdaemon
then I get the (correct) message
cova at calvin ~ $ gpg --card-status
gpg: selecting openpgp failed: Scheda non presente
gpg: OpenPGP card not available: Scheda non presente
Inserting the card again, I'm back to "Card error" situation.
So it seems thaat scdaemon gets stuck in "card not present" situation and it
takes a kill to fix it.
It seems likely that this issue can be related to scdaemon.
Next, forcing the smartcard reader to be always powered and not suspended the
behaviour is different:
starting from a "card error" status, like
cova at calvin ~ $ gpg --card-status
gpg: selecting openpgp failed: Errore della scheda
gpg: OpenPGP card not available: Errore della scheda
if I kill scdaemon and then issue a gpg --card-status, everyting works with no
issues.
So my questions are:
1) is it possible that when scdaemon enters the "card error" status it is not
able to exit it unless killed and restarted?
2) is it possible that with kernel turning on and off the power for the
reader, the reader itself requires more time to become operational that
allowed by scdaemon, that then enters into error condition and so behaving
like described in 1?)
Many thanks for any answer. If anything above seems reasonable, I can try to
have a look at the code, even if I'm not, by any means, an expert.
--
Fabio
More information about the Gnupg-devel
mailing list