👍 Большая шпаргалка по Linux-командам для повседневной работы!

В репозитории собраны команды для получения информации о системе, поиска и просмотра файлов, монтирования дисков, работы с файловыми системами, резервного копирования и обработки текста через grep, sed и awk. Есть отдельные разделы по сети, iptables, процессам, мониторингу и диагностике с top, ps, lsof, strace, tcpdump, rsync и другими утилитами.

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

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

❤️ Годная статья попалась на Хабре: «Топ утилит и инструментов для проверки работоспособности VDS»!

В этой статье:
• Узнаете, как быстро определить, где проблема: на сервере, в сети или у провайдера;
• Разберёте диагностику VDS с помощью ping, traceroute, MTR, curl, htop, iostat и других Linux-утилит;
• Познакомитесь с инструментами для мониторинга сети, ресурсов, дисков, портов и логов сервера.

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

🚪 Linux Ready | #статья

📂 Краткая шпаргалка по основам системы!

Как устроена файловая система Linux, чем отличаются /etc, /usr, /var и /proc, как работают права rwx и что означает chmod 764

На схеме собраны системные директории, базовые команды для работы с файлами, процессами и дисковым пространством, права доступа, специальные биты SetUID / SetGID / Sticky Bit, а также полезные сочетания клавиш терминала.

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

🚪 Linux Ready | #ресурс

Почему rm удалил файл, но место на диске не освободилось!

На Linux-сервере можно удалить большой журнал через rm, но df -h по-прежнему будет показывать заполненную файловую систему.

rm /var/log/app/application.log
df -h /var

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

Найти открытые удалённые файлы можно через:

sudo lsof +L1

Например, в выводе может быть:

COMMAND  PID   USER  FD   TYPE DEVICE SIZE/OFF NLINK NAME
java    2451   app   12w  REG  8,1         15G     0 /var/log/app/application.log (deleted)

NLINK=0 означает, что ссылок из каталогов на inode больше нет, а 12w — файловый дескриптор, открытый на запись. Процесс при этом продолжает работать с прежним файлом даже после rm.

Проверить, куда указывает дескриптор, и посмотреть его параметры можно через /proc:

readlink /proc/2451/fd/12
cat /proc/2451/fdinfo/12

Именно поэтому du и df могут показывать разные значения. du считает файлы, доступные при обходе дерева каталогов, а df показывает занятые блоки файловой системы, включая блоки удалённых файлов, которые всё ещё удерживаются процессами.

Сравнить показания можно так:

du -xhd1 /var
df -h /var

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

systemctl restart имя-сервиса

Для постоянно работающих служб предпочтительнее использовать поддерживаемый приложением механизм повторного открытия журналов без полного перезапуска. Например, nginx умеет переоткрывать лог-файлы:

nginx -s reopen

Поэтому для ротации журналов обычно используют logrotate вместе с поддерживаемым приложением механизмом reopen. copytruncate тоже применяется, когда приложение не умеет переоткрывать лог, но у него есть недостаток: между копированием файла и его обнулением существует небольшое окно, в котором часть новых записей может быть потеряна.

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

sudo sh -c ': > /proc/2451/fd/12'

Но это именно аварийный приём. Если процесс пишет без O_APPEND, сохранённая позиция записи после truncate может остаться далеко за новым концом файла. Последующая запись тогда способна создать разреженную область — sparse hole.

Проверить флаги открытого дескриптора и текущую позицию можно через:

cat /proc/2451/fdinfo/12

Расхождение между du и df не всегда связано именно с открытыми удалёнными файлами. Но если перед этим был удалён большой активный журнал, одна из первых диагностических команд:

sudo lsof +L1

🔥 Если после rm место не освободилось, процесс, скорее всего, продолжает удерживать удалённый файл открытым. Блоки будут окончательно освобождены, когда исчезнут все открытые ссылки на него.

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

Почему rm удалил файл, но место на диске не освободилось!

