Телеграм канал «LinuxSkill - Сводки с прода и Шпаргалки»

💀 Ошибка No space left, хотя свободны гигабайты? Диагноз inode

apt падает с «No space left on device», сервис перестал писать логи, а df -h показывает гигабайты свободного места. Место ни при чём — кончились inode: у каждого файла, даже пустого, свой номер, и на ext4 их число конечно.

Шаг 1. Проверяем inode, а не место
df -i /
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/loop0 5024 5024 0 100% /mnt/ino
На тестовой ФС df -h в этот момент показывал 1% занятого места.
ВАЖНО: резерва под root, как у места на диске, тут нет. У меня root не смог создать даже конфиг — встают все сервисы разом.

Шаг 2. Ищем каталог-пожиратель
# Где больше всего inode, с учётом вложенных
sudo du --inodes -x / 2>/dev/null | sort -n | tail
# Файлов прямо в каталоге
sudo find / -xdev -printf '%h\n' | sort | uniq -c \
| sort -rn | head
Частые виновники: PHP-сессии в /var/lib/php/sessions, очередь почты, кэш приложения, старые linux-headers в /usr/src — их убирает apt autoremove --purge.

Шаг 3. Удаляем правильно
# Сначала посмотри, что попадёт под удаление
sudo find /var/lib/php/sessions -type f -mmin +1440 | head
sudo find /var/lib/php/sessions -type f -mmin +1440 -delete
Подвох: rm /path/* на сотнях тысяч файлов падает с «Argument list too long» — глоб не влезает в командную строку. Проверил на 300 000 файлов: rm отказался, find -delete справился за 1.7 с.

Шаг 4. Понять, сколько inode у ФС
sudo tune2fs -l /dev/\<disk> | grep -i 'inode count'
На ext4 число inode задаётся при mkfs — по умолчанию одна на 16 КБ. Добавить их можно только вместе с размером: resize2fs при расширении ФС вдвое удвоил и inode. Под миллионы мелких файлов форматируй с mkfs.ext4 -i 4096 или бери XFS — там inode выделяются динамически.

Чтобы не повторилось, найди источник — крон для сессий, logrotate — и добавь IUse% в мониторинг рядом с Use%.

❗️ Нравится формат? Ставь 👍
👉 Рубрика: #шпаргалка@LinuxSkill
#Linux #Troubleshooting #Storage #ext4 #SysAdmin #DevOps

🧠 15 параметров sysctl и /proc, которые спасут сервер под нагрузкой
Всплеск трафика — и сервер «падает», хотя CPU и память в порядке: упёрся в лимиты ядра по умолчанию. Держи 15 ручек с симптомом, по которому видно, какую крутить. Проверил на ядре 6.18.
Сеть
Очередь accept:
sysctl net.core.somaxconn
nstat -az TcpExtListenOverflows
Растёт ListenOverflows — очередь полна. Подвох: somaxconn режет backlog приложения — listen(1024) при somaxconn=16 дал 16. Поднимай оба.
Очередь SYN:
sysctl net.ipv4.tcp_max_syn_backlog net.ipv4.tcp_syncookies
tcp_syncookies=1 — переполнение SYN-очереди не остановит приём.
Порты для исходящих:
sysctl net.ipv4.ip_local_port_range
Тысячи исходящих — и «Cannot assign requested address»: у меня так упало шестое соединение при диапазоне из 5 портов.
Переиспользование TIME_WAIT:
sysctl net.ipv4.tcp_tw_reuse
2 — только loopback, 1 — все исходящие. tcp_tw_recycle из старых гайдов ломал клиентов за NAT и удалён в ядре 4.12.
Очередь входящих пакетов:
sysctl net.core.netdev_max_backlog
awk '{print $2}' /proc/net/softnet_stat
Второй столбец — дропы по каждому CPU. Не нули — поднимай.
Таблица conntrack:
sysctl net.netfilter.nf_conntrack_count \
net.netfilter.nf_conntrack_max
count упёрся в max — новые соединения молча дропаются.
TCP-буферы:
sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem
Третье число — потолок автотюнинга, его поднимают для 10G.
Память и диск
Грязные страницы:
sysctl vm.dirty_background_ratio vm.dirty_ratio
При 256 ГБ RAM 20% — это 51 ГБ несброшенной записи, и на пороге пишущие процессы встают. Задавай в байтах через vm.dirty_bytes — подвох: он обнуляет vm.dirty_ratio.
Своппинг:
sysctl vm.swappiness
Для БД ставят 1–10. 0 своп не выключает, а откладывает до последнего.
Резерв свободной памяти:
sysctl vm.min_free_kbytes
ВАЖНО: ниже 1 МБ ядро, по документации, склонно к дедлокам под нагрузкой — атомарным аллокациям не из чего брать. Слишком высоко — мгновенный OOM.
Overcommit:
sysctl vm.overcommit_memory
Redis при 0 пишет «WARNING Memory overcommit must be enabled!» и просит 1.
Карты памяти:
sysctl vm.max_map_count
65530 по умолчанию, Elasticsearch без 262144 не стартует.
Файлы и процессы
Открытые файлы:
cat /proc/sys/fs/file-nr
grep 'open files' /proc/\<PID>/limits
«Too many open files» — почти всегда лимит процесса, а не fs.file-max. Лечится LimitNOFILE= в юните.
Inotify:
sysctl fs.inotify.max_user_watches
Подвох: кончились вотчи — и ошибка «No space left on device» при свободном диске.
Процессы и потоки:
sysctl kernel.pid_max kernel.threads-max
«fork: Resource temporarily unavailable» — упёрся сюда, в ulimit -u или в TasksMax= юнита.
Меняй по одной ручке и сравнивай счётчик до и после. Сохраняй в /etc/sysctl.d/, применяй sysctl --system.
❗️ Нравится формат? Ставь 👍
👉 Рубрика: #шпаргалка@LinuxSkill
#Linux #sysctl #Performance #Kernel #SysAdmin #DevOps

🔥 10 незаменимых флагов journalctl для моментального поиска логов

Журнал разросся до гигабайтов, а journalctl | grep думает по несколько секунд на каждый запрос. Половина флагов journalctl ищет по индексу и отвечает мгновенно. Держи 10 — проверил на systemd 255.

1️⃣ Логи сервиса — сразу с конца или в реальном времени:
journalctl -u nginx -e
journalctl -u nginx -f

2️⃣ Только ошибки текущей загрузки:
journalctl -p err -b
-p err — это уже err и всё серьёзнее. Диапазон: -p warning..err.

3️⃣ Окно по времени:
journalctl --since "1 hour ago"
journalctl --since "09:00" --until "09:30"

4️⃣ Прошлая загрузка — почему сервер ребутнулся:
journalctl --list-boots
journalctl -b -1 -p err
ВАЖНО: «no persistent journal was found» — журнал живёт в /run и умирает с перезагрузкой. Лечится так: sudo mkdir -p /var/log/journal и рестарт systemd-journald.

5️⃣ Ядро прошлой загрузки:
journalctl -k -b -1
OOM или паника перед ребутом видны здесь, а в dmesg их уже нет.

6️⃣ Какие значения вообще есть в журнале:
journalctl -F _SYSTEMD_UNIT
journalctl -F SYSLOG_IDENTIFIER

7️⃣ Фильтр по полям вместо grep:
journalctl _COMM=sshd _UID=0
journalctl _PID=1234 + _COMM=cron
Поля через пробел — И, через + — ИЛИ. Поле читается по индексу: на 300 000 записей journalctl | grep думал 3.4 с, фильтр по полю — 0.025 с.

8️⃣ Встроенный grep:
journalctl -u nginx -g 'timeout|refused'
Подвох: шаблон в нижнем регистре ищет без учёта регистра, с заглавной буквой — строго. У меня -g 'Payment' не нашёл ни одной строки с payment. И -g индекса не видит: 1.4 с против 0.03 с у поля — сначала сузь выборку.

9️⃣ Вывод для скриптов и разбора:
journalctl -u nginx -n 1 -o json-pretty
journalctl -u nginx -o cat
json-pretty покажет все поля записи — так и узнаёшь, по чему фильтровать. cat — только текст.

🔟 Журнал съел диск или лежит на чужом:
journalctl --disk-usage
sudo journalctl --vacuum-size=1G
# журнал с другого диска, например в rescue
journalctl -D /mnt/var/log/journal
--vacuum удаляет только архивные файлы, активный не трогает.

❗️ Нравится формат? Ставь 👍
👉 Рубрика: #шпаргалка@LinuxSkill
#Linux #journalctl #systemd #Logs #SysAdmin #DevOps

💀 OOM Killer убивает базу данных? 6 шагов отладки утечек RAM

OOM Killer снова прибил PostgreSQL, а free -m показывает гигабайты свободной памяти. Так бывает, когда память кончилась не у сервера, а у cgroup сервиса, или когда «кэш» на самом деле нельзя освободить. Показываю, как найти настоящую причину.

Шаг 1. Кого убили и почему
sudo dmesg -T | grep -iE 'oom-kill|killed process'
oom-kill:constraint=CONSTRAINT_MEMCG,…,oom_memcg=/dbtest
Memory cgroup out of memory: Killed process 280 (python3)
ВАЖНО: Memory cgroup out of memory и CONSTRAINT_MEMCG — память кончилась у cgroup, а не у сервера. Глобальная нехватка выглядит как Out of memory и CONSTRAINT_NONE. Проверил: процесс убит на лимите 100 МБ, хотя на хосте было 3.8 ГБ available.

Шаг 2. Что на самом деле занято
free -m
grep -E 'MemAvailable|Shmem:|SUnreclaim' /proc/meminfo
Смотри available, а не free плюс buff/cache. Подвох: tmpfs и shared memory сидят в buff/cache, но не освобождаются. У меня 800 МБ в /dev/shm остались в buff/cache и после drop_caches. Растёт SUnreclaim — течёт само ядро, смотри
slabtop.

Шаг 3. Давление памяти
cat /proc/pressure/memory
Растущий some — ядро уже вытесняет страницы и тормозит процессы. Ранний сигнал до OOM.

Шаг 4. Кто ест память
# сервисы systemd, сортировка по памяти
systemd-cgtop -m
# процессы по RSS
ps -eo pid,rss,comm --sort=-rss | head

Шаг 5. Лимит и счётчик убийств cgroup
cd /sys/fs/cgroup/system.slice/\<unit>.service
cat memory.max memory.current
grep oom_kill memory.events
oom_kill — сколько раз ядро уже убивало процессы этой cgroup.

Шаг 6. Где растёт память процесса
# крупные области; повтори через минуту и сравни
sudo pmap -x \<PID> | sort -k3 -n | tail -5
Растёт [ anon ] — утечка в куче приложения.

Убитый — не всегда виновник: OOM Killer бьёт по самому большому oom_score, а у базы с её буферами он часто максимальный. Пока ищешь утечку, прикрой БД: OOMScoreAdjust=-900 в override юнита через sudo systemctl edit \<unit>.

❗️ Нравится формат? Ставь 👍
👉 Рубрика: #шпаргалка@LinuxSkill
#Linux #Memory #OOM #Troubleshooting #SysAdmin #DevOps

🚨 Сервер под подозрением? 8 шагов аудита прав и SUID-бэкдоров

Кажется, что кто-то получил лишние привилегии, а с чего начать проверку — непонятно. Держи чек-лист на первые минуты: ищем скрытые пути к root — SUID, capabilities, PAM и sudo. Команды с SELinux проверены по документации, остальное прогнано на Ubuntu 24.04.

🔴 Шаг 1. SELinux: снять маску dontaudit
# Правила dontaudit глушат часть отказов —
# атака может не попасть в лог AVC.
# Временно снимаем глушилку:
sudo semodule -DB
sudo ausearch -m avc -ts today
# Вернуть как было:
sudo semodule -B
ВАЖНО: без semodule -DB часть заблокированных попыток доступа в журнал AVC просто не пишется. -DB держи включённым только на время аудита.

🔑 Шаг 2. SUID и SGID
# Бинарники с SUID/SGID, по дате изменения
sudo find / -xdev -type f -perm -4000 \
-printf '%TY-%Tm-%Td %p\n' 2>/dev/null | sort
Сравни список с чистой системой. Свежая дата у файла в /tmp, /dev/shm или /var/tmp — почти наверняка бэкдор.

🎭 Шаг 3. Capabilities: SUID, который find не видит
# Права root без бита SUID
getcap -r / 2>/dev/null
ВАЖНО: cap_setuid даёт тот же root, что и SUID, но в поиске -perm -4000 НЕ появится. Проверил: файл с cap_setuid+ep дал обычному юзеру uid 0, а find -perm -4000 его не нашёл. Опасные: cap_setuid, cap_setgid, cap_dac_override, cap_sys_admin, cap_sys_ptrace.

🚪 Шаг 4. PAM: вход мимо пароля
# Модули, дающие проход: pam_permit,
# pam_rootok не на месте, чужой pam_exec
grep -rnE "pam_permit|pam_exec|pam_rootok" \
/etc/pam.d/
sufficient pam_permit.so в common-auth — открытая дверь. pam_permit там штатно идёт только как required в хвосте стека.

👤 Шаги 5–6. Скрытый root и sudo-лазейки
# Второй UID 0 — сразу к делу
awk -F: '$3==0 {print $1}' /etc/passwd
# NOPASSWD, добавленный в обход
sudo grep -rEn "NOPASSWD" /etc/sudoers /etc/sudoers.d/

🔐 Шаги 7–8. Чужие ключи и входы
# Ключи SSH у всех, кто есть
sudo cat /root/.ssh/authorized_keys \
/home/*/.ssh/authorized_keys 2>/dev/null
# Неудачные входы — брутфорс перед взломом
sudo lastb -Fai | head
Порядок: dontaudit и AVC → SUID и capabilities → PAM → root и sudo → ключи. Нашёл подозрительное — не «чисти», а снимай образ: подчищенный сервер невозможно расследовать. И держи эталонный список SUID и getcap заранее — сравнивать будет с чем.

