Знаете ли вы, что kill -9 не всегда убивает процесс?

Запускаем kill -9 <PID>, ждем что процесс будет убит – а он продолжает висеть в ps aux. Пробуем еще раз от рута, с разными сигналами – ничего не помогает. Проблема здесь в том, что процесс в статусе D (uninterruptible sleep) просто игнорирует все сигналы, включая SIGKILL. Это происходит потому что процесс находится в системном вызове ядра и ждет завершения I/O операции – пока ядро не закончит работу, процесс не может быть убит.

Представим себе такой неубиваемый процесс:

# Запустим что-то с подвисшим NFS
ls /mnt/broken_nfs &

# Посмотрим на статус процесса
ps aux | grep ls
# USER  PID  %CPU %MEM    VSZ   RSS TTY  STAT START   TIME COMMAND
# user  1234  0.0  0.1   2345   678 ?    D    10:30   0:00 ls /mnt/broken_nfs

# D в STAT означает тот самый uninterruptible sleep
# Попробуем его убить
kill -9 1234

# Но процесс все еще жив:
ps aux | grep 1234
# kill -9 не сработал

Статус D означает что процесс в системном вызове ядра и не может быть прерван. Обычно это операции ввода-вывода – чтение с диска, сетевой запрос, ожидание блокировки.

Но мы можем увидеть ВСЕ процессы в D-состоянии:

# Через ps aux
ps aux | awk '$8 ~ /D/ { print $0 }'

# Или через top/htop
top
# Прожимаем 'o' для фильтра, вводим: S=D
# Покажутся только D-процессы

# Смотрим stack trace процесса
cat /proc/1234/stack
# [<0>] wait_on_page_bit+0x123/0x456
# [<0>] read_pages+0x234/0x567
# [<0>] __do_page_cache_readahead+0x345/0x678
# Будет видно что процесс ждет чтения страницы

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

Процесс в D можно убить, но только через перезагрузку или починив то, что он ждет:

# Для NFS – размонтировать принудительно
umount -f /mnt/nfs
# Или ленивое размонтирование
umount -l /mnt/nfs

Процессы будут убиты, когда NFS отвалится; для сломанного диска – только перезагрузка.

Почему SIGKILL не сработает? Потому что сигналы обрабатываются только когда процесс возвращается в user space. D-процесс находится в kernel space системного вызова, а ядро не проверяет сигналы пока вызов не завершится. Но мы можем увидеть где процесс застрял:

cat /proc/1234/wchan
# wait_on_page_bit
# Процесс ждет страницу в памяти

Процессы в состоянии D (uninterruptible sleep) не реагируют на сигналы, включая SIGKILL. Они застревают в системных вызовах ядра, обычно при I/O операциях с зависшими устройствами (NFS, сломанный диск, RAID). Убить такой процесс можно только решив проблему ввода-вывода – размонтировав файловую систему, отключив устройство или через перезагрузку. Проверяйте статус процесса через ps – если в колонке STAT стоит значение D – значит kill -9 не поможет.

Код на салфетке x Кусочки кода

Всем доброго вечера пятницы!

«Искусство самообороны» (2019)

«Искусство самообороны» — чёрная комедия о тихом бухгалтере Кейси, которого жестоко избивает банда мотоциклистов. Вместо пистолета он выбирает додзё каратэ и попадает под влияние харизматичного, но очень токсичного сенсея.
​
Тренировки постепенно превращают его из забитого «офисного мыша» в агрессивного фаната насилия, а додзё — в секту с ночными уроками, жестокими правилами и мрачными секретами. Кейси шаг за шагом узнаёт правду о сенсее, преступлениях школы и своём собственном страхе.
​
Фильм одновременно высмеивает культ «мужественности на стероидах» и показывает, как легко хрупкого человека сломать под видом «закалки характера». Подойдёт, если любите странное, неловкое кино с юмором на грани и неожиданно жёсткой развязкой.

Приятного просмотра!

Всем привет!

Уже завтра в 13:00 МСК, мы встречаемся на практикуме по Python!

Что будем делать?
В прямом эфире, вместе со мной, вы:
👉 Напишете код Telegram-бота.
👉 Подключите к нему искусственный интеллект GigaChat.
👉 Задеплоите его, чтобы он работал.

И всё это — за одну встречу.
Даже если вы никогда раньше не программировали, у вас получится рабочий проект. Это лучший способ понять, подходит ли вам Python.

Как попасть?
Эфир закрытый. Чтобы получить доступ, нужна регистрация:
Зарегистрироваться

ВАЖНО: Подготовка к эфиру
Это не вебинар "послушать под чай", а практикум. Чтобы мы успели всё сделать, нужно подготовить рабочее окружение заранее.

Сразу после регистрации вы попадете в чат участников. Там в закрепе лежит инструкция. Пожалуйста, выполните её сегодня вечером, чтобы завтра в 13:00 мы сразу начали творить магию, а не устанавливать программы.

До встречи завтра в эфире! 🚀

Знаете ли вы, что > затирает файл до выполнения команды?

Бывает, нужно изменить файл на месте, напишешь cat file.txt > file.txt – а файл пустой. Дело в том, что Shell открывает файл для записи и обрезает его в ноль до того, как запустится команда. К моменту когда cat пытается его прочитать, в файле уже ничего нет.

Посмотрим:

echo "Hello World" > test.txt
cat test.txt
# Hello World