На Linux-сервере можно удалить большой журнал через rm, но df -h по-прежнему будет показывать заполненную файловую систему.

rm /var/log/app/application.log
df -h /var

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

Найти открытые удалённые файлы можно через:

sudo lsof +L1

Например, в выводе может быть:

COMMAND  PID   USER  FD   TYPE DEVICE SIZE/OFF NLINK NAME
java    2451   app   12w  REG  8,1         15G     0 /var/log/app/application.log (deleted)

NLINK=0 означает, что ссылок из каталогов на inode больше нет, а 12w — файловый дескриптор, открытый на запись. Процесс при этом продолжает работать с прежним файлом даже после rm.

Проверить, куда указывает дескриптор, и посмотреть его параметры можно через /proc:

readlink /proc/2451/fd/12
cat /proc/2451/fdinfo/12

Именно поэтому du и df могут показывать разные значения. du считает файлы, доступные при обходе дерева каталогов, а df показывает занятые блоки файловой системы, включая блоки удалённых файлов, которые всё ещё удерживаются процессами.

Сравнить показания можно так:

du -xhd1 /var
df -h /var

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

systemctl restart имя-сервиса

Для постоянно работающих служб предпочтительнее использовать поддерживаемый приложением механизм повторного открытия журналов без полного перезапуска. Например, nginx умеет переоткрывать лог-файлы:

nginx -s reopen

Поэтому для ротации журналов обычно используют logrotate вместе с поддерживаемым приложением механизмом reopen. copytruncate тоже применяется, когда приложение не умеет переоткрывать лог, но у него есть недостаток: между копированием файла и его обнулением существует небольшое окно, в котором часть новых записей может быть потеряна.

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

sudo sh -c ': > /proc/2451/fd/12'

Но это именно аварийный приём. Если процесс пишет без O_APPEND, сохранённая позиция записи после truncate может остаться далеко за новым концом файла. Последующая запись тогда способна создать разреженную область — sparse hole.

Проверить флаги открытого дескриптора и текущую позицию можно через:

cat /proc/2451/fdinfo/12

Расхождение между du и df не всегда связано именно с открытыми удалёнными файлами. Но если перед этим был удалён большой активный журнал, одна из первых диагностических команд:

sudo lsof +L1

🔥 Если после rm место не освободилось, процесс, скорее всего, продолжает удерживать удалённый файл открытым. Блоки будут окончательно освобождены, когда исчезнут все открытые ссылки на него.

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

📂 Напоминалка по сетям контейнеров в Linux!

Например, сетевое пространство имён (network namespace) изолирует сетевой стек контейнера, а пара виртуальных сетевых интерфейсов veth соединяет его с основной сетью Linux через виртуальный мост (Linux Bridge).

На картинке наглядно показано, как устроены сетевые пространства имён, veth-пары, сетевые мосты, маршрутизация, NAT и проброс портов.

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

🚪 Linux Ready | #ресурс

📂 Напоминалка по SSH-туннелям и пробросу портов!

Например, ssh -L позволяет открыть локальный порт и через SSH получить доступ к сервису на удалённом сервере, а ssh -R работает в обратную сторону — открывает порт на удалённой стороне и направляет трафик к вашему локальному сервису.

На картинке наглядно разобраны 4 частых сценария: локальный проброс, доступ через bastion-сервер, удалённый проброс и reverse-туннель через gateway.

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

🚪 Linux Ready | #ресурс

Linux умеет автоматически запускать команду после изменения файла без бесконечных циклов и ручных проверок!

Частая задача при разработке: изменить код, дождаться сборки, проверить тесты, обновить конфигурацию.

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

Утилита entr делает это проще:

$ ls *.go | entr go test ./...

Теперь после каждого изменения Go-файла тесты автоматически запускаются заново.

Можно следить за целым проектом:

$ find . -name "*.js" | entr npm run build

После сохранения JavaScript-файла сборка будет выполнена автоматически.

Можно использовать это и для серверных задач:

$ echo nginx.conf | entr sudo systemctl reload nginx