❗️ Нравится формат? Ставь 👍
👉 Рубрика: #SkillHunter@LinuxSkill
#Linux #Security #SELinux #Forensics #Hardening #SysAdmin

🔥 12 скрытых фишек find, о которых молчат базовые туториалы
find . -name знают все. А потом скрипт с xargs спотыкается о файл с пробелом, -delete сносит лишнее, а -mtime +1 находит не то. Держи 12 приёмов с подводными камнями — проверил на GNU find 4.9.
Регистр не важен — и всегда кавычки:
find . -iname '*.jpg'
Без кавычек шелл сам раскроет *.jpg, и find упадёт с «paths must precede expression».
Большие файлы, не выходя за пределы ФС:
sudo find / -xdev -type f -size +100M
Ловушка: -size -1M найдёт только пустые файлы — размер округляется вверх до мегабайта. «Меньше мегабайта» — это -size -1024k.
Изменённые за последние сутки:
find /etc -mtime -1
Ловушка: -mtime +1 — это старше 48 часов, а не 24: дробные сутки отбрасываются. Старше суток — -mmin +1440.
Всё, что поменялось после деплоя:
find /var/www -newermt '2026-09-25 18:00'
SUID-файлы — первое, что смотрят при аудите:
sudo find / -xdev -type f -perm -4000
SUID или SGID — -perm /6000. Старый -perm +6000 GNU find больше не принимает.
Пустые папки — найти и удалить, включая вложенные:
find . -type d -empty -delete
7. Исключить каталог целиком:
find . -path ./node_modules -prune \
-o -name '*.js' -print
Без -print в конце в вывод попадёт и сам ./node_modules.
Имена с пробелами и переносами строк:
find . -name '*.log' -print0 | xargs -0 gzip
Без -print0 и -0 файл «c d.jpg» превратится в два несуществующих: ./c и d.jpg.
Один процесс вместо тысяч:
find . -type f -exec grep -l 'TODO' {} +
ВАЖНО: {} \; запускает grep на каждый файл. На 5000 файлах у меня 4.3 с против 0.015 с с {} +. Лимит длины командной строки (ARG_MAX) + соблюдает сам.
Удаление — только последним:
find /tmp/app -name '*.tmp' -delete
ВАЖНО: find /tmp/app -delete -name '*.tmp' удалит ВСЁ — выражение читается слева направо. Проверил: от каталога не осталось ничего. Сначала запусти без -delete.
Топ самых тяжёлых файлов с размерами:
sudo find /var -xdev -type f -printf '%s %p\n' \
| sort -rn | head
12. Битые симлинки:
find . -xtype l
А на каком из этих подводных камней ты уже обжигался?
❗️ Нравится формат? Ставь 👍
👉 Рубрика: #шпаргалка@LinuxSkill
#Linux #find #Bash #CheatSheet #SysAdmin #DevOps

