Error while loading shared libraries libnss3 so

Новые и опытные пользователи Linux могут сталкиваться с ошибкой error loading shared libraries во время запуска программ, также с ней могут сталкиваться программисты и все желающие компилировать программное обеспечение в своей системе. Эта ошибка в дословном переводе означает что возникла проблема во время загрузки общей библиотеки. О том что такое библиотеки и зачем они нужны вы можете узнать из статьи библиотеки Linux.

В этой же статье мы рассмотрим что значит ошибка error while loading shared libraries более подробно, а главное, как ее решить.

Даже если вы не компилируете свои программы, то вы можете увидеть ошибку error while loading shared libraries: имя_библиотеки: cannot open shared object file: No such file or directory достаточно часто во время установки новых программ не через пакетный менеджер или программ, предназначенных для другого дистрибутива. Как я уже говорил, она возникает потому, что система не может найти библиотеку.

А вот почему ее нельзя найти и загрузить, это уже интересно. Этому может быть несколько причин:

• Библиотека не установлена в системе;
• Библиотека установлена, но неизвестно куда;
• Библиотека установлена правильно, но имеет не ту версию.

При решении проблемы мы будем руководствоваться именно этими причинами и пытаться их решить.

Как исправить ошибку?

1. Библиотека не установлена

Первый вариант, тут все понятно, библиотеки просто нет в системе, поэтому мы и получаем такую ошибку. Верный способ ее решения — просто найти пакет библиотеки с помощью пакетного менеджера и установить ее. Обычно, пакеты с библиотеками называются так же, как и сами библиотеки с префиксом lib.

Например, если нам не хватает библиотеки libfuse2.so, то мы можем найти ее в Ubuntu такой командой:

sudo apt search libfuse2

Затем осталось только установить ее:

sudo apt install libfuse2

Если перед вами стоит задача собрать программу из исходников, то вам понадобится не только установить саму библиотеку, но и заголовочные файлы для нее:

sudo apt install libfuse-dev

И так для любой библиотеки. Но это не всегда помогает.

2. Библиотека находится не в том каталоге

Бывает что библиотека установлена, мы установили ее или она поставлялась вместе с программой, но ошибка как была, так и есть. Причиной этому может быть то, что загрузчик Linux не может найти библиотеку.

Поиск библиотек выполняется по всех папках, которые указаны в конфигурационных файлах /etc/ld.conf.d/. По умолчанию, это такие каталоги, как /usr/lib, /lib, /usr/lib64, /lib64. Если библиотека установлена в другой каталог, то, возможно, это и есть причина проблемы.

Вы можете посмотреть какие библиотеки сейчас доступны загрузчику с помощью команды:

Найти, где находится ваша библиотека можно с помощью команды locate. Например, нас интересует библиотека librtfreader.so:

Теперь мы знаем, что она находится по адресу /opt/kingsoft/wps-office/office6/. А значит, для работы программы необходимо сделать чтобы загрузчик библиотек ее видел. Для этого можно добавить путь в один из файлов /etc/ld.so.conf.d/ или же в переменную LD_LIBRARY_PATH:

Опять же, так вы можете поставить с любой библиотекой, которая взывает ошибку. Еще один более простой метод — это просто создать символическую ссылку на нужную библиотеку в правильной папке:

ln -s /opt/kingsoft/wps-office/office6/librtfreader.so /usr/lib/librtfreader.so

3. Неверная версия библиотеки

Эта причина ошибки довольно часто встречается при использовании программ не для вашего дистрибутива. Каждая библиотека имеет дополнительную версию, так называемую ревизию, которая записывается после расширения .so. Например, libav.so.1. Так вот, номер версии меняется всякий раз, когда в библиотеку вносятся какие-либо исправления.

Часто возникает ситуация, когда в одном дистрибутиве программа собирается с зависимостью от библиотеки, например, libc.so.1, а в другом есть только libc.so.2. Отличия в большинстве случаев здесь небольшие и программа могла бы работать на второй версии библиотеки. Поэтому мы можем просто создать символическую ссылку на нее.

Например, библиотеки libusb-1.0.so.1 нет. Но зато есть libusb-1.0.so.0.1, и мы можем ее использовать:

Для этого просто создаем символическую ссылку на библиотеку:

sudo ln -s /usr/lib/libusb-1.0.so.0.1 /usr/lib/libusb-1.0.so.1

В большинстве случаев программа не заметит подмены и будет работать, как и ожидалось. Также для решения этой проблемы можно попытаться найти нужную версию библиотеки в интернете для своей архитектуры и поместить ее в папку /usr/lib/ или /usr/lib64/. Но после этого желательно обновить кэш:

