From bug 3548: ------- Comment #9 From Peter Åstrand 2010-09-02 13:54 [reply] ------- (In reply to comment #4) > I've noticed that it is possible to trigger this problem by doing a kill -STOP > on the pcscd process. Not good. I think we need to enhance tlclient, so that it > disconnects if "it is not possible to communicate with the daemon/reader/card", > rather than "disconnect if it receives a change event". But as Pierre points > out, many of the higher level operations are very slow and may block. They can > also be unavailable if an application has locked the card. Handling the case with -STOP might be over ambitious. However, I've verified that the problem occurs with kill -9 on pcscd as well. I think we should at least handle this case. I've done some stracing and there's *no* difference in the system calls before and after killing pcscd. So apparently, tlclient/libpcsclite does not verify if the pcscd daemon is still alive; it just sits there waiting for it to signal any events.
Another idea is to try to get vncviewer dependent on the tlclient process, to avoid that the smart card yanking fails if tlclient.bin crashes. If tlclient.bin crashes, it's better to notice this.