💀 df показывает 100%, а du молчит? 5 шагов спасения прода

Сервисы падают с «No space left on device», df -h рисует 100%, а du -sh /* насчитывает куда меньше. Классика: кто-то удалил гигантский лог, а процесс держит его открытым — файла уже нет, а блоки заняты. Показываю, как вернуть место без рестарта сервиса.

Шаг 1. Что именно кончилось
df -h /var
# Место есть, а пишет «No space left»? Кончились inode:
df -i /var
При 100% в df сервисы от root ещё пишут в резерв ext4, а остальные уже падают.

Шаг 2. Ищем удалённые, но открытые файлы
# +L1 — файлы без единой ссылки в ФС.
# Точка монтирования в конце = только эта ФС.
sudo lsof -nP +L1 \<mountpoint>
COMMAND PID FD SIZE/OFF NAME
python3 690 3w 73400887 /mnt/t/app.log (deleted)

Шаг 3. PID и номер дескриптора
3w в колонке FD — дескриптор 3, открыт на запись. Проверка:
sudo ls -l /proc/\<PID>/fd/\<FD>
# ... -> /mnt/t/app.log (deleted)
Шаг 4. Обнуляем файл без рестарта
# ВАЖНО: sudo : > файл НЕ сработает —
# перенаправление делает твой шелл, а не sudo.
sudo truncate -s 0 /proc/\<PID>/fd/\<FD>
Проверил на тестовой ФС: 141 МБ вернулись мгновенно, процесс продолжил писать. Только для логов и мусора — усечёшь файл данных БД, потеряешь данные.

Подвох: если сервис пишет без O_APPEND (например, запущен как app > file.log), он продолжит с прежнего смещения. Размер снова покажет 70 МБ, хотя на диске файл занимает 4 КБ: он станет разреженным, и мониторинг по размеру будет врать.

Шаг 5. Аварийный запас на ext4
# Резерв под root, по умолчанию 5%
sudo tune2fs -l /dev/\<disk> | grep -i "reserved block"
# Временно отдать 4% — работает на лету
sudo tune2fs -m 1 /dev/\<disk>
После уборки верни -m 5: резерв нужен, чтобы root мог чинить систему на полном диске. Только ext2/3/4, на XFS не сработает.

lsof +L1 пуст, а расхождение осталось? Файлы могут прятаться под точкой монтирования: смонтируй корень через mount --bind в пустую папку и запусти du там.

Чтобы не повторилось — logrotate с postrotate, который просит сервис переоткрыть лог, вместо ручного rm.

❗️ Нравится формат? Ставь 👍
👉 Рубрика: #шпаргалка@LinuxSkill
#Linux #Troubleshooting #Storage #SysAdmin #DevOps