cat test.txt > test.txt
cat test.txt
# (пусто - ничего не выводит, файл 0 байт)

Файл обнулился до того как cat успел его прочитать. То же самое с любой командой – grep pattern file.txt > file.txt или sort file.txt > file.txt дадут пустой файл:

1. Shell видит > file.txt и открывает файл для записи
2. Файл обрезается до 0 байт
3. Команда запускается и читает уже пустой файл

Правильно – сделать временный файл:

echo -e "3\n1\n2" > numbers.txt
sort numbers.txt > temp.txt && mv temp.txt numbers.txt
cat numbers.txt
# 1
# 2
# 3

Shell обрабатывает редиректы до запуска команды – файл обнуляется в момент открытия для записи, еще до выполнения. Для модификации на месте используйте временный файл или утилиты с флагом -i типа sed -i.

Код на салфетке x Кусочки кода

Знаете ли вы, что time.sleep() в Python не гарантирует точную паузу?

Когда нужно приостановить выполнение скрипта на заданное количество времени, первое, что приходит на ум – это time.sleep(). Кажется, что time.sleep(5) всегда остановит выполнение ровно на 5 секунд. Но это не так – time.sleep(X) это скорее обещание операционной системы приостановить процесс как минимум на X секунд, не гарантия точной паузы.

Проверим на 1000 итераций:

import time

duration = 0.001  # 1 миллисекунда
diffs = []

for _ in range(1000):
    start = time.monotonic()
    time.sleep(duration)
    actual = time.monotonic() - start
    diffs.append(actual - duration)

print(f"Запрошенная пауза: {duration * 1000:.1f} мс")
print(f"Мин. отклонение:   +{min(diffs) * 1000:.3f} мс")
print(f"Среднее отклонение: +{sum(diffs)/len(diffs) * 1000:.3f} мс")
print(f"Макс. отклонение:  +{max(diffs) * 1000:.3f} мс")

При запуске будет видно, что все 1000 раз фактическая пауза больше запрошенной: sleep() гарантирует паузу не менее указанного времени, но не точно указанное время.

Почему так происходит?

1. Планировщик ОС – после сна процесс встает в очередь и ждет, пока ОС до него доберется.
2. Разрешение таймера – если гранулярность 10 мс, запрос на 1 мс все равно займет минимум 10, а sleep(0) – значит, отдать остаток кванта другим процессам.
3. Системная нагрузка – чем больше загружена система, тем больше задержка.

time.sleep() хорошо подходит, когда нужна приблизительная пауза или просто разгрузить процессор. Но если нужна высокая точность синхронизации, нужны более низкоуровневые механизмы, учитывающие особенности конкретной ОС.

Код на салфетке x Кусочки кода

Знаете ли вы, что cd – это не программа?

cd и ls – обе короткие, используемые каждый день в терминале, команды. Но одна из них – программа, файл на диске, а другая – функция, встроенная прямо в shell.

type ls
# ls is /usr/bin/ls

type cd
# cd is a shell builtin

ls – обычная программа в /usr/bin/. А cd в файловой системе не существует, он живет внутри самого shell.

Зачем так сделано? Когда shell запускает любую программу, он создает для нее дочерний процесс. Дочерний процесс работает в своей копии окружения и не может передать изменения обратно родителю. Если бы cd был программой – он бы сменил директорию внутри дочернего процесса и тот бы завершился, а ваш shell остался бы где был.

Попробуем запустить cd как отдельный процесс, как если бы он был программой:

bash -c "cd /tmp && pwd"
# /tmp

pwd
# остался в той же директории

Дочерний процесс сменил директорию у себя и завершился, родительский shell остался где был. Именно поэтому cd должен быть встроенной командой – иначе в нем просто нет смысла.

Кстати, export, source, exit – тоже встроенные по той же причине. Все они должны менять состояние текущего shell: переменные окружения, выполнение скриптов в текущем контексте, завершение сессии. Если вынести любую из них в отдельный процесс – она теряет смысл.

Код на салфетке x Кусочки кода

Чем отличается RAG по туториалу от реальной системы

Собрать RAG или агента по туториалу — легко. А довести до пользователя так, чтобы он не сломался — нет.

Но в реальной эксплуатации начинаются сюрпризы:
галлюцинации, нестабильное качество, высокий latency, неожиданные счета за API, агент зацикливается или принимает странные решения. Всё вроде работает — но бизнесу этим пользоваться нельзя.

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

Поэтому DL-инженеры из DeepSchool сделали курс «RAG и AI-агенты», программу про переход от прототипа к рабочим системам.

После обучения вы сможете:
• выбирать архитектуру под задачу, нагрузку, бюджет
• проектировать и собирать production-ready RAG и агентские системы с измеримыми метриками
• настраивать качество: query rewriting, reranking, гибридный поиск, tool-use, memory
• разбираться в системном дизайне и деплое
• чётко формулировать задачу, определять границы MVP и осознанно выбирать компромиссы в реализации

Программа для ML/DL-инженеров и backend-разработчиков, которые работали с LLM и хотят строить системы для реальных пользователей.

Для подписчиков моего канала до 6 марта действует скидка 25% 🔥

Изучайте подробности на сайте и оставляйте заявку!

Реклама. ИП Фатыхов Тимур Маратович, ИНН 540132430312, Erid 2VtzqwJny1e