Admin Guides | Сисадмин

OOM Killer: как Linux убивает процессы и что с этим делать Сервер работает, потом процесс внезапно исчезает без каких-либо ошибок в его логах. Приложение не крашилось, сигнала не было, просто пропал. Почти всегда это OOM Killer. Когда физическая память и swap заканчиваются, ядро не падает, а выбирает процесс и убивает его. Выбор основан на oom_score: чем выше балл, тем выше шанс попасть под удар. Учитывается размер процесса, время жизни, приоритет. Диагностика Смотрим был ли OOM Killer активен:

    
        dmesg | grep -i "oom\|killed process"
journalctl -k | grep -i oom{}
    

Текущий oom_score всех процессов, сортируем по убыванию:

    
        for pid in /proc/[0-9]*; do printf "%d %d %s\n" $pid $(cat $pid/oom_score 2>/dev/null) $(cat $pid/comm 2>/dev/null); done | sort -k2 -rn | head -20{}
    

Управление приоритетами Снижаем вероятность убийства критического процесса (например базы данных):

    
        echo -500 > /proc/$(pgrep postgres)/oom_score_adj{}
    

Полностью защищаем процесс от OOM Killer:

    
        echo -1000 > /proc/$(pgrep postgres)/oom_score_adj{}
    

Через systemd для постоянного эффекта:

    
        [Service]
OOMScoreAdjust=-500{}
    

Совет на 2027 год — переходите в ML. Пока обычные разрабы конкурируют с ИИ-копилотами, ML-инженеры эти самые нейронки создают. В эпоху нейростей это самые востребованые люди в мире программирования. Зарплаты мидлов начинаются от 250 000 ₽, а у сеньоров в BigTech доходят до 700 000 ₽. А чтобы освоить его всего за 4 месяца без лишней суеты — изучите канал Марка Миргалеева. Он помог 20+ ученикам найти работу от 250к в ML/NLP/AI-агентах На канале вы найдёте: — Всё про самые востребованные стеки(Python, ИИ-агенты, NLP) и почему математика — это не страшно, если учить только нужное. — Как оформить резюме, чтобы оно пролетало через любые LLM-фильтры и ATS-системы прямо к тимлидам. — Скрипты переговоров, которые помогли его ученикам прыгнуть с 0 до 360к всего за 8 месяцев. Во времена острой нехватки ML-разработчиков, это лучшее время, чтобы перекатиться. Переходи и изучай: https://t.me/+TwxQ8W6MF6hhY2My

💬 Вопрос на собеседовании для DevOps-инженера

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Что такое ARP cache poisoning (ARP spoofing) и как Linux-система защищается или обнаруживает такие атаки? ✅Ответ: ARP spoofing - это атака на локальную сеть, при которой злоумышленник отправляет поддельные ARP-ответы, связывая свой MAC-адрес с IP-адресом другого устройства (например, шлюза). В результате трафик начинает проходить через атакующего (MITM - man-in-the-middle). Как это работает: • В локальной сети устройства используют ARP для сопоставления IP ↔ MAC. • ARP не имеет встроенной аутентификации, поэтому таблица ARP может быть «отравлена». • Атакующий рассылает ложные ARP replies, подменяя записи у жертв. Как это проявляется в системе: • нестабильный интернет, редиректы, задержки • неожиданные смены MAC у gateway в arp -n • дублирующиеся IP в сети

Что же делать с этим Linux...❓ Если вы хотите сменить профессию, войти в IT, перейти в системное администрирование/DevOps или проверить, подходит ли вам направление Linux, — ждем на интенсиве по погружению в ОС Linux. ✨ Эксперт Кирилл Казарин — DevOps and SRE global manager в RingCentral Inc. Опыт в администрировании более 16 лет. ✨ Внутри обучения Вы пройдете путь от основ терминала до администрирования сети и безопасности. Выполните итоговый проект. ✨ Формат Удобный канал в Telegram, где можно общаться и получать обратную связь. После завершения все полезные материалы остаются у вас. ✨ Цена 3000 рублей за такой объем структурированной информации и проектной работы — вполне адекватное вложение в себя. Оно себя быстро окупит. Минимум риска, максимум пользы. 15 мая начинаем настраивать софт, первый день обучения — 18 мая. Вы успеваете! Даты, программа и другие подробности — на сайте. Оставляйте заявку, ждем вас!

