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