Debian/Ubuntu: как исправить libc6 и libstdc++ version mismatch без поломки системы

Ошибки совместимости библиотек в Debian и Ubuntu почти никогда не приходят по одной. В логах можно увидеть GLIBCXX_3.4.29 not found, version `GLIBC_2.34' not found, сообщения про libc6 version mismatch, libstdc++ version mismatch или каскад из broken dependencies после неудачного обновления. На практике это означает одно: бинарник собран в окружении, которое не совпадает с тем, где вы его запускаете.

Чаще всего причина банальна: приложение собрали на более новой системе, а запускают на более старой. Второй распространённый сценарий — ручная установка отдельных .deb, точечный апгрейд из стороннего репозитория или попытка «просто заменить библиотеку», не обновляя остальную систему. Для production это особенно неприятно: сервис перестаёт стартовать, а иногда ломается и пакетный менеджер, если конфликт затронул базовые библиотеки.

Ниже разберём, как быстро понять источник несовместимости, чем отличаются проблемы с libc6 и libstdc++6, какие команды реально помогают в диагностике, когда уместен apt pinning и как организовать безопасный rollback.

Что на самом деле означают GLIBC not found и GLIBCXX not found

В Linux приложение редко бывает полностью автономным. Обычно бинарник динамически линкуется с системными библиотеками. При запуске загрузчик ищет нужные shared libraries, а затем проверяет версии экспортируемых символов. Если программа была собрана с ожиданием более новой версии ABI, чем есть в системе, вы и получаете ошибку.

GLIBC not found почти всегда относится к GNU C Library, то есть к пакету libc6 в Debian и Ubuntu. Это фундаментальная библиотека, на которой завязаны почти все пользовательские процессы. Поэтому любые эксперименты с ней особенно рискованны.

GLIBCXX not found обычно связано с C++ runtime из пакета libstdc++6. Здесь проблема чуть локальнее, но тоже неприятная: приложение на C++, Rust с системными зависимостями, PHP-расширение, Node.js native addon или Python-модуль с нативной частью могут перестать запускаться из-за несовпадения версий libstdc++.

Ключевая мысль: проблема обычно не в отсутствии файла библиотеки, а в том, что в найденной библиотеке нет нужной версии символа или нужного ABI.

Типовые причины binary compatibility проблем в Debian/Ubuntu

Если отбросить теорию, в админской практике почти всегда всплывают одни и те же сценарии.

• Бинарник скопировали с Ubuntu 24.04 на Debian 11 или Ubuntu 20.04.
• Пакет собрали в CI на новом образе, а выкатывают на старые ноды.
• Систему частично обновили: часть пакетов из stable, часть из backports, часть из testing или PPA.
• Установили отдельный .deb через dpkg -i, а зависимости остались старыми.
• Поверх системных библиотек положили нестандартные версии в /usr/local/lib или через LD_LIBRARY_PATH.
• Попытались обновить только libstdc++6 или только libc6, не учитывая зависимости всей цепочки.
• Сделали inplace-обновление production без проверки на staging.

Отдельно отмечу опасный антипаттерн: скачивать libc6 вручную с другого релиза и ставить его в работающую систему. Для Debian и Ubuntu это очень частый путь к сломанному apt, systemd и базовым shell-утилитам.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Если вам нужен отдельный стенд для проверки спорных обновлений и новых сборок, удобнее делать это на изолированном VDS, а не на боевом сервере.

С чего начать диагностику

Первая задача — не чинить вслепую. Нужно понять, какой именно бинарник не запускается, какую библиотеку он ожидает и что реально установлено в системе. На практике базовой связки ldd, readelf и strings хватает для большинства случаев.

1. Посмотреть точное сообщение об ошибке

./myapp
journalctl -u myapp.service -n 50 --no-pager
systemctl status myapp.service

Вам нужна именно строка с недостающей версией символа, например GLIBC_2.34 или GLIBCXX_3.4.30. Это уже даёт направление поиска.

2. Проверить, какие библиотеки подцепляет бинарник

ldd /usr/local/bin/myapp
ldd /path/to/module.so

Если здесь видны неожиданные пути вроде /usr/local/lib, нестандартный каталог приложения или библиотека из другого релиза, причина уже почти найдена. Но помните: ldd не лучший инструмент для недоверенных бинарников, потому что фактически инициирует загрузку. Для аккуратной статической проверки лучше дополнить его следующими командами.

3. Посмотреть, какие версии символов требует бинарник

readelf -Ws /usr/local/bin/myapp | grep GLIBC
readelf -Ws /usr/local/bin/myapp | grep GLIBCXX
readelf -V /usr/local/bin/myapp

Особенно полезен readelf -V: он показывает Version needs и помогает понять, к каким версиям ABI привязан файл.

4. Узнать, какие версии символов есть в установленной библиотеке

strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep GLIBCXX
strings /lib/x86_64-linux-gnu/libc.so.6 | grep GLIBC_

Если бинарнику нужен, например, GLIBCXX_3.4.30, а в системе максимум GLIBCXX_3.4.28, это чистый и понятный libstdc++ version mismatch.

5. Проверить версии пакетов и кандидатов из APT

dpkg -l | grep -E '^ii\s+(libc6|libstdc\+\+6)'
apt-cache policy libc6 libstdc++6
apt-cache madison libc6
apt-cache madison libstdc++6

Так вы увидите, что реально установлено и из какого репозитория доступна другая версия.

Как отличить проблему приложения от проблемы системы

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

Признаки локальной проблемы:

• сломался один сервис или модуль;
• ошибка началась после обновления приложения, а не ОС;
• остальные системные команды работают штатно;
• бинарник находится в /opt, /usr/local или приехал из CI/CD артефакта.

Признаки системной проблемы:

• ошибки появляются у нескольких программ сразу;
• apt сообщает о конфликтах и broken dependencies;
• в системе смешаны репозитории разных релизов;
• проблема началась после ручного обновления базовых пакетов.

Что делать в первую очередь в production

В production главное не «срочно обновить всё», а быстро вернуть работоспособность с минимальным риском. В большинстве случаев лучший первый шаг — откатить приложение или пакет до прежней версии, а не трогать libc6 на живом сервере.

Если у вас есть артефакты предыдущего релиза, атомарный деплой и хранимые пакеты, откат часто занимает минуты. Если откатывать нечего, хотя бы остановите автодеплой, зафиксируйте текущее состояние и снимите данные для анализа: версии пакетов, вывод ldd, readelf, apt-cache policy.

Если ошибка появилась после выката нового бинарника, почти всегда безопаснее откатить бинарник назад, чем обновлять системные библиотеки под него прямо на бою.

Минимальный production rollback

dpkg -l > /root/pkglist-before-rollback.txt
apt-mark showhold > /root/apt-holds.txt
cp -a /etc/apt /root/apt-backup

Дальше сценарий зависит от способа поставки приложения. Для пакетного деплоя полезно иметь локальный кэш прошлых версий. Для релизов через symlink — вернуть предыдущий релиз и перезапустить сервис. Смысл один: сначала восстановить работу, потом уже разбираться, почему сборка оказалась несовместимой.

Для сервисов с PHP-стеком параллельно полезно проверить соседние симптомы на уровне пула и расширений. Если после обновления падает только часть процессов, загляните в материал про диагностику PHP-FPM и slowlog — он помогает отделить библиотечную проблему от зависших воркеров и кривых модулей.

Безопасные стратегии исправления

Пересобрать приложение под целевую систему

Это наиболее правильный путь, если проблема в артефакте. Бинарник нужно собирать в окружении не новее production. Если прод работает на Debian 11, сборка на Ubuntu 24.04 почти гарантированно создаст риск несовместимости. Для переносимых релизов лучше собирать на самом старом поддерживаемом базовом образе.

Практический принцип простой: build old, run new обычно работает; build new, run old часто ломается.

Обновить систему целиком в рамках релиза, а не точечно библиотеку

Если приложение штатно требует библиотеку, доступную в официальных репозиториях вашего релиза, обновление можно делать через APT. Но обновлять только одну базовую библиотеку без анализа зависимостей нельзя.

apt update
apt full-upgrade

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

Проверить и очистить сторонние источники пакетов

grep -R ^deb /etc/apt/sources.list /etc/apt/sources.list.d
apt-cache policy

Если у вас Debian stable, а в списке есть testing, unstable или чужой Ubuntu-репозиторий, то источник проблемы может быть именно там. Частичное смешивание сначала иногда «работает», а потом приводит к труднообъяснимым ABI-конфликтам.

Когда уместен apt pinning, а когда он только ухудшит ситуацию

apt pinning — полезный инструмент, но не волшебная палочка. Он помогает контролировать приоритеты пакетов, например оставлять базовую систему на stable, а отдельные пакеты брать из backports. Проблема в том, что при неаккуратной настройке pinning как раз и создаёт ситуацию частичного обновления, после которой возникают broken dependencies и несовместимости ABI.

Используйте pinning, если:

• вы понимаете, из какого репозитория и почему приходит конкретный пакет;
• есть staging с таким же набором репозиториев;
• зафиксирована политика обновлений;
• есть план отката.

Не используйте pinning как быстрый способ «дотащить одну библиотеку поновее» для случайного бинарника. Для libc6 это особенно плохая идея.

apt-cache policy libc6 libstdc++6
apt-cache policy your-package

Эти команды часто полезнее любого редактирования preferences, пока вы ещё не поняли источник конфликтов.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Как разруливать broken dependencies

Если система уже в полусломанном состоянии и APT ругается на зависимости, действуйте поэтапно. Не ставьте новые пакеты поверх хаоса, пока не увидите согласованную картину версий.

apt --fix-broken install
dpkg --configure -a
apt install -f

После этого снова смотрите политику пакетов:

apt-cache policy libc6 libstdc++6
dpkg -l | grep -E '^..\s+(libc6|libstdc\+\+6)'
apt list --upgradable

Если видно, что часть пакетов пришла из чужого релиза, лучше вернуть список репозиториев к штатному состоянию, сделать apt update и только потом выравнивать систему. Иногда помогает принудительная установка версии из текущего релиза, но для базовых библиотек это нужно делать очень осторожно и только после проверки зависимостей.

Почему нельзя просто подменить libc.so.6 вручную

Потому что libc6 — это не библиотека «для одного приложения», а основа пользовательского пространства системы. Ручная подмена файла в /lib или /lib64 может привести к ситуации, когда перестанут запускаться shell, systemctl, apt, SSH-сессии и любые сервисы после рестарта.

Если очень хочется быстро проверить гипотезу, делайте это не на production и не на хостовой системе. Для изоляции используйте контейнер, chroot, тестовую VM или отдельный стенд. В реальной эксплуатации это экономит часы и спасает от аварийных ночных откатов.

Практичный runbook для администратора

Если собрать всё выше в короткую последовательность, получится рабочий сценарий.

1. Зафиксируйте инцидент: какой сервис сломан, после какого изменения, на каких хостах.
2. Снимите точную ошибку запуска из stdout, journald или unit status.
3. Проверьте зависимости бинарника через ldd.
4. Сравните требуемые и доступные версии символов через readelf и strings.
5. Проверьте версии пакетов и источник кандидатов через apt-cache policy.
6. Определите, локальная ли это проблема приложения или системный конфликт библиотек.
7. В production сначала откатите приложение или пакет до рабочего состояния.
8. Уберите смешанные репозитории и несанкционированные источники пакетов, если они есть.
9. Пересоберите приложение под целевую ОС или планово обновите систему целиком.
10. Зафиксируйте политику сборки и обновлений, чтобы проблема не повторилась.

Как предотвратить повторение проблемы

Лучшая профилактика для ошибок libc6 version mismatch и libstdc++ version mismatch — дисциплина поставки артефактов. Бинарники должны собираться в воспроизводимой среде, совместимой с production. Если у вас несколько поколений серверов, ориентируйтесь на самый старый поддерживаемый релиз. Для нативных модулей и C/C++ зависимостей это особенно важно.

Хорошо работает такой набор практик:

• единый build image для CI;
• staging, повторяющий production по версии ОС;
• запрет на ручную установку случайных .deb в production;
• контроль списка APT-репозиториев через конфигурационное управление;
• хранение предыдущих релизов и пакетов для быстрого rollback;
• документированный процесс обновления базовой системы.

Если вы разворачиваете сервисы на отдельных виртуальных машинах, удобно держать чистые тестовые окружения, где можно безопасно проверять апгрейды библиотек и новых сборок перед выкладкой в production. Для этого подойдут как изолированные стенды на виртуальном хостинге для простых сервисов, так и отдельные VM для более сложных сценариев.

В конечном счёте почти все проблемы этого класса сводятся к одному правилу: не переносите бинарную совместимость «на авось». Проверяйте, где собран артефакт, какие версии ABI он требует и соответствует ли этому целевая система. Тогда сообщения про GLIBCXX not found и GLIBC not found останутся рабочим эпизодом из журнала инцидентов, а не началом большого outage.