Jump to content
Welcome to our new Citrix community!
  • 12

Citrix Receiver for Linux 13.10 won't start on Fedora 29


Dominik Mierzejewski

Question

The following binaries are linked against libidn.so.11, which is available in Fedora 29 as libidn1.34:

/usr/lib64/ICAClient/ServiceRecord
/usr/lib64/ICAClient/util/storebrowse
/usr/lib64/ICAClient/PrimaryAuthManager
/usr/lib64/ICAClient/AuthManagerDaemon
/usr/lib64/ICAClient/wfica

If you don't install the libidn1.34 compatibility package, the above binaries fail to run with the following error:

$ /usr/lib64/ICAClient/wfica
/usr/lib64/ICAClient/wfica: error while loading shared libraries: libidn.so.11: cannot open shared object file: No such file or directory

The solution is to install the libidn1.34 compatibility package:

dnf install libidn1.34

 

Link to comment

Recommended Posts

  • 2
On 4/19/2019 at 8:05 PM, Terry Barnaby said:

I changed wfica to be a shell script that runs "LD_PRELOAD=/lib64/libcrypto.so.1.0.2o wfica1 $*" (Binary wfica moved to wfica1)
 

 

I've been able to get Citrix running on Fedora 29 by installing libidn1.34. With the above hack I can launch sessions from Firefox also.

 

- move /opt/Citrix/ICAClient/wfica to /opt/Citrix/ICAClient/wfica1

- create /opt/Citrix/ICAClient/wfica with content:

#!/bin/sh
ICAROOT=/opt/Citrix/ICAClient
export ICAROOT
LD_LIBRARY_PATH=/opt/Citrix/ICAClient/lib
export LD_LIBRARY_PATH
LD_PRELOAD=/lib64/libcrypto.so.1.0.2o $ICAROOT/wfica1 $*

One thing I have found is that attempting to run Citrix fullscreen causes excessively high CPU usage. It seems to run much better in a window.

  • Like 2
Link to comment
  • 1

It does not seem to be enough here.

 

After copying libidn from Fedora 28 to /usr/lib64 I get a segmentation fault

 

Thread 2 "wfica" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe9101700 (LWP 11455)]
0x00007ffff6e55895 in __strlen_avx2 () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff6e55895 in __strlen_avx2 () from /lib64/libc.so.6
#1  0x00007ffff645e688 in ?? () from /lib64/libcrypto.so.1.1
#2  0x00007fffe3baa058 in doSslHandshake_internal () from /opt/Citrix/ICAClient//libproxy.so
#3  0x00007fffe3ba9de9 in doClientHandshake () from /opt/Citrix/ICAClient//libproxy.so
#4  0x00007fffe3b71d44 in ?? () from /opt/Citrix/ICAClient//libproxy.so
#5  0x00007fffe3b7277e in ?? () from /opt/Citrix/ICAClient//libproxy.so
#6  0x00000000005a4cf3 in ?? ()
#7  0x00007fffe3b84259 in IPSTACKconnect () from /opt/Citrix/ICAClient//libproxy.so
#8  0x00000000004faafa in ?? ()
#9  0x00000000004f8f6d in ?? ()
#10 0x00007fffe86fe7fd in ?? () from /opt/Citrix/ICAClient/PDCRYPT1.DLL
#11 0x00000000004e7425 in Wd_ConnectStream ()
#12 0x0000000000540314 in NCSbind ()
#13 0x0000000000499bc9 in ?? ()
#14 0x00007ffff71b148a in ?? () from /lib64/libglib-2.0.so.0
#15 0x00007ffff712158e in start_thread () from /lib64/libpthread.so.0
#16 0x00007ffff6df1513 in clone () from /lib64/libc.so.6

  • Like 1
Link to comment
  • 1

Similar issue. I also launch Citrix from a browser (Firefox in my case). I upgraded to Fedora 29 this morning and the .ica file downloads rather than automatically opening (which was the behavior prior to the update). I cannot open the file manually either.

 

I am a moderately advanced Linux user, but only use Citrix for email access - so not terribly advanced in that regard.

 

I run Ubuntu 18.04 on my desktop and it's working fine there. Updating to Fedora 29 broke Citrix for me on a laptop and a co-worker's Fedora 29 laptop. So it's definitely something with the upgrade.

 

 

  • Like 1
