В Linux можно диагностировать загрузку динамических библиотек ещё до запуска самой программы!

Если приложение падает с ошибкой cannot open shared object file, проблема часто не в отсутствии библиотеки, а в том, где именно загрузчик её ищет.

У динамического загрузчика Linux есть собственные диагностические возможности:

LD_DEBUG=libs ./myapp

Команда покажет поиск библиотек по каталогам, включая пути из RPATH, RUNPATH, переменных окружения и системных настроек.

А если нужно проверить зависимости без запуска main(), можно вызвать загрузчик напрямую:

/lib64/ld-linux-x86-64.so.2 --list ./myapp

Он покажет, какие зависимости удалось разрешить и какие файлы библиотек будут использованы.

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

# Посмотреть диагностические данные загрузчика
/lib64/ld-linux-x86-64.so.2 --list-diagnostics ./myapp

Последняя возможность доступна в glibc начиная с версии 2.33. Путь к загрузчику зависит от архитектуры и дистрибутива, а диагностика LD_DEBUG может быть ограничена для защищённых исполняемых файлов.

🔥 В следующий раз, когда приложение не найдёт .so, не спешите создавать симлинки и менять LD_LIBRARY_PATH. Сначала посмотрите, где загрузчик ищет библиотеку.

🚪 Linux Ready | #совет

📂 Шпаргалка по протоколу NTP!

Например, NTP позволяет синхронизировать системное время компьютеров и серверов, а временные метки T1–T4 помогают рассчитать сетевую задержку и смещение часов.

На картинке — принцип работы NTP, основные формулы, режимы синхронизации и иерархия NTP-серверов.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

В Linux можно найти процессы, использующие конкретный порт или файл, без просмотра полного списка открытых дескрипторов!

Для этого есть fuser из пакета psmisc. Он удобен, когда сервис не запускается из-за занятого порта:

sudo fuser -v -n tcp 8080

Команда покажет процессы, связанные с TCP-портом 8080. А если нужно узнать, кто использует файл или каталог:

sudo fuser -v /var/log/myapp.log

Есть и более интересный сценарий: выяснить, какие процессы мешают размонтировать файловую систему:

sudo fuser -vm /mnt/data

Здесь -m ищет процессы, использующие файлы на той же файловой системе, что и указанный путь. Это полезно при ошибке target is busy.

🔥 fuser позволяет быстро перейти от проблемного ресурса к процессу, который его использует. Что полезно при отладке занятых портов и размонтировании файловых систем.

🚪 Linux Ready | #совет

В Linux можно передать уже открытый сетевой сокет другому процессу без повторного открытия порта!

Этот механизм называется socket activation. Его поддерживает systemd: он сам открывает порт и передаёт готовый файловый дескриптор запускаемому сервису.

Например, можно создать сокет для приложения:

# /etc/systemd/system/myapp.socket
[Socket]
ListenStream=8080

[Install]
WantedBy=sockets.target

После включения сокета systemd начинает слушать порт, даже если приложение ещё не запущено:

sudo systemctl daemon-reload
sudo systemctl enable --now myapp.socket

Когда приходит подключение, ядро ставит его в очередь, а systemd запускает myapp.service и передаёт ему слушающий сокет. Для работы нужен соответствующий unit-файл и приложение с поддержкой socket activation (например, через LISTEN_FDS). Обычный сервер, самостоятельно вызывающий bind(), без адаптации не подойдёт.

Проверить состояние можно так:

systemctl status myapp.socket
systemctl list-sockets

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

🔥 Socket activation позволяет отделить владение сетевым портом от жизненного цикла приложения. Полезно для сервисов с редкими запросами, запуска по требованию и сокращения перерывов при перезапуске.

🚪 Linux Ready | #совет

✍️ linux-book — большое руководство по Linux на русском языке!

В репозитории собраны материалы по работе с командной строкой, файловой системой, процессами, пользователями, правами доступа, сетями и администрированию системы. Здесь есть не только объяснения основных принципов Linux, но и примеры команд, настройки и практические рекомендации, к которым удобно возвращаться во время работы.

Оставляю ссылочку: GitHub 📱

🚪 Linux Ready | #репозиторий

Как диагностировать проблемы с MTU и Path MTU Discovery в линукс?

TCP-соединение установилось, мелкие пакеты проходят, а передача данных зависает? Возможно, поймали PMTU black hole: крупные пакеты с DF отбрасываются, а ICMP Fragmentation Needed не доходит до отправителя. Такое встречается с VPN, GRE и VXLAN.

Начнём с MTU интерфейса:

ip -d link show dev eth0

Например:

eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500

Но MTU 1500 на интерфейсе ещё не означает, что пакеты такого размера пройдут весь маршрут.

Проверим маршрут:

ip -4 route get 203.0.113.10

Теперь отправим IPv4-пакет размером 1500 байт с запретом фрагментации:

ping -4 -M do -s 1472 -c 3 203.0.113.10

Размер: 1472 байта данных + 8 байт ICMP + 20 байт IPv4. Если пакет не проходит, попробуем 1400 байт:

ping -4 -M do -s 1372 -c 3 203.0.113.10

Если меньшие пакеты проходят, а большие нет — есть повод проверить Path MTU.

Отсутствие ответа на ping ещё не доказывает проблему с MTU. Кроме того, -M do учитывает уже известный ядру PMTU. Для проверки в обход этого ограничения можно использовать:

sudo ping -4 -M probe -s 1472 -c 3 203.0.113.10

Для дополнительной диагностики запустим:

tracepath -n 203.0.113.10

Утилита может показать обнаруженное ограничение:

pmtu 1400

Результат зависит от прохождения ICMP. В Debian/Ubuntu tracepath доступен в пакете iputils-tracepath.

Теперь посмотрим, какой PMTU известен ядру:

ip -4 route get 203.0.113.10

Если информация сохранена, вывод может содержать:

cache expires 420sec mtu 1400

Для действующего TCP-соединения проверим MSS и PMTU:

ss -tin dst 203.0.113.10

Например:

mss:1360 pmtu:1400

При стандартных 20-байтных заголовках IPv4 и TCP получаем MSS 1360. Фактические значения могут отличаться.

В линукс есть и встроенный механизм TCP MTU probing, который помогает при проблемах с определением MTU. Проверим его состояние:

sysctl net.ipv4.tcp_mtu_probing

Возможные значения:

0 — отключён
1 — включается при обнаружении проблемы
2 — включён постоянно

Сохраним исходное значение и временно включим механизм:

original=$(sysctl -n net.ipv4.tcp_mtu_probing)
sudo sysctl -w net.ipv4.tcp_mtu_probing=1

Повторим проблемную передачу через новое TCP-соединение. Если заработало — это дополнительный аргумент в пользу проблемы с PMTUD. Но механизм может сработать не сразу, а отсутствие улучшения не исключает проблему.

Вернём исходное значение:

sudo sysctl -w net.ipv4.tcp_mtu_probing="$original"

Механизм работает только для TCP в соответствующем сетевом пространстве имён и не заменяет правильную настройку MTU туннелей. Все проверки рассчитаны на IPv4. В IPv6 для обнаружения ограничений используется ICMPv6 Packet Too Big.

Адрес 203.0.113.10 приведён для примера. Замените его на адрес доступного узла, где воспроизводится проблема, а eth0 — на свой интерфейс.

🔥 PMTU black hole — одна из причин, почему TCP-соединение есть, а нормальной передачи данных нет. Проверка DF-пакетов, tracepath, PMTU и MSS помогает найти ограничение на маршруте, особенно в сетях с VPN и туннелями.

🚪 Linux Ready | #практика

❤️ Необычная и крайне интересная статья на Хабре: «Пустили ботов по SSH на фейковый сервер с четырьмя H100: что они там делали»!

В этой статье:
• Узнаете, как с помощью Python и Cowrie создать SSH-ловушку, имитирующую мощный сервер с четырьмя NVIDIA H100;
• Посмотрите, что делали атакующие боты после входа: меняли пароли, добавляли SSH-ключи и пытались установить майнеры;
• Разберёте результаты первых 12,5 часов эксперимента — 1 846 подключений и более 1 500 команд — и способы защиты SSH от подобных атак.

🔊 Продолжай читать на Habr!

🚪 Linux Ready | #статья

В Git можно переносить незавершённые изменения между проектами или рабочими деревьями без коммитов и копирования файлов вручную!

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

git diff > changes.patch

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

Перед применением полезно проверить, получится ли внести изменения:

git apply --check changes.patch

Если проверка прошла успешно, применяем:

git apply changes.patch

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

git diff HEAD > changes.patch

Важно: новые неотслеживаемые файлы в такой патч автоматически не попадут.

🔥 git diff вместе с git apply — удобный способ переносить локальные правки между рабочими деревьями, тестовыми окружениями и копиями проекта без промежуточных коммитов.

🚪 Linux Ready | #совет

Почему линукс может показывать разные файлы по одному и тому же пути?

В линукс два процесса могут обращаться к /tmp, /etc или /var, но фактически видеть разные файловые системы. Причём для этого необязательно использовать docker или полноценный контейнер.

Такое поведение обеспечивает механизм mount namespaces, позволяющий изолировать таблицу монтирования отдельных процессов.

Проверим на практике. Сначала создадим тестовый каталог:

sudo mkdir -p /mnt/ns-test
echo "original" | sudo tee /mnt/ns-test/file

Теперь запустим отдельное пространство имён монтирования:

sudo unshare --mount --propagation private /bin/bash

Внутри новой оболочки смонтируем tmpfs поверх существующего каталога:

mount -t tmpfs tmpfs /mnt/ns-test
echo "isolated" > /mnt/ns-test/file
cat /mnt/ns-test/file

Результат:

isolated

Откроем второй терминал и выполним:

cat /mnt/ns-test/file

Здесь результат будет другим:

original

Оба процесса используют одинаковый абсолютный путь, но обращаются к разным объектам файловой системы.

Посмотреть пространства имён процессов можно через:

readlink /proc/self/ns/mnt

А для конкретного процесса:

readlink /proc/PID/ns/mnt

Если идентификаторы отличаются, процессы находятся в разных mount namespaces. Однако это ещё не означает, что их таблицы монтирования обязательно различаются.

Посмотреть реальные точки монтирования процесса:

cat /proc/PID/mountinfo

Можно также войти в существующее пространство имен другого процесса:

sudo nsenter --target PID --mount -- /bin/bash

После этого новая оболочка будет использовать его mount namespace. Именно этот механизм применяется в контейнерах и при изоляции сервисов systemd. Например, параметр PrivateTmp=yes позволяет сервису получить отдельные пространства для временных файлов в /tmp и /var/tmp.

Поэтому файл, созданный сервисом в /tmp, может быть недоступен по тому же пути из обычной пользовательской оболочки. После эксперимента выйдем из изолированной оболочки командой exit и удалим тестовый каталог:

sudo rm -rf /mnt/ns-test

🔥 Абсолютный путь в линукс не гарантирует обращение к одному и тому же файлу. При диагностике контейнеров и systemd-сервисов проверяйте не только путь, но и mount namespace процесса. Особенно если приложение видит файл, который отсутствует на хосте, или наоборот.

🚪 Linux Ready | #практика

Как диагностировать переполнение TCP listen backlog в линукс?

Под нагрузкой TCP-сервис может терять новые подключения или увеличивать время их установления, хотя CPU не перегружен, а существующие соединения работают стабильно. Одна из возможных причин — переполнение accept queue, в которой завершённые TCP-подключения ожидают обработки через accept().

Размер очереди определяется аргументом backlog при вызове listen() и ограничивается net.core.somaxconn. Проверим listening socket на порту 443:

ss -lnt '( sport = :443 )'

Для TCP-сокета в состоянии LISTEN поле Recv-Q показывает количество соединений, ожидающих accept(), а Send-Q — максимальную длину очереди. Следующий результат указывает на её заполнение в момент измерения:

State   Recv-Q Send-Q Local Address:Port
LISTEN  128    128    0.0.0.0:443

Заполненная очередь ещё не доказывает потери подключений. Проверим системный лимит и счётчики переполнений TCP-стека:

sysctl net.core.somaxconn

nstat -az | grep -E \
  'TcpExtListenOverflows|TcpExtListenDrops'

ListenOverflows учитывает события переполнения, а ListenDrops — более широкий набор отказов при обработке подключений. Счётчики относятся ко всему network namespace и не отражают точное количество уникальных потерянных соединений.

Для оценки динамики измерим прирост счётчиков за 30 секунд, используя два снимка статистики ядра.

nstat -az > /tmp/tcp-before.nstat
sleep 30
nstat -az > /tmp/tcp-after.nstat

awk '
NR == FNR { before[$1] = $2; next }
/^TcpExtListen(Overflows|Drops)[[:space:]]/ {
    printf "%s: +%.0f\n", $1, $2 - before[$1]
}
' /tmp/tcp-before.nstat /tmp/tcp-after.nstat

Если ListenOverflows растёт одновременно с заполнением Recv-Q, необходимо проверить интенсивность обработки соединений приложением. Через bpftrace подсчитаем успешные вызовы accept4() процесса с PID 2451:

sudo bpftrace -e '
tracepoint:syscalls:sys_exit_accept4
/pid == 2451 && args->ret >= 0/
{
    @accepted = count();
}

interval:s:1
{
    print(@accepted);
    clear(@accepted);
}'

Измерение приблизительное: оно не учитывает обычный accept() и другие процессы, а вывод и очистка счётчика не атомарны. Для многопроцессных серверов требуется учитывать всех обработчиков соединений.

От accept queue необходимо отличать SYN queue, которая используется при незавершённых TCP-handshake. Проверим параметры и статистику её переполнения:

sysctl net.ipv4.tcp_max_syn_backlog
sysctl net.ipv4.tcp_syncookies

nstat -az | grep -E \
  'TcpExtSyncookiesSent|TcpExtTCPReqQFull'

Рост SyncookiesSent может указывать на давление на SYN queue, но не обязательно свидетельствует о SYN flood. Фактическое поведение зависит от конфигурации сокета и реализации TCP в ядре.

При переполнении accept queue параметр tcp_abort_on_overflow влияет на возможность сброса подключений через RST:

sysctl net.ipv4.tcp_abort_on_overflow

При значении 0 ядро обычно допускает повторную обработку подключения, что может увеличивать задержки. Значение 1 позволяет отправлять RST, но не устраняет причину перегрузки.

Если используется SO_REUSEPORT, несколько listening sockets могут обслуживать один порт с независимыми accept queues. Проверять их необходимо отдельно:

sudo ss -lntpe '( sport = :443 )'

🔥 Переполнение TCP listen backlog диагностируется по совокупности показателей: заполненности Recv-Q, динамике ListenOverflows и ListenDrops, интенсивности accept() и состоянию SYN queue. При подтверждённой перегрузке следует исследовать обработчики соединений, блокировки event loop и распределение нагрузки до изменения системных лимитов.

🚪 Linux Ready | #практика