scdaemon (possible?) lockup

Fabio Coatti fabio.coatti at gmail.com
Wed Oct 5 09:07:52 CEST 2016


In data mercoledì 5 ottobre 2016 08:33:05 CEST, NIIBE Yutaka ha scritto:
> Hello,
> 
> On 10/04/2016 10:15 PM, Fabio Coatti wrote:
> > If I kill scdaemon,
> > cova at calvin ~ $ killall scdaemon
> 
> This doesn't kill scdaemon because scdaemon has a signal handler for
> SIGTERM (If you really want to do this way, you need sending signal at
> least two times to scdaemon).
> 
> Instead, please do this:
> 
>     $ gpgconf --reload scdaemon

You are right, and in fact I was issuing the command twice (redacted for 
clarity in the mail above, but that wasn't a good idea :) )

Anyway, I made the same tests again using reload.
The behaviour can be summarized like this:
Case A: power management set to auto
Card already IN: -> status: card error
scdaemon reloaded -> status: card error
Card pulled out: -> status: card error
Card plugged in: -> status: card error

card plugged out, scd reload, card in and status immediately requested: card 
OK
card plugged out, scd reload, card in, wait a couple of seconds: card error.
basically: no way to came out from error condition (besides reload) and error 
is triggered every time, unless the card is read just after being inserted.


Case B: power management set to ON
starting from a card error condition, reloading scd makes the card to work 
correctly: card not present when plugged out, card OK and read correctly when 
plugged. No other card errors.


So a possible explanation could be:
1. for some reason, when scd enters the "card error status" he can't get off 
until reloaded. 
2. for some other reason, the card reader takes too much to wake up when 
powered off (or scd has a too short timeout), scd enters error condition and 
triggers behaviour described to in 1. Maybe there could also be an error in 
power management of card reader and he can't be woke up by scd but only 
inserting the card.

Those hypotesis can explain the behaviour... but there can also be a host of 
different explanations, I fear.

Given that, a try would be to look a the code of scd to check the behaviour 
when an error occurs and if the error state can be exited in some way, and 
look at timeouts/retries to read the card.

What do you think?


-- 
Fabio



More information about the Gnupg-devel mailing list