Link to comment
  • 1
On 07/11/2018 at 1:40 AM, Dominik Mierzejewski said:

I'm working on getting that package into official F29 repositories, too.

And it's on its way to updates-testing: https://bodhi.fedoraproject.org/updates/libidn1.34-1.34-1.fc29

 

18 hours ago, Geerten Schram said:

Ordinary 64-bit Intel it is.

Indeed. Mine is a bit older (Haswell). The only remaining difference might be that I'm using my own repackaged version. I put the spec file and other files here on GitLab. You can use these to build your own binary package and try using that. As I said, it works for me. If that doesn't help then I guess you'll have to open a case with Citrix support.

  • Like 1
Link to comment
  • 1
On 11/9/2018 at 6:53 PM, Keith Calvelli said:

I installed libidn from your repo and built the ICAClient rpm using your spec.  Installation was successful, but performance was abysmal when compared to Fedora 28.

 

So confirmation that this workaround will suffice for some folks and is definitely worth trying.  As for me, I get much better performance firing up a Windows VM and running ICAClient from there.

 

Would be nice to see a permanent solution/fix from Citrix.

Thanks for testing and confirming. One idea I have to explain why you're seeing bad performance is that you might be using Wayland instead of X11 and thus ICAClient is running on Wayland's X11 emulation. Could you retry on a pure X11 session and see if that helps? I'm using MATE Desktop, which runs on X11 (because it doesn't support Wayland yet).

 

Regards,

Dominik

  • Like 1
Link to comment
  • 0
On 2-11-2018 at 1:31 PM, Dominik Mierzejewski said:

The following binaries are linked against libidn.so.11, which isn't available in Fedora 29 by default:


/usr/lib64/ICAClient/ServiceRecord
/usr/lib64/ICAClient/util/storebrowse
/usr/lib64/ICAClient/PrimaryAuthManager
/usr/lib64/ICAClient/AuthManagerDaemon
/usr/lib64/ICAClient/wfica

 

Fedora 29 ships with libidn-1.35, which provides libidn.so.12. As a result, the above binaries fail to run with the following error:


$ /usr/lib64/ICAClient/wfica
/usr/lib64/ICAClient/wfica: error while loading shared libraries: libidn.so.11: cannot open shared object file: No such file or directory

As a workaround one could try extracting libidn.so.11 from Fedora 28 libidn package and putting it in /usr/lib64.

 

I just tried this workaround, but I get the same result from linking libidn.so.12 -> libidn.so.11 and that result is a "Segmentation fault (core dumped)"

Using:

 

$ rpm -q ICAClient
ICAClient-18.10.0.11-0.x86_64

 

1 hour ago, Dominik Mierzejewski said:

How are you running wfica? It doesn't crash for me, but I log in to my company workspace using a browser (Chromium) and just have the virtual desktop launched by wfica via a link from the browser.

 

I'm try to run it from Chrome (with worked with Fedora 28).

When I try to launch the .ica file (coming from a Citrix Netscaler) manually:
 

$ cd /opt/Citrix/ICAClient
$ ./wfica ~/Download/connection.ica
Segmentation fault (core dumped)
$

 

Link to comment
  • 0

Same problem after upgrading over the weekend to Fedora 29. 

 

Citrix support for Fedora is awful; every upgrade leaves it non-functional. 

 

In Fedora 28, I had the rare experience of being able to run the full Citrix receiver directly, without going through Chrome or the Citrix Workspace.  After the Fedora 29 upgrade, the only way I can access it is via a "light" version in Chrome.  I may roll back to Fedora 28 until this is resolved. 

 

Unless....someone here can come up with a solution.

Link to comment
  • 0
7 hours ago, Dominik Mierzejewski said:

Try installing the libidn1.34 package from my COPR instead of manually extracting a libidn.so.11 copy from F28 package:

 

https://copr.fedorainfracloud.org/coprs/rathann/libidn/build/820124/

 

I'm working on getting that package into official F29 repositories, too.

Unfortunately this doesn't help.

 

$ rpm -qa | grep libidn
libidn1.34-1.34-1.fc29.x86_64
libidn-1.35-3.fc29.x86_64
libidn2-2.0.5-2.fc29.x86_64

$ rpm -q ICAClient
ICAClient-13.9.1.6-0.x86_64