Изменили конфигурацию — сервис сразу получил обновление без ручного запуска команды.

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

🚪 Linux Ready | #совет

👨‍💻 Полезная статья недавно вышла на Хабре: «Топ-10 утилит для работы с диском на VDS»!

В этой статье:
• Узнаете, как быстро найти файлы и директории, которые занимают больше всего места;
• Разберёте инструменты для проверки скорости диска и поиска процессов, создающих высокую нагрузку;
• Познакомитесь с утилитами для очистки дублей, передачи файлов и синхронизации данных с облаками.

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

🚪 Linux Ready | #статья

📂 Напоминалка по Berkeley Sockets API!

Например, SOCK_STREAM используется для потоковых соединений вроде TCP, а SOCK_DGRAM — для передачи отдельных датаграмм, например через UDP.

На картинке — наглядная схема работы сетевых и Unix domain sockets: AF_INET, AF_INET6, AF_UNIX, различия между stream и datagram-сокетами, а также базовый обмен данными между клиентом и сервером.

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

🚪 Linux Ready | #ресурс

🤔 Большой справочник по Linux и командной строке!

Здесь собраны заметки и команды по работе с Linux: Shell и SSH, файловая система и LVM, права доступа, grep, sed и Vim, сеть, systemd, переменные окружения, безопасность, DEB/RPM-пакеты, ядро и Bash-скрипты. Есть отдельные материалы по Docker, сборке программ через CMake и Autotools, отладке с GDB и другим системным инструментам.

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

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

Почему TCP подключается, но передача данных зависает?

TCP-соединение может успешно устанавливаться, хотя передача данных по нему работает нестабильно. Характерные симптомы — зависание SSH, HTTP-запросов и загрузок после начала передачи более крупных TCP-сегментов.

Одна из возможных причин — проблема с определением MTU на всём пути передачи. Сначала проверим MTU физических и виртуальных интерфейсов:

ip -br link

ip link show eth0
ip link show wg0
ip link show tun0
ip link show docker0

MTU интерфейса и MTU всего маршрута — разные параметры. Интерфейс может иметь MTU 1500, тогда как VPN, VXLAN, GRE, IPsec, PPPoE или другой участок маршрута ограничивает максимальный размер проходящего IP-пакета.

Для IPv4 проверим прохождение пакета размером 1500 байт с запретом фрагментации:

ping -4 -M do -s 1472 server_ip

1472 — данные ICMP. Плюс 20 байт заголовка IPv4 и 8 байт ICMP — получаем IP-пакет размером 1500 байт.

Если ядру уже известен меньший MTU маршрута, можно получить локальную ошибку:

ping: local error: message too long, mtu=1400

MTU маршрута также может быть уменьшен после получения ICMP Fragmentation Needed от маршрутизатора.

Если такие ICMP-сообщения фильтруются, отправитель может не узнать, что размер пакета необходимо уменьшить. Крупные пакеты будут отбрасываться, а небольшие продолжат проходить.

При необходимости можно выполнить проверку без учёта сохранённого ядром MTU маршрута:

ping -4 -M probe -s 1472 server_ip

Найти приблизительную границу можно последовательной проверкой:

for size in 1472 1452 1440 1420 1400 1380 1372; do
    ping -4 -M do -c 3 -s "$size" server_ip
done

Например, если максимальный рабочий размер данных ICMP равен 1372 байтам:

1372 + 20 IPv4 + 8 ICMP = 1400

Предполагаемый MTU маршрута — 1400 байт. При этом он может различаться в прямом и обратном направлениях, поэтому при возможности проверяйте соединение с обеих сторон.

Дополнительно проверим маршрут:

tracepath server_ip

Для TCP важен MSS — максимальный размер данных TCP, который сторона сообщает другой стороне. MSS объявляется независимо в SYN и SYN-ACK, поэтому значения могут отличаться. Посмотреть MSS при установлении соединения:

tcpdump -i any -nn -vv 'tcp[tcpflags] & tcp-syn != 0'