Выводы

В этой статье мы рассмотрели почему возникает ошибка Error while loading shared libraries, а также как ее решить. В большинстве случаев проблема решается довольно просто и вы получите работоспособную программу. Надеюсь, эта информация была полезной для вас.

Источник

There is a list of common errors I often see in Ubuntu. There is problem with merge list, then there is BADSIG error, and a number of common Ubuntu update errors.

One of such common errors which I often see while installing a program from its source code is error while loading shared libraries. The full error generally looks like this:

error while loading shared libraries:
cannot open shared object file: No such file or directory

For example, I was trying to use FreeRADIUS server and it showed me this error:

The reason behind this error is that the libraries of the program have been installed in a place where dynamic linker cannot find it.

Let me show you how you can go about fixing this issue.

One quick way to fix this “error while loading shared libraries” automatically is to use ldconfig.

All you need to do is to open terminal (Ctrl+Alt+T) and type the following command:

This one liner should solve the problem in most cases. However, if it doesn’t, I have discussed another method to handle this error. But before that, let me tell you what does the above command do.

What are shared object files? How does the above command fixes the issue?

You see, in C/C++, a .so (shared object) is a compiled library file. It is called shared object because this library file can be shared by several programs. These generated libraries are usually located in /lib or /usr/lib directories.

Now if you wonder how did this tiny command fixed this problem, you should read the man page of ldconfig which says:

ldconfig creates the necessary links and cache to the most recent shared libraries found in the directories specified on the command line, in the file /etc/ld.so.conf, and in the trusted directories (/lib and /usr/lib). The cache is used by the run-time linker, ld.so or ld-linux.so. ldconfig checks the header and filenames of the libraries it encounters when determining which versions should have their links updated.

I hope this quick fix helps you in eliminating the nasty error while loading shared libraries message in Ubuntu and other Linux.

If not, you can do some investigation and try to fix the issue the way it is mentioned in the next section.

The above discussed method fixes the issue if the library in question is available in your system. But that may not always be the case.

If you do not have the program installed on your system, you won’t have its library file. The ldconfig cannot do anything if there is no library file in the first place.

So, the alternate method is to install the required program and it should create the library automatically.

Let me show it to you by an example. Let’s say you see this error:

The problem is with libgobject version 2.0. The version number is important because some programs depend on a specific version of the library and if they don’t find, they complain about it.

Now, apt provides the search option that can be used for searching a package and knowing its version before installing it.

Now, this librust-gobject-sys-dev package could be what you need if you know that you were trying to run a Rust program. But what if it was a Python program you were running that complained about it?

You can widen your search by removing the lib from the package name while searching. The lib signifies library and libraries may be provided by a generic package that could be named gobject-xyz.

It would be a good idea to search for the string in the names of the package (instead of description) to get more concise results.

In the above truncated output, you’ll have to see if the package is related to the original program you were trying to run. You must also check the version of the library provided.

Once you have identified the correct package, install it like this:

Once installed, you may run the ldconfig command again to update the cache:

This method requires some effort on your end but this is how the dependencies are handled.

Nothing works, what now?

If you are unfortunate enough, the above methods might not work for you. What can you do?

First, keep in mind that the shared libraries may be used from other packages in some cases. If you were trying to run XYZ program and ABC program installs the correct version of the shared library, it may (or may not) work for you. You can give it a hit and trial.

Second, if you are trying to run a program which is too old or too new, it may require a library version which is not available for your Linux distribution.

What you may do is to check if you can use some other version of the program. For example, using Eclipse version 3 instead of version 4. This may help your case.

The other way would be to check the developers website or forums and see if you can manually install the correct version of the library from its source code. That requires a lot of effort (in 2020) but you don’t have a lot of options.

Did it work for you?

I hope I have make things a bit more clear for you. Did you manage to fix the issue of shared libraries in your system? If you have questions, suggestions, feel free to drop a comment. Ciao 🙂

Источник

[BUG] Failed to launch the browser process: error while loading shared libraries: libnss3.so: cannot open shared object file #164

Environment

• chrome-aws-lambda Version: 3.0.4
• puppeteer / puppeteer-core Version: 3.0.4
• OS: Mac
• Node.js Version: 12.x
• Lambda / GCF Runtime: nodejs12.x

Expected Behavior

Chrome should have load.

Current Behavior

Error: Failed to launch the browser process!
/tmp/chromium: error while loading shared libraries: libnss3.so: cannot open shared object file: No such file or directory