$ /opt/Citrix/ICAClient/wfica /home/users/geerten/Downloads/connection.ica 
Segmentation fault (core dumped)


 

Link to comment
  • 0
5 minutes ago, Dominik Mierzejewski said:

I see, thanks for testing. Which hardware are you running this on? Please post the output of


lscpu

or


cat /proc/cpuinfo
$ lscpu 
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              4
On-line CPU(s) list: 0-3
Thread(s) per core:  2
Core(s) per socket:  2
Socket(s):           1
NUMA node(s):        1
Vendor ID:           GenuineIntel
CPU family:          6
Model:               142
Model name:          Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz
Stepping:            9
CPU MHz:             3100.022
CPU max MHz:         3100,0000
CPU min MHz:         400,0000
BogoMIPS:            5424.00
Virtualization:      VT-x
L1d cache:           32K
L1i cache:           32K
L2 cache:            256K
L3 cache:            3072K
NUMA node0 CPU(s):   0-3
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp flush_l1d

Ordinary 64-bit Intel it is.

Link to comment
  • 0
On 11/8/2018 at 4:25 AM, Dominik Mierzejewski said:

And it's on its way to updates-testing: https://bodhi.fedoraproject.org/updates/libidn1.34-1.34-1.fc29

 

Indeed. Mine is a bit older (Haswell). The only remaining difference might be that I'm using my own repackaged version. I put the spec file and other files here on GitLab. You can use these to build your own binary package and try using that. As I said, it works for me. If that doesn't help then I guess you'll have to open a case with Citrix support.

I installed libidn from your repo and built the ICAClient rpm using your spec.  Installation was successful, but performance was abysmal when compared to Fedora 28.

 

So confirmation that this workaround will suffice for some folks and is definitely worth trying.  As for me, I get much better performance firing up a Windows VM and running ICAClient from there.

 

Would be nice to see a permanent solution/fix from Citrix.

Link to comment
  • 0

The package from

 

https://bodhi.fedoraproject.org/updates/libidn1.34-1.34-1.fc29

 

makes no difference. it crashes in the same way

 

#0  0x00007ffff7053915 in __strlen_avx2 () from /lib64/libc.so.6
#1  0x00007ffff665c688 in ?? () from /lib64/libcrypto.so.1.1
#2  0x00007fffe3baa058 in doSslHandshake_internal () from /opt/Citrix/ICAClient//libproxy.so
#3  0x00007fffe3ba9de9 in doClientHandshake () from /opt/Citrix/ICAClient//libproxy.so
#4  0x00007fffe3b71d44 in ?? () from /opt/Citrix/ICAClient//libproxy.so
#5  0x00007fffe3b7277e in ?? () from /opt/Citrix/ICAClient//libproxy.so
#6  0x00000000005a4cf3 in ?? ()
#7  0x00007fffe3b84259 in IPSTACKconnect () from /opt/Citrix/ICAClient//libproxy.so
#8  0x00000000004faafa in ?? ()
#9  0x00000000004f8f6d in ?? ()
#10 0x00007fffe86827fd in ?? () from /opt/Citrix/ICAClient/PDCRYPT1.DLL
#11 0x00000000004e7425 in Wd_ConnectStream ()
#12 0x0000000000540314 in NCSbind ()
#13 0x0000000000499bc9 in ?? ()
#14 0x00007ffff71b148a in ?? () from /lib64/libglib-2.0.so.0
#15 0x00007ffff712158e in start_thread () from /lib64/libpthread.so.0
#16 0x00007ffff6fef593 in clone () from /lib64/libc.so.6

Link to comment
  • 0
1 hour ago, Mario Futire said:

The package from

 

https://bodhi.fedoraproject.org/updates/libidn1.34-1.34-1.fc29

 

makes no difference. it crashes in the same way

[...]

 

I wouldn't expect any difference between the package from my COPR and the one in official updates. As a last resort, could you try building an RPM package from my spec file and running that instead of the official Citrix RPM? It seems to work for @Keith Calvelliand myself.

 

Regards,

Dominik

Link to comment
  • 0

If it matters here is my Haswell cpu

 