При IPv4 MTU 1500 типичный MSS:

1500 - 20 IPv4 - 20 TCP = 1460

Если реальный MTU маршрута меньше, а его определение работает некорректно — например, ICMP Fragmentation Needed блокируется — крупные пакеты могут теряться, вызывая повторные передачи и зависание соединения.

Состояние TCP-соединения проверим через:

ss -ti dst server_ip

Смотрим RTT, mss, advmss, окно перегрузки и повторные передачи. Одновременно можно анализировать TCP и ICMP:

tcpdump -i any -nn -vv 'tcp or icmp'

Ищем повторные передачи TCP-сегментов и ICMP Fragmentation Needed. Успешный обычный ping здесь ничего не доказывает: небольшие ICMP-пакеты могут проходить даже при меньшем MTU маршрута. По той же причине TCP-соединение может успешно устанавливаться — SYN, SYN-ACK и ACK имеют небольшой размер.

При подтверждённой проблеме не стоит произвольно уменьшать MTU на конечном сервере. Проверьте MTU туннелей, фильтрацию ICMP и конфигурацию наложенной сети. Ограничение TCP MSS также может применяться на маршрутизаторах и VPN-шлюзах, но только как осознанное решение конкретной проблемы.

🔥 Главный вывод будет такой: успешное установление TCP-соединения не гарантирует нормальную передачу данных. Если небольшие пакеты проходят, а крупные теряются — проверяйте MTU маршрута, MSS, ICMP и повторные передачи TCP.

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

❤️ Linux SysOps Handbook — руководство по системному администрированию Linux!

Здесь собраны команды, инструкции и примеры по управлению процессами и пользователями, правам доступа, Bash и SSH, systemd и cron, логам и мониторингу, сетям, дискам и диагностике системы. Отдельно разобрана работа с ps, systemctl, journalctl, nmcli, apt, yum, LVM и другими системными инструментами. Полезный справочник для изучения Linux и работы с серверами.

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

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

📂 Напоминалка для работы с Vim!

Например, i включает режим вставки текста, dd удаляет текущую строку, а :wq сохраняет изменения и закрывает редактор.

На картинке — основные режимы и самые нужные команды Vim для навигации, редактирования, поиска, сохранения и выхода.

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

🚪 Linux Ready | #ресурс

Отслеживаем изменения файлов через inotifywait!

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

В Debian и Ubuntu утилита устанавливается из стандартных репозиториев:

sudo apt update && sudo apt install -y inotify-tools

Запустим непрерывное наблюдение за каталогом. Параметр -m (--monitor) оставляет процесс активным после получения события:

inotifywait -m /var/www/app

События выводятся по мере их получения от ядра:

/var/www/app/ MODIFY config.json
/var/www/app/ CREATE cache.tmp
/var/www/app/ DELETE cache.tmp

Для наблюдения за всем деревом каталогов добавим -r (--recursive):

inotifywait -m -r /var/www/app

Параметр -e позволяет оставить только нужные события. move включает события перемещения из наблюдаемого каталога и в него:

inotifywait -m -r \
  -e create,modify,delete,move \
  /var/www/app

Для диагностики удобнее выводить время, тип события и путь объекта:

inotifywait -m -r \
  --timefmt '%H:%M:%S' \
  --format '%T %e %w%f' \
  /var/www/app

При использовании абсолютного пути %w%f формирует полный путь к объекту:

14:32:07 MODIFY /var/www/app/config.json
14:32:11 MOVED_TO /var/www/app/releases/current

Следует учитывать, что одно действие приложения может породить несколько событий inotify, а рекурсивное наблюдение создаёт отдельные watches для дерева каталогов. Текущий системный лимит можно проверить через sysctl:

sysctl fs.inotify.max_user_watches

🔥 inotify фиксирует события файловой системы, но не сообщает PID процесса, который инициировал изменение. Если требуется определить конкретный процесс или пользователя, следует использовать механизмы аудита, например auditd.

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