Description of problem: I use mutt and a crypto card to sign and/or encrypt email. I *always* have to restart the pcscd daemon before I can successfully sign a message with mutt. I've found this to also happen when trying to read the card using gnupg. This has been going on for a while but my troubleshooting hasn't come up with anything specific. If you can advise me on anything I can check to get an actual error message other than "cannot find card" I'd appreciate it. Otherwise, I'm having this problem... Version-Release number of selected component (if applicable): pcsc-lite-1.8.10-1.fc20.x86_64 How reproducible: Always Steps to Reproduce: 1. Start computer 2. Login to Gnome 3. Open mutt and attempt to sign an email Actual results: gpg: detected reader `Lenovo Integrated Smart Card Reader 00 00' gpg: detected reader `Gemalto USB Shell Token V2 01 00' gpg: apdu_send_simple(0) failed: no card gpg: selecting openpgp failed: no card gpg: signing failed: general error gpg: signing failed: general error Press any key to continue... Expected results: gpg: detected reader `Gemalto USB Shell Token V2 00 00' gpg: detected reader `Lenovo Integrated Smart Card Reader 01 00' gpg: signatures created so far: 1203 Press any key to continue... Additional info:
Please follow http://pcsclite.alioth.debian.org/pcsclite.html#support to generate a log trace.
Created attachment 902170 [details] Error log Here's the log with the error.
I can't find any error in the log you sent. Regenerate a log while reproducing the problem with mutt.
Ummm, the error is right there. 00000032 winscard.c:235:SCardConnect() Attempting Connect to Lenovo Integrated Smart Card Reader 00 00 using protocol: 3 00000014 readerfactory.c:745:RFReaderInfo() RefReader() count was: 1 00000010 winscard.c:290:SCardConnect() Card Not Inserted 00000009 winscard.c:490:SCardConnect() UnrefReader() count was: 2 00000012 winscard_svc.c:453:ContextThread() CONNECT rv=0x8010000C for client 15 00000612 winscard_svc.c:319:ContextThread() Received command: RELEASE_CONTEXT from client 15 00000030 winscard.c:204:SCardReleaseContext() Releasing Context: 0x789A6DCB 00000017 winscard_svc.c:427:ContextThread() RELEASE_CONTEXT rv=0x0 for client 15 00000063 winscard_svc.c:311:ContextThread() Client die: 15 pcscd is not finding the card when it is being asked to sign something.
You are using 2 smart card readers: - Lenovo Integrated Smart Card Reader 00 00 - Gemalto USB Shell Token V2 01 00 You card is present in the "Gemalto USB Shell Token V2 01 00" reader but your application (mutt) is using the "Lenovo Integrated Smart Card Reader 00 00" reader. So of course the application cannot find the card. You need to configure mutt (or the signing application) to use the "Gemalto USB Shell Token V2 01 00" reader. Or you need to insert your card in the "Lenovo Integrated Smart Card Reader 00 00" reader. It is not a pcsc-lite bug.
I'm closing it as not a bug, but if it is not a configuration issue, please feel free to reopen and assign it to the proper component (mutt, gpg-agent or gnome-keyring seem like candidates).
(In reply to Ludovic Rousseau from comment #5) > It is not a pcsc-lite bug. Then why does it work *every time* once I restart pcscd?
It could be anything. For example in your failed log you have: gpg: detected reader `Lenovo Integrated Smart Card Reader 00 00' gpg: detected reader `Gemalto USB Shell Token V2 01 00' While in the working one: gpg: detected reader `Gemalto USB Shell Token V2 00 00' gpg: detected reader `Lenovo Integrated Smart Card Reader 01 00' So the order of detection of the readers may affect gnupg's utilization of the card. I'd suggest to reassign this to gnupg and if it is shown to be any issue in pcscd we take a look again. With the information we have now it doesn't seem to be an issue on pcscd.
I have the same problem. So I decided to do some prodding. First my gear I am using: Omnikey 3821 with a OpenPGP card. Card is blocked, it shows the card is in use. Which at first I thought ESC was still installed, but rpm -qa|grep -i esc perl-Pod-Escapes-1.04-289.fc20.noarch dracut-config-rescue-037-11.git20140402.fc20.x86_64 show nothing. Then I started to wonder about what is using the socket. lsusb Bus 002 Device 005: ID xxxx:3821 OmniKey AG CardMan 3821 lsof /var/run/pcscd/pcscd.comm lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME systemd 1 root 17u unix 0xffff880036843480 0t0 17382 /var/run/pcscd/pcscd.comm pcscd 1933 root 3u unix 0xffff880036843480 0t0 17382 /var/run/pcscd/pcscd.comm pcscd 1933 root 14u unix 0xffff880232d7e900 0t0 27692 /var/run/pcscd/pcscd.comm pcscd 1933 root 15u unix 0xffff880233b2b100 0t0 28134 /var/run/pcscd/pcscd.comm pcscd 1933 root 16u unix 0xffff880233b2a300 0t0 29344 /var/run/pcscd/pcscd.comm Now that is bizarre, why are there so many connections to the socket ? #systemctl restart pcscd lsof /var/run/pcscd/pcscd.comm lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME systemd 1 root 17u unix 0xffff880036843480 0t0 17382 /var/run/pcscd/pcscd.comm pcscd 4924 root 3u unix 0xffff880036843480 0t0 17382 /var/run/pcscd/pcscd.comm Now I have one. systemctl stop pcscd Warning: Stopping pcscd, but it can still be activated by: pcscd.socket gpg2 --card-edit gpg: selecting openpgp failed: Card not present gpg: OpenPGP card not available: Card not present After running gpg2 once, I get an error. lsof /var/run/pcscd/pcscd.comm lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME systemd 1 root 17u unix 0xffff880036843480 0t0 17382 /var/run/pcscd/pcscd.comm No socket created for pcscd. $gpg2 --card-edit Shows my card details. lsof /var/run/pcscd/pcscd.comm lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME systemd 1 root 17u unix 0xffff880036843480 0t0 17382 /var/run/pcscd/pcscd.comm pcscd 5236 root 3u unix 0xffff880036843480 0t0 17382 /var/run/pcscd/pcscd.comm pcscd 5236 root 14u unix 0xffff880094b68000 0t0 112743 /var/run/pcscd/pcscd.comm But why are there now two pcscd sockets ? Now I restart pcscd! #systemctl restart pcscd [root@titan ~]# lsof /var/run/pcscd/pcscd.comm lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME systemd 1 root 17u unix 0xffff880036843480 0t0 17382 /var/run/pcscd/pcscd.comm pcscd 5279 root 3u unix 0xffff880036843480 0t0 17382 /var/run/pcscd/pcscd.comm One socket connection is still there ? gpg2 --card-edit gpg: selecting openpgp failed: Card not present gpg: OpenPGP card not available: Card not present Then I re-run gpg2, same error as before. Re-run it again. Works. But now I have. lsof /var/run/pcscd/pcscd.comm lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME systemd 1 root 17u unix 0xffff880036843480 0t0 17382 /var/run/pcscd/pcscd.comm pcscd 5310 root 3u unix 0xffff880036843480 0t0 17382 /var/run/pcscd/pcscd.comm pcscd 5310 root 14u unix 0xffff8800b4f89500 0t0 113050 /var/run/pcscd/pcscd.comm So, I assume that is normal! And having 4 sockets for some reason blocks it until you restart pcscd. So, there should not be 4 sockets blocking pcscd ?
Sorry, had to reboot. I then modified the systemd files, to get rid of the socket listener. Which did not allow pcscd to start initially: lsof /var/run/pcscd/pcscd.comm lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. lsof: status error on /var/../run/pcscd/pcscd.comm: No such file or directory So, then I start it: systemctl start pcscd [root@titan ~]# lsof /var/run/pcscd/pcscd.comm lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME pcscd 3012 root 3u unix 0xffff880091528700 0t0 33500 /var/run/pcscd/pcscd.comm I see the smartcard is not being locked by something. So then I start gpg2 --card-edit. The card is now shown as locked and: lsof /var/run/pcscd/pcscd.comm lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME pcscd 3012 root 3u unix 0xffff880091528700 0t0 33500 /var/run/pcscd/pcscd.comm pcscd 3012 root 14u unix 0xffff880094eb7000 0t0 35892 /var/run/pcscd/pcscd.comm As seen above, I have two sockets now. So the question is, what is touching the socket, causing it to be blocked as the root user. Because now if I kill scdaemon it relases the card and the reader. If there is any other output I can provide to fix this, please let me know. I can also meet somebody up in irc if that helps. I hope some of this stuff is helpful in trying to diagnose this weird blcoking/locking problem. Regards, Tristan
You should start pcscsd with debug logs to know what is happening. http://pcsclite.alioth.debian.org/pcsclite.html#support Also note (if I am correct) that scdaemon may use the smart card reader _without_ using PC/SC. Maybe you can configure gpg2 to use PC/SC to avoid conflicts.
FWIW, switching from GNOME to KDE fixed this for me.
(In reply to Eric Christensen from comment #12) > FWIW, switching from GNOME to KDE fixed this for me. GNOME keyring simulates gpg-agent so it can be a compatibility issue between the real gpg-agent and the one simulated by gnome. Could you verify that this is the issue? In that case the bug should be reassigned to gnome-keyring.
(In reply to Nikos Mavrogiannopoulos from comment #13) > (In reply to Eric Christensen from comment #12) > > FWIW, switching from GNOME to KDE fixed this for me. > > GNOME keyring simulates gpg-agent so it can be a compatibility issue between > the real gpg-agent and the one simulated by gnome. Could you verify that > this is the issue? In that case the bug should be reassigned to > gnome-keyring. Sorry, I don't have GNOME installed any longer and getting it off my machine was such a pain that I won't be putting it back on. It sounds likely that this is a gnome-keyring issue.
Adding Matthias, maintainer of gnome-keyring. Matthias, could you verify that gnome-keyring indeed replaces gpg-agent, and could cause the issue described in that report?
Created attachment 942571 [details] Debug for boot up of PCSCD This is the debug file output. Piping into tee does not seem to work for systemd. Also I omitted the APDU stuff. If you require that, I will gladly provide that. It looks like it tries to query the card reader then something goes wrong. Maybe that is the reason why it blocks/locks the card reader ?
Created attachment 942572 [details] Manual restart after initial reboot. Here is the log output, when I manually restart using systemd. There appears to be no error and it just works. The card symbol is empty, meaning there is a card slotted in, but not "locked", if that is the right word to use here. Also note the lack of error/failure and no second attempt to read the card.
Sorry, I should have added, please look from 03:04:08 onwards. This clearly requires an expert eye, because I cannot make any sense of this. ;-D So, I hope this helps somewhow, and as I said I will happily get the APDU output as well, if required. So, for now a big thank you, and I hope we can get this issue fixed. FWIW, the gnome-keyring issue I have addressed in the past. There is another bug in mate, where ssh-agent starts under pid 1, and segfaults when somebody tries to kill it. SSH-Agent is started by gnome-keyring/mate-keyring, in the end I had to rename ssh-agent, or there was a socket blocking issue for ssh-agent, when gpg-agent emulates it. Even though I disabled ssh-agent from loading under the start-up options. But that bug is not relevant to the blocking/locking issue, seen here. Regards, Tristan
Tristan, First: do NOT start pcscd by hand if you have systemd configured to start it. This will NOT work. You can kill pcscd if you want and systemd will restart it automatically. Second: you can use lsof to know what client is using pcscd. Just use: $ sudo lsof /usr/lib/x86_64-linux-gnu/libpcsclite.so.1 The library path may be different on your system. I am use Debian here.
I did not Ludovic. I modified systemd to add the --debug argument. Thank you for the idea to check on the library. Just shows I was tired, because I would and should have thought of that. And, I have good news and bad news, depending on who is to blame for the problem here. Just so anyone else can follow, as to what I did: rpm -qa|grep pcsc pcsc-lite-libs-1.8.10-2.fc20.x86_64 pcsc-lite-ccid-1.4.13-1.fc20.x86_64 pcsc-tools-1.4.17-8.fc20.x86_64 pcsc-lite-1.8.10-2.fc20.x86_64 pcsc-perl-1.4.12-8.fc20.x86_64 rpm -ql pcsc-lite-libs /usr/lib64/libpcsclite.so.1 /usr/lib64/libpcsclite.so.1.0.0 /usr/share/doc/pcsc-lite-libs /usr/share/doc/pcsc-lite-libs/COPYING lsof /usr/lib64/libpcsclite.so.1.0.0 lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME libvirtd 3461 root mem REG 253,2 47896 1081788 /usr/lib64/libpcsclite.so.1.0.0 pcscd 3462 root mem REG 253,2 47896 1081788 /usr/lib64/libpcsclite.so.1.0.0 upowerd 3606 root mem REG 253,2 47896 1081788 /usr/lib64/libpcsclite.so.1.0.0 There was also another binary: /usr/libexec/gvfsd-afc that was linked to pcsc-lite. However, systemctl stop libvirt stopped the smartcard + reader from being blocked, before login. And then systemctl stop upower released the block for the smartcard + reader after I logged in. So, now the question is, what is to blame for this not working properly. My understanding was that pcscd can handle multiple connections ? Is this correct ? Or did I misunderstand the man page ? Secondly, who or what do a file a bugzilla against now ? I do not understand why a mobile phone app like gvfs-afc, libvirt or upower need access to the smartcard reader. Libvirt kind of makes sense because you if you use keys, you might need to store them securely, but the others ? Further, before when I restarted pcscd, it released those blocks, so why do they not try to re-engage the smartcard reader after I have restarted it ? This just all seems weird and broken and mildly irritating. ;-D Anyway, thanks agin Ludovic for your extremely valued input and help regarding this matter. Now how do we proceed to address these problems ? Any insights welcome. If you require any further information, or other assistance I can render, in order to fix this, please do not hesitate to ask me. Thank you again. Also, thanks to anyone else who threw in some input, most of it was all valid and should help others to find problems with their setup. Regards, Tristan
I have no idea what libvirtd and upowerd are doing with the smart card and smart card readers. This is new to me. Yes, PC/SC can handle multiple connections. Note that a PC/SC applciation can request an exclusive access to a smart card reader and then block the accesses to the other applications. To progress in the debug I suggest to trace the PC/SC calls made by libvirtd and upowerd. Maybe using PCSC API spy http://ludovicrousseau.blogspot.fr/2011/11/pcsc-api-spy-third-try.html Maybe you should open 1 (or 2) new bug report(s).
Tristan could you please open a new bug report? You issue does not seems to be related to the bug here (and please don't cancel need info requests for other people).
(btw. assign the new bug reports to pcsc-lite, copy paste your comments from here or a summary, and we see how to proceed from there)
Reading that again gives some hints. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME libvirtd 3461 root mem REG 253,2 47896 1081788 /usr/lib64/libpcsclite.so.1.0.0 What I suspect here is the usage of gnutls. As fedora lists opensc libs in the p11-kit configuration gnutls in F20 will call C_Initialize on that library and opensc will open a connection to pcsc. That shouldn't normally affect other programs using it though, as except for opensc initialize no other calls are made that would make it use a card or slot. There could be something in opensc's openpgp smart card support that after opensc's initialization blocks anyone else from using an openpgp card? I'm reassigning back to pcsc-lite until we figure out the culprit.
Ludovic, is there some way to see what each program is using from pcsc-lite, and whether they are blocking each other? (and Tristan, I was apparently wrong)
(In reply to Nikos Mavrogiannopoulos from comment #25) > Ludovic, is there some way to see what each program is using from pcsc-lite, > and whether they are blocking each other? Yes. See PCSC API spy in my comment 21.
Created attachment 943065 [details] spy output Ok, the instructions with opensc-tool are pretty misleading as it seems that now it is not linked against libpcsc. In any case. I tried to run virt-manager (I hope it is a good candidate) and the output is attached. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME virt-mana 18073 nmavrogi mem REG 253,0 19760 2242748 /usr/lib64/libpcscspy.so.0.0.0
This is with a PKCS #11 smart card, but it looks pretty harmless. We most probably need an output with the smart card in question.
(In reply to Nikos Mavrogiannopoulos from comment #27) > Ok, the instructions with opensc-tool are pretty misleading as it seems that > now it is not linked against libpcsc. opensc-tool was never linked against libpcsclite.so.1 I tried "$ LD_PRELOAD=/usr/lib/libpcscspy.so opensc-tool -a" with the current git version of OpenSC and the PC/SC spy does still work. What was your problem? How have you solved it? > In any case. I tried to run virt-manager (I hope it is a good candidate) and > the output is attached. We do not learn much from the PC/SC spy trace: - the application do not call SCardReleaseContext() at the end. This can be considered as a bug. - the application use SCardConnect() with SCARD_SHARE_SHARED so the reader can be shared with other applications. That is good.
I have a similar problem with moneyplex where I had some conversation with matrica. This is really annoying: after system startup the pcscd is available. But when opening moneyplex it complains that there is no card in the reader. My reader is a ReinerSCT cyberJack (pinpad, the version without display). I tried to figure out why this is the case but had no success with changing anything in the .service file. It always works fine after a restart of pcscd. Then I can open and close moneyplex and the card is detected. Today I found out that if I logout from my Gnome session and login again the issue reappears. If I then restart pcscd it works again. So I guess it has something todo with Gnome.
Created attachment 957839 [details] pcscd -a -f -d behaviour when logging off from Gnnome
Sorry all. I am currently stuck in Germany for work reasons and hope to be back in London on Monday and back home Tuesday some time. I will then have more time to investigate further and file further bug reports, if required, and also to work with you all to resolve this matter. So apologies for now. And a comment for Frank, there is some kind of blocking behaviour of the reader, with multiple binaries hogging the reader. As stated previously, if you run lsof /usr/lib64/libpcsclite.so.1.0.0, it should show the processes involved. If you could scroll up please in the bug report, and if you have processes that I have not listed, it would be very useful indeed to compile a full list, or we will be running after this bug for a long time yet. Thank you. Regards, Tristan
Created attachment 957948 [details] lsof output for pcscd lsof output after login to Gnome and after resart of pcscd
Fixed in Fedora 21.