Jenkins Xvfb libcrypto issue

1
votes

I have a Jenkins Job(for Selenium headless testing). I have installed Xvfb plugin in Jenkins. But when I run the job it gives following error

/var/jenkins_home/Xvfb: error while loading shared libraries: libcrypto.so.10: cannot open shared object file: No such file or directory

Not sure, though the libcrypto.so.10 is also available in PATH variable.

1
seleniumjenkinsxvfb

1 Answers

1
votes

The error message you're getting is indicating that Xvfb can't find the shared object for libcrypto. This happens when the dynamic linker can't locate a dependency of an executable. Generally you can determine which libraries can't be found by using the ldd command as your Jenkins user, for example:

$ ldd /usr/bin/Xvfb
linux-vdso.so.1 (0x00007ffdc6def000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f6bcb054000)
libcrypto.so.10 => not found

The dynamic linker in Linux doesn't generally use the PATH variable to determine where to load libraries from. It usually looks in: the LD_LIBRARY_PATH environment variable, the contents of /etc/ld.so.conf, then /lib, and /usr/lib. More information in this Unix Stack Exchange answer or the man page for ld.so.

Where exactly it looks depends on the distribution you're using and how you've got it configured. You've got a few options for helping Jenkins find your library:

  • Add the path for libcrypto.so.10 to the environment variable LD_LIBRARY_PATH - This should work, but depending on what you're building this may mess up other things. Some (mostly C/C++) build scripts require this to be unset. This does have the advantage of only affecting your Jenkins user and not requiring additional privileges to set up.
  • Add the path for libcrypto.so.10 to the list of paths in the file /etc/ld.so.conf (or on some distributions into its own file in /etc/ld.so.conf.d/. This should work without the nasty side effects of LD_LIBRARY_PATH, but requires root privileges and would affect any user on the computer.
  • Copy (or symlink) libcrypto.so.10 to /usr/lib. This is a brute force tactic and is probably a bad idea since it might mess with your distribution's packaging system but it should work if nothing else does.