TROUBLESHOOTING: https://github.com/puppeteer/puppeteer/blob/master/docs/troubleshooting.md
at onClose (/var/task/node_modules/puppeteer-core/lib/Launcher.js:547:20)
at Interface. (/var/task/node_modules/puppeteer-core/lib/Launcher.js:537:65)
at Interface.emit (events.js:327:22)
at Interface.EventEmitter.emit (domain.js:483:12)
at Interface.close (readline.js:416:8)
at Socket.onend (readline.js:194:10)
at Socket.emit (events.js:327:22)
at Socket.EventEmitter.emit (domain.js:483:12)
at endReadableNT (_stream_readable.js:1220:12)
at processTicksAndRejections (internal/process/task_queues.js:84:21)

Steps to Reproduce

Previously my code was running properly on nodejs8.10 supported AWS Lambda function but after forcefully upgrade to nodejs12.x, my code starts to throw this error. I tried upgrading chrome-aws-lambda and puppeteer-core version to 2.1.1 and even the latest 5.3.1 but no luck on resolving the issue.

The text was updated successfully, but these errors were encountered:

@pmakkar93 With Node 12 the Lambda environment needs provisioning of additional shared libraries for Chromium to work, the earliest version that would work on this environment is precisely 3.0.4 (I advise you to upgrade to the latest 5.3.x though).

I think the issue that you’re facing might be caused by a warm Lambda that is still keeping the files under /tmp and thus preventing these libraries from being provisioned. Please try a brand new deployment with 3.0.4 or any version since.

Edit: I just noticed that you’re trying this on Mac? If so please check this wiki page.

@alixaxel Any potential workaround for this? I also have this exact same problem but since 2.0.0, Puppeteer introduced a change that broke clipping beyond the viewport and this was needed to curve a lot of issues with the screenshotting mechanism.

I’m getting this same issue with:

• node 12
• chrome-aws-lambda 5.3.1
• puppeter-core 5.3.1

It’s not the exactly same case but I’ve seen same issue to initialize the browser object, missing libnss3.so. In my case it only happens when I run the lambda with aws-sam-cli in debug mode.
Actually I don’t see the issue if I run the lambda at my local with normal mode (i.e. run with sam local invoke ), but in debug mode ( sam local invoke -d 5858 ) I can see the error message Failed to launch the browser process!n/tmp/chromium: error while loading shared libraries: libnss3.so: cannot open shared object file: No such file or directory .

Actually I could notice that the environment variable AWS_EXECUTION_ENV is not defined in local lambda container if I run in debug mode, it’s there in normal mode on the other hand.
And when I set that variable in template.yaml file (which contains the definition of serverless application in aws sam), then the error was gone.
My experience is only in aws sam, but hope this can be a clue to resolve someone’s trouble.
My environment is:

• Mac Catalina
• chrome-aws-lambda: 5.3.1
• puppeteer-core: 5.3.1
• Node: 12.x

Also, I know there are few lines which use AWS_EXECUTION_ENV as a switch to modify env variables like https://github.com/alixaxel/chrome-aws-lambda/blob/master/source/index.js#L6.
It can be better to have more robust check routine since I’ve seen it’s not always defined.

I get the same error, but not related to AWS, but Linux on a Windows 10 machine using WSL 2 (Ubuntu 20.04.1 LTS) and Puppetter: 5.5.0:
ChromeHeadless stderr: /home/sandstedt/_open-source/mojs/node_modules/puppeteer/.local-chromium/linux-818858/chrome-linux/chrome: error while loading shared libraries: libnss3.so: cannot open shared object file: No such file or directory

Solved it by installing all missing dependencies listed here: Puppeteer Troubleshooting

This may be helpful to some, to check which libs are missing just do cd /project_folder/node_modules/puppeteer/.local-chromium/linux-version/chrome-linux/ ldd chrome | grep not make sure to change the folders to your own folders, hope this helps.

I just pushed up my code to AWS Lambda, and I’m getting the exact same error. New deployment (actually never been deployed before), NodeJs12, using the shelfio layer.

Also got the same error following the instructions in the Lambda Layers option. The resulting zip file, pushed up to AWS Lambda, triggers the same error, missing libnss3.so .

Here is how I fixed mine.

• First, I ran an update.

• Move to the chromium directory.

but replace the bracketed directories with the directories available in your node_modules folder. There you should find the local installation of chrome and from there you ran the next command.

• Next, run this

on a Linux machine to check which dependencies are missing.
Read more here Chrome headless doesn’t launch on UNIX

• Run this to install the missing libraries or packages.

• Run this again to check if the missing packages are installed
  ldd chrome | grep not this time nothing is shown on the terminal, so you should be good.
• In your JS code, add this

That is it. You are good to go. Hopefully, this helps someone. 😄

Источник