processor    : 0
vendor_id    : GenuineIntel
cpu family    : 6
model        : 60
model name    : Intel(R) Core(TM) i5-4460  CPU @ 3.20GHz
stepping    : 3
microcode    : 0x25
cpu MHz        : 2088.440
cache size    : 6144 KB
physical id    : 0
siblings    : 4
core id        : 0
cpu cores    : 4
apicid        : 0
initial apicid    : 0
fpu        : yes
fpu_exception    : yes
cpuid level    : 13
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt dtherm ida arat pln pts flush_l1d
bugs        : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
bogomips    : 6395.71
clflush size    : 64
cache_alignment    : 64
address sizes    : 39 bits physical, 48 bits virtual
power management:
 

Link to comment
  • 0
On 11/13/2018 at 10:45 AM, Dominik Mierzejewski said:

Thanks for testing and confirming. One idea I have to explain why you're seeing bad performance is that you might be using Wayland instead of X11 and thus ICAClient is running on Wayland's X11 emulation. Could you retry on a pure X11 session and see if that helps? I'm using MATE Desktop, which runs on X11 (because it doesn't support Wayland yet).

 

Regards,

Dominik

Hi Dominik,

 

I can confirm it works with your version of libidn and ICAClient, but you have to choose GNOME for xorg at startup to have an acceptable performance.

 

Thx for this great workaround.

 

Ralf

Link to comment
  • 0
On 8-11-2018 at 10:25 AM, Dominik Mierzejewski said:

And it's on its way to updates-testing: https://bodhi.fedoraproject.org/updates/libidn1.34-1.34-1.fc29

 

Indeed. Mine is a bit older (Haswell). The only remaining difference might be that I'm using my own repackaged version. I put the spec file and other files here on GitLab. You can use these to build your own binary package and try using that. As I said, it works for me. If that doesn't help then I guess you'll have to open a case with Citrix support.

Hi Dominik,

Just build your package. I'm already running on X11. But unfortunately it didn't work. Get a different error though (see attachment). It seems like the supplied connection file from my employer is faulty. Depressing.

 

Regards. 

Geerten

 

Screenshot from 2018-11-15 22-57-58.png

Link to comment
  • 0
14 hours ago, Mario Futire said:

Are we saying that the SegFault is down to bad luck and nothing can be done?

 

It seems very strange that on freshly installed F29 it behaves so differently.

 

And I had it working perfectly on F28 as well.

 

 

I don't know why it is crashing and the lack of debug information in the binaries isn't helping. I do have one more idea: are you running the regular version or the -crtbora build (with Seamless Window Feature enabled)? I found that -crtbora binary (/usr/lib/vmware/view/bin/vmware-view-crtbora) is linked with older version of glibmm24 library and Fedora provides a newer version built with C++11 standard support, causing some ABI differences. See https://gitlab.gnome.org/GNOME/glibmm/issues/32 for more details. That might explain the crash if you're using that binary. I also found that if you don't install the Seamless Window Feature, the wrapper script (/usr/bin/vmware-view) will just fail, so I patched it to fall back to regular vmware-view binary (/usr/lib/vmware/view/bin/vmware-view) if -crtbora is not installed. This is done in my package which I linked to above. Please try building it like @Geerten Schram and see if that works for you.

Link to comment
  • 0
13 hours ago, Geerten Schram said:

Hi Dominik,

Just build your package. I'm already running on X11. But unfortunately it didn't work. Get a different error though (see attachment). It seems like the supplied connection file from my employer is faulty. Depressing.

 

Regards. 

Geerten

 

Screenshot from 2018-11-15 22-57-58.png

That looks like SSL Ciphers compatibility issue or missing CA certificates discussed already in other threads: https://discussions.citrix.com/topic/323985-cannot-connect-to-0002-published-app-name-most-distros/ and https://discussions.citrix.com/topic/393904-cannot-connect-to-0002-streetsmart-edge/ .

Link to comment
  • 0
On 11/13/2018 at 4:45 AM, Dominik Mierzejewski said:

Thanks for testing and confirming. One idea I have to explain why you're seeing bad performance is that you might be using Wayland instead of X11 and thus ICAClient is running on Wayland's X11 emulation. Could you retry on a pure X11 session and see if that helps? I'm using MATE Desktop, which runs on X11 (because it doesn't support Wayland yet).

 

Regards,

Dominik

Hey Dominik,

 

You are correct.  There was a significant performance increase when running in an X11 session (though still not at the level of running in a Win10 VM).  Puzzling to me, as I previously ran in F28 on Wayland without noticing performance issues. 

 

Thanks for your work on this!

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...