inode exhaustion: диск не полный, а файлы не создаются Классическая ловушка: df -h показывает свободное место, но создать новый файл невозможно. Ошибка “No space left on device” при этом вводит в ступор. Проблема в inodes. Каждый файл занимает один inode, и их количество фиксируется при создании файловой системы. Можно иметь терабайт свободного места и ноль свободных inodes. Чаще всего виновник: миллионы мелких файлов. Логи, кеш пакетного менеджера, временные файлы приложений, незачищенные сессии PHP. Диагностика Смотрим использование inodes:

    
        df -i{}
    

Находим директорию с максимальным количеством файлов:

    
        find / -xdev -printf '%h\n' | sort | uniq -c | sort -rn | head -20{}
    

Считаем файлы в подозрительной директории:

    
        ls /var/cache/apt/archives | wc -l
find /tmp -type f | wc -l{}
    

Чистим Кеш apt:

    
        apt clean{}
    

Старые временные файлы:

    
        find /tmp -type f -atime +7 -delete
find /var/log -name "*.gz" -delete{}
    

После очистки проверяем:

    
        df -i{}
    

Совет на ближайшие годы — изучайте ВАЙБ-КОДИНГ ИИ уже пишет код, чинит баги, генерирует тесты, документацию и помогает запускать продукты быстрее, чем это делали классические команды разработки. И это уже не "будущее когда-нибудь", а реальность, которая меняет рынок уже сегодня И те, кто научится вайбкодить сейчас, будут увереннее конкурировать на рынке и зарабатывать больше тех, кто по-прежнему делает всё вручную. Стартовать с нуля поможет канал Вайб-кодинг. Там ребята круглосуточно мониторят более 320 российских и зарубежных источников и публикуют только главное: релизы, инструменты, гайды, курсы и практические кейсы. Подписывайтесь, нас уже 35 тысяч: @vibecoding_tg

💬 Вопрос на собеседовании для сисадмина

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Что такое kernel page-table isolation (KPTI) и зачем он нужен? ✅Ответ: KPTI — это механизм ядра Linux, введённый для защиты от атак типа Meltdown. Он изолирует таблицы страниц ядра от пользовательского пространства, предотвращая возможность чтения содержимого памяти ядра через уязвимости в процессоре. Как это работает: при переключении в пользовательский режим процессор использует отдельные таблицы страниц без прямого доступа к ядру. Это повышает безопасность, но может слегка снижать производительность при интенсивном переключении контекста между ядром и пользователем, так как требует обновления TLB при каждом переходе.

lsof: когда “порт занят”, но непонятно кем Очень частая история: сервис не стартует после рестарта, потому что порт уже используется. Но systemctl status ничего полезного не говорит, а старый процесс вроде бы уже убит. В этот момент почти всегда помогает не netstat, а lsof. Посмотреть, кто реально держит порт:

    
        lsof -i :8080{}
    

Сразу видно PID, процесс и пользователя. Если нужно быстро проверить все сетевые соединения процесса:

    
        lsof -p <pid> -i{}
    

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

    
        lsof -p <pid>{}
    

Иногда сервис “течёт” не по памяти, а по файловым дескрипторам: сокеты, временные файлы, deleted files. Классический продовый кейс: лог удалили, а место на диске не освободилось. Проверяется так:

    
        lsof | grep deleted{}
    

Процесс всё ещё держит файл открытым, хотя в filesystem его уже нет. Ещё один полезный сценарий - понять, кто держит mount или директорию:

    
        lsof +D /mnt/data{}
    

Особенно помогает, когда umount говорит “target is busy”. ⏺Что обычно ломается: Сервис формально “остановлен”, но старый worker ещё держит сокет. • Или место на диске закончилось, хотя логи “удалили”. • Или контейнер не удаляется, потому что процесс держит volume. Во всех этих случаях проблема не в сервисе, а в том, что какой-то процесс всё ещё держит ресурс открытым.