Smartcard on Linux clients: firefox does not start

[mvogt1]

Hello,

I cannot start thunderbird, firefox every morning, when I start my work day.The problem is smartcard related and only occurs on a Linux client.

I have this behaviour usually when I go home in the evening and reconnect to a locked session in the morning

What happens:

Firefox and thunderbird do not start anymore, "sudo -s" or "pkcs11-tool -L"  command hangs.

The VM, on which this happens, is a RedHat 7.8 with the necessary smartcard fixes see [1], otherwise SCard does not work at all.

What needs to be done, for working SCard, is explained here:

[1] https://communities.vmware.com/thread/613996

But SCard,firefox,thunderbird,... works fine, when connected to the VM from Windows clients!

My VM runs: RHEL 7.8 with Horizon 7.9 or 7.10 ,windows clients works, no problem.

What happens on the Linux Thinclient?

pcscd is complaining:

pcscdaemoni.c 137 SVServicerunLoop : Problem during the context thread creation

winscard_svc.184 CreateContextThread Too many contex running 200

pcscdaeon.c 137:SVServicerunLoop Problem during the context thread creation

When I look a the source:

listSize = list_size(&contextsList);

if (listSize >= contextMaxThreadCounter)

{

        Log2(PCSC_LOG_CRITICAL, "Too many context running: %d", listSize);

        goto out;

}

So, after some time (evening to morning), something is using all context threads and this is the reason why firefox,thunderbird, pkcs11-tool -L ,etc.. hangs.

Rebooting the Thinclient works, and moving the session to another hosts works too to let firefox,thunbird etc. run.

Up to now, I cannot reproduce the bug, I must wait for it, for ~12 hours.

[mvogt1]

Debugging. On the Linux Thinclient the horizon client version is 5.4. On a RHEL 7.8

the horizon client ist version 5.2. On the RHEL client the problem does not occur.

I have written two scripts running in the background on the thinclient.

The scripts counts the number of threads in pcscd and the

number of open sockets of vmware-remotemks. It shows that the number of

threads increase with no real pattern.

But te thread increase has a counterpart in the vmware-remotemks sockets count.

while true; do

  A=`date`;

  B=`ps -o thcount $PID_PCSCD`;

  echo "$A : $B" >>/var/tmp/threads.txt;

  sleep 30;

done

Thu Oct 15 16:21:07 CEST 2020 : THCNT  9

Thu Oct 15 16:26:05 CEST 2020 : THCNT  18

Thu Oct 15 16:27:23 CEST 2020 : THCNT  21

Thu Oct 15 16:55:54 CEST 2020 : THCNT  30

Thu Oct 15 16:56:24 CEST 2020 : THCNT  29

Thu Oct 15 16:56:54 CEST 2020 : THCNT  33

Thu Oct 15 17:09:54 CEST 2020 : THCNT  47

Thu Oct 15 17:10:24 CEST 2020 : THCNT  52

Thu Oct 15 17:25:55 CEST 2020 : THCNT  61

Thu Oct 15 17:26:55 CEST 2020 : THCNT  64

Thu Oct 15 17:31:55 CEST 2020 : THCNT  63

Thu Oct 15 17:32:25 CEST 2020 : THCNT  64

Thu Oct 15 17:55:56 CEST 2020 : THCNT  73

Thu Oct 15 17:56:56 CEST 2020 : THCNT  76

Thu Oct 15 17:57:26 CEST 2020 : THCNT  79

Thu Oct 15 18:14:57 CEST 2020 : THCNT  98

Thu Oct 15 18:25:57 CEST 2020 : THCNT  107

Thu Oct 15 18:26:57 CEST 2020 : THCNT  110

Thu Oct 15 18:42:58 CEST 2020 : THCNT  109

Thu Oct 15 18:43:28 CEST 2020 : THCNT  110

Thu Oct 15 18:55:59 CEST 2020 : THCNT  119

Thu Oct 15 18:56:59 CEST 2020 : THCNT  122

Thu Oct 15 19:11:59 CEST 2020 : THCNT  141

Thu Oct 15 19:26:00 CEST 2020 : THCNT  150

Thu Oct 15 19:27:00 CEST 2020 : THCNT  153

Thu Oct 15 19:55:31 CEST 2020 : THCNT  162

Thu Oct 15 19:57:01 CEST 2020 : THCNT  165

Thu Oct 15 20:05:31 CEST 2020 : THCNT  181

Thu Oct 15 20:16:32 CEST 2020 : THCNT  180

Thu Oct 15 20:17:02 CEST 2020 : THCNT  181

Thu Oct 15 20:26:02 CEST 2020 : THCNT  190

Thu Oct 15 20:27:02 CEST 2020 : THCNT  193

