Discover не открывается: библиотечный апокалипсис
Если после обновления Discover и другие приложения не открываются, а в терминале появляются ошибки про libsystemd.so.0, libudev.so.1 или glibc, значит, часть пакетов осталась от старой версии библиотек. Лечится это полным обновлением pacman -Syu, переустановкой сломанных пакетов и пересборкой AUR-сборок. Ниже: как диагностировать и чинить по шагам.
Почему приложения не открываются после обновления
«Библиотечный апокалипсис» выглядит так: ты обновил систему, перезагрузился, а Discover молча закрывается или показывает окно с ошибкой. Другие приложения ведут себя так же: KDE-программы, утилиты, игры. Запуск из терминала показывает правду:
discover
discover: error while loading shared libraries: libsystemd.so.0: cannot open shared object file: No such file or directory
Ошибка error while loading shared libraries означает одно: программа собрана против определённой версии библиотеки, а в системе такой библиотеки нет. Приложения в Arch Linux собираются против свежих версий libsystemd, libudev и glibc. Бинарник старой сборки не запустится на новых библиотеках, а новая сборка не запустится на старых. Отсюда и «апокалипсис»: после обновления не открывается не одно приложение, а сразу пачка.
Discover это магазин приложений KDE. Он стартует вместе с Plasma, поэтому первым попадает под удар: система загружается, Discover пытается запуститься и падает. Но он не один такой. Любое приложение, собранное против старых библиотек, ведёт себя одинаково: молча закрывается, показывает пустое окно или вылетает с ошибкой при запуске.
Отдельная история: glibc. Это базовая библиотека языка C, от неё зависит практически всё в системе. Если бинарник собран против новой glibc, а в системе старая, он не запустится вообще. Если наоборот, тоже. Поэтому обновление glibc без обновления остальных пакетов почти гарантированно что-нибудь ломает.
Откуда берётся рассинхрон? Две главные причины.
Частичное обновление
Ты обновил только часть пакетов: pacman -Sy без -u, установку конкретного пакета через pacman -S, или обновил AUR-пакеты, не трогая системные. В системе живут пакеты разных эпох. Библиотеки обновились, а приложения, собранные под старые, остались. Или наоборот. Pacman прямо предупреждает об этом:
warning: system has not been upgraded in more than 24 hours
Это не пустая формальность, а сигнал: дальше pacman -Sy без полного обновления, риск сломать систему.
Классический сценарий: ты хочешь поставить один пакет, запускаешь pacman -Sy пакет, pacman обновляет базы и заодно тянет свежие версии зависимостей. Остальная система остаётся старой. Через неделю ты обновляешь систему целиком, и получаешь рассинхрон, потому что часть пакетов уже обновилась, а часть нет. Именно так и рождается «библиотечный апокалипсис».
Сторонние репозитории и ручные бинарники
Второй источник: сторонние репозитории вроде chaotic-aur и бинарники, положенные в /usr/local вручную. Они собираются под конкретную версию библиотек и не обновляются вместе с системой. После апгрейда glibc или systemd такой бинарник перестаёт запускаться. Причём ломается он тихо: без предупреждений, просто «не открывается».
Chaotic-AUR и другие сторонние репозитории собирают пакеты на своих серверах. Между сборкой и установкой проходит время, и за это время библиотеки в системе успевают обновиться. Пакет из репозитория оказывается собран против версии, которой уже нет. То же самое с бинарниками, скачанными с сайтов: tar.gz с программой, собранной на другом дистрибутиве, это лотерея.
Что такое динамические библиотеки и зачем они нужны
Программы в Linux редко содержат весь код внутри себя. Общий код вынесен в отдельные файлы, динамические библиотеки с расширением .so. При запуске программа подключает их по имени: libsystemd.so.0, libudev.so.1, libc.so.6. Такой подход экономит место и память: одна библиотека используется десятками программ.
Но у него есть оборотная сторона. Библиотека и программа должны совпадать по версии. Программа собрана против libsystemd.so.0 версии 257, а в системе лежит версия 256, запуск может провалиться. Динамический линковщик ищет файл по имени, и если версия не совпадает или файла нет, выдаёт error while loading shared libraries. Имя файла в ошибке это и есть ключ к разгадке.
Версия библиотеки зашита прямо в имя файла: libsystemd.so.0 это soname, стабильный идентификатор ABI. Пока soname совпадает, программа считает библиотеку подходящей. Но внутри версии могут разойтись настолько, что символы, которые ищет программа, исчезнут. Тогда линковщик упадёт с undefined symbol, ещё один вариант «библиотечного апокалипсиса».
Как понять, что сломались именно библиотеки
Запусти проблемное приложение из терминала. Ошибка error while loading shared libraries: прямой признак. Дальше проверь зависимости через ldd:
ldd $(command -v discover)
В выводе ищи строки not found. Если какая-то библиотека не находится, вот она, причина. Для наглядности отфильтруй вывод:
ldd $(command -v discover) | grep "not found"
Так ты узнаешь точное имя недостающей библиотеки: libsystemd.so.0, libudev.so.1 или libc.so.6 (это и есть glibc). Запиши имя, оно понадобится на следующем шаге.
Проверь пару приложений сразу. Если у всех ошибки про одни и те же библиотеки, картина ясна, лечится одним способом. Если приложение запускается из терминала без ошибок, но всё равно не открывается, смотри системный журнал:
journalctl -b -p err | grep -i discover
Там будет причина падения: недостающая библиотека, сбой в конфиге или что-то ещё.
Общая методика диагностики таких проблем в статье «Методика решения проблем в Arch Linux».
Как найти, какому пакету принадлежит библиотека
Когда имя библиотеки известно, выясни, какой пакет её ставит:
pacman -Qo /usr/lib/libsystemd.so.0
Ответ покажет владельца: например, systemd-libs. Если пакет установлен, но файла нет, библиотека пропала или повреждена. Если pacman -Qo ругается, что файл не принадлежит ни одному пакету, подключи базу файлов и поищи по имени:
pacman -Fy
pacman -F libsystemd.so.0
Так найдёшь пакет даже для файла, которого ещё нет в системе. Заодно проверь, какие версии библиотек вообще лежат в /usr/lib:
find /usr/lib -name 'lib*.so*' | grep -E 'systemd|udev'
Сравни с тем, что требует приложение. Расхождение в версиях: диагноз подтверждён. Посмотри и версию glibc:
pacman -Q glibc
Если она новее, чем у собранных вручную бинарников, причина найдена.
Как починить сломанные библиотеки
Порядок действий простой: сначала синхронизируй систему целиком, потом переустанови то, что не починилось, и в конце пересобери локальные сборки. Не пропускай шаги, каждый из них закрывает свой источник рассинхрона.
Полное обновление системы
Первый шаг: синхронизировать всё:
pacman -Syu
Это обновит и библиотеки, и приложения до одной эпохи. После перезагрузки проверь, открывается ли Discover. В большинстве случаев этого хватает. Если обновление прервалось, повтори pacman -Syu ещё раз, pacman продолжит с того места, где остановился.
Переустановка сломанных пакетов
Если полное обновление не помогло, переустанови пакеты, которые владеют проблемными библиотеками:
pacman -S systemd-libs
Pacman перезапишет файлы пакета из кеша или репозитория. Если сломано много пакетов, переустанови их все:
pacman -S $(pacman -Qqn)
Про этот приём подробно в статье «Переустановка всех пакетов».
Пересборка AUR-пакетов
AUR-пакеты собираются локально и привязаны к версиям библиотек на момент сборки. После крупного обновления их нужно пересобрать:
paru -Sua
или вручную для конкретного пакета. Перед пересборкой обнови базы и системные пакеты, иначе AUR-сборка снова соберётся против старых библиотек. Порядок такой: сначала pacman -Syu, потом пересборка AUR. Как пересобирать AUR после крупных обновлений библиотек, разобрано в статье «AUR после крупных библиотек».
Удаление сторонних репозиториев и старых бинарников
Если проблема пришла из стороннего репозитория, отключи его в /etc/pacman.conf и обнови систему. Бинарники из /usr/local проверь вручную:
find /usr/local -name '*.so*'
Старые библиотеки оттуда удали, а программы пересобери или переустанови штатно. Сторонние репозитории отдельная тема: про доверие к ним написано в статье «Chaotic-AUR: доверяем ли мы ему».
После каждого шага проверяй результат: запусти Discover из терминала. Ошибка error while loading shared libraries исчезла, значит, библиотека на месте.
Почему частичное обновление опасно
Arch Linux это rolling release: пакеты обновляются непрерывно, и версии библиотек жёстко связаны с версиями приложений. Обновил glibc, всё, что собрано против старой версии, может перестать запускаться. Обновил systemd, та же история с libsystemd и libudev. Частичное обновление разрывает эту связь, и система превращается в винегрет из несовместимых версий. Поэтому pacman предупреждает при pacman -Sy, а ArchWiki прямо запрещает частичные обновления. Подробный разбор в статье «Почему частичное обновление опасно», а про pacman -Sy без -u в статье «Частичное обновление в pacman».
Запомни простую закономерность: чем дольше система живёт без полного обновления, тем больше рассинхрон и тем больше приложений ляжет после pacman -Syu. Регулярное обновление раз в несколько дней лучшая профилактика. Тогда «библиотечный апокалипсис» просто не успевает накопиться.
Частые вопросы
Discover не открывается, но другие приложения работают: это библиотеки?
Проверь через ldd $(command -v discover). Если нашлись not found, да, библиотеки. Если нет, смотри логи Discover через journalctl или запускай с флагом отладки. Иногда проблема в конфиге или в сломанном кеше, а не в библиотеках. Сброс кеша Discover через настройки Plasma тоже иногда решает дело.
Что делать, если pacman -Syu не помог?
Переустанови пакеты-владельцы библиотек: pacman -S systemd-libs glibc. Затем пересобери AUR-пакеты. Если и это не помогло, проверь /usr/local и сторонние репозитории. Крайний случай: откат обновления до рабочего состояния: верни пакеты к прежним версиям из кеша pacman и перезагрузись.
Почему ошибка про libsystemd.so.0 появляется у KDE-приложений чаще всего?
Discover и другие KDE-программы тянут systemd-libs через зависимости. При частичном обновлении именно эти зависимости расходятся первыми. Плюс KDE-приложения часто ставятся из AUR, а AUR-сборки привязаны к версиям библиотек на момент сборки.
Как не допустить «библиотечного апокалипсиса» снова?
Обновляйся только через pacman -Syu, не используй pacman -Sy без полного обновления, пересобирай AUR-пакеты после крупных обновлений и не клади бинарники в /usr/local без необходимости. Тогда рассинхрон версий не появится.
Полезные ресурсы
- System maintenance (ArchWiki): официальные правила обновления Arch Linux, включая запрет частичных обновлений.
- Pacman (ArchWiki): полная документация по менеджеру пакетов.
Заключение
«Библиотечный апокалипсис» это не поломка системы, а рассинхрон версий: приложения собраны против одних библиотек, а в системе лежат другие. Диагностика занимает минуту: запусти приложение из терминала, посмотри ldd, найди владельца библиотеки через pacman -Qo. Лечение: полное обновление, переустановка сломанных пакетов и пересборка AUR. Главное правило на будущее: никаких частичных обновлений, только pacman -Syu.
Не получилось? Поможем настроить
Задай вопрос в чате — отвечаем быстро, по делу и без воды.
Комментарии