Thu Oct 15 20:52:03 CEST 2020 : THCNT  192

Thu Oct 15 20:55:04 CEST 2020 : THCNT  193

Thu Oct 15 20:56:04 CEST 2020 : THCNT  201

Thu Oct 15 20:57:04 CEST 2020 : THCNT  205

while true; do

  A=`date`;

  B=`lsof -p $PIDOF_VMWARE_REMOTEMKS | grep remote | grep sock | wc -l`;

  echo "$A : $B" >>/var/tmp/socket.txt;

  sleep 30;

done

Thu Oct 15 16:28:01 CEST 2020 : 34

Thu Oct 15 16:54:02 CEST 2020 : 33

Thu Oct 15 16:54:32 CEST 2020 : 34

Thu Oct 15 16:55:32 CEST 2020 : 47

Thu Oct 15 16:56:02 CEST 2020 : 43

Thu Oct 15 16:57:02 CEST 2020 : 46

Thu Oct 15 17:10:33 CEST 2020 : 65

Thu Oct 15 17:25:34 CEST 2020 : 78

Thu Oct 15 17:26:04 CEST 2020 : 74

Thu Oct 15 17:27:04 CEST 2020 : 77

Thu Oct 15 17:29:34 CEST 2020 : 76

Thu Oct 15 17:30:04 CEST 2020 : 77

Thu Oct 15 17:55:35 CEST 2020 : 86

Thu Oct 15 17:57:05 CEST 2020 : 89

Thu Oct 15 17:57:35 CEST 2020 : 92

Thu Oct 15 18:14:36 CEST 2020 : 112

Thu Oct 15 18:15:06 CEST 2020 : 111

Thu Oct 15 18:18:06 CEST 2020 : 110

Thu Oct 15 18:18:36 CEST 2020 : 111

Thu Oct 15 18:26:07 CEST 2020 : 120

Thu Oct 15 18:27:07 CEST 2020 : 123

Thu Oct 15 18:53:38 CEST 2020 : 122

Thu Oct 15 18:54:08 CEST 2020 : 123

Thu Oct 15 18:55:38 CEST 2020 : 132

Thu Oct 15 18:57:08 CEST 2020 : 135

Thu Oct 15 19:11:39 CEST 2020 : 154

Thu Oct 15 19:25:40 CEST 2020 : 163

Thu Oct 15 19:27:10 CEST 2020 : 166

Thu Oct 15 19:42:11 CEST 2020 : 165

Thu Oct 15 19:55:12 CEST 2020 : 166

Thu Oct 15 19:56:12 CEST 2020 : 175

Thu Oct 15 20:05:42 CEST 2020 : 194

Thu Oct 15 20:25:43 CEST 2020 : 203

Thu Oct 15 20:26:44 CEST 2020 : 206

Thu Oct 15 20:55:45 CEST 2020 : 214

Thu Oct 15 20:56:45 CEST 2020 : 218

Thu Oct 15 21:06:16 CEST 2020 : 217

[totti0858]

It seems that the pcscd already created 200 thread and pcsc-lite library do not allow client to create more thread.

Smart card redirection on Linux client was based on the pcsc-lite. Could you please double check the pcsc-lite library version both on your ThinClient and RHEL by using the command "/usr/sbin/pcscd --version" ?

In order to get more log info from pcscd, Please try the command: "sudo pcscd --foreground --debug --apdu --color | tee log.txt".

Wish you can find more clue of why pcscd not work as expected.

[mvogt1]

Debugging.

[root@e120it00 ~]# ps -o thcount 13523

THCNT

   12

❤️ hours passed>

[root@e120it00 ~]# ps -o thcount 13523

THCNT

  179

This happens on a RHEL 7.8 connected to a VM over Horizon with RHEL 7.8 with Agent 7.10 and Client 5.4.1.

==> bug is present on newest vmware-view.

[mvogt1]

Debugging. On the Linux Thinclient the horizon client version is 5.4. On a RHEL 7.8

the horizon client ist version 5.2. On the RHEL client the problem does not occur.

No, the problem exists on 5.2 too.

[root@e120it00 ~]# ps -o thcount 5066

THCNT

   22

[root@e120it00 ~]# ps -o thcount 5066

THCNT

  204

[root@e120it00 ~]# date

Fri Oct 23 09:21:33 CEST 2020

[root@e120it00 ~]# vmware-view --version | grep Client | grep VMware

VMware Horizon Client 5.2.0

The above commands are from a RHEL 7.8 client connected with VMWare Horizon Client 5.2.0 to a RHEL 7.8 VM with Agent 7.10

[mvogt1 · Accepted solution]

VMware fixed this bug. The fix should appear in the next major update VMware-Horizon-Client-2103-8.2.0