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

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

❓Вопрос: Что такое Linux PSI (Pressure Stall Information) и как его использовать для мониторинга?

✅Ответ: PSI — это механизм ядра Linux, позволяющий отслеживать давление на ресурсы: CPU, память и I/O. Он показывает, сколько времени процессы провели в ожидании этих ресурсов, что помогает выявить узкие места до того, как ситуация станет критичной (например, до вмешательства oom-killer).

PSI не измеряет загрузку напрямую — он измеряет «stall time» — сколько процессов одновременно не могли продолжить работу из-за нехватки ресурса. Это дает более реалистичную картину деградации системы.

Проверка PSI осуществляется через:

cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

Перехват stdout/stderr у systemd-сервиса в рантайме: без перезапуска и strace

Иногда вам нужно отладить запущенный systemd-сервис, чтобы понять, что он пишет в stdout или stderr, но:

– сервис уже работает,
– логи в journald запаздывают или отфильтрованы,
– вы не хотите/не можете использовать strace.

Что делать?

1️⃣Ищем дескрипторы вывода

Узнаём PID процесса:

systemctl show -p MainPID your-service

Идём в /proc/<PID>/fd/ — смотрим, куда пишется stdout (обычно fd 1) и stderr (обычно fd 2):

ls -l /proc/<PID>/fd/1

Может быть что-то вроде:

/proc/<PID>/fd/1 -> /dev/null
или -> socket:[12345]
или -> /run/log/journal/...

2️⃣Если это сокет — дублируем вывод

Можно аккуратно “подключиться” к этому дескриптору с помощью socat, если он всё ещё живой:

socat -u ABSTRACT-CONNECT:your-socket - | cat

Или, если это пайп или лог-файл — можно открыть его напрямую и читать в реальном времени:

tail -f /run/log/your-app.log

3️⃣Переоткрытие stdout/stderr без перезапуска

Иногда вы хотите временно направить stdout/err в другой файл (например, в отладочный лог). Если приложение не закрывает дескрипторы, можно сделать:

exec 3>/tmp/debug.log
sudo tee /proc/<PID>/fd/1 >/dev/null <&3

Это дублирует вывод в debug.log. Подходит не для всех случаев, но может сработать.

Диагностика high-load без perf и strace: ps + procfs как минимум

Когда серверу плохо, а perf, strace и eBPF недоступны (или неуместны) — остаётся old school: ps, top и чтение /proc.

И это вполне достаточно, чтобы найти:

– кто грузит CPU и память,
– где залипли процессы,
– кто блокирует I/O и тормозит остальных.

1️⃣Кто грузит CPU?
Проверяем самых голодных:

ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%cpu | head

Или top -H — если процесс многопоточный (например, Java или nginx), смотрим нагрузку по тредам.

2️⃣Что делают эти процессы?

Находим PID и лезем в /proc/<pid>/:

cat /proc/<pid>/status | grep -E 'State|VmRSS'

Смотрим состояние (Running, Sleeping, Zombie) и потребление памяти.

Читаем cmdline и cwd:

tr '\0' ' ' < /proc/<pid>/cmdline
ls -l /proc/<pid>/cwd

3️⃣Что с диском?

Находим процессы с активным I/O:

iotop -o    # если доступен

Или вручную:

grep -r . /proc/*/io | grep read_bytes | sort -nk2 | tail

Можно отследить, кто грузит диск даже без iotop.

4️⃣Где залипли?

Иногда процессы висят в ожидании ресурсов. Смотрим wchan:

ps -eo pid,wchan:30,cmd | grep -v -E '^\s*PID' | grep -v running

wchan показывает, где «спит» поток: например, futex_wait_queue_me (ожидание мьютекса) или unix_stream_recvmsg (чтение из сокета).

5️⃣Кто кого держит?

Смотрим locks:

cat /proc/locks

Или проверяем открытые файлы:

ls -l /proc/<pid>/fd/

Быстро даёт понять, кто блокирует файл или ждёт освобождения сокета/канала.

6️⃣А если нагрузка прыгает?

Снимаем срез каждые 5 секунд:

while true; do ps -eo pid,cmd,%cpu,%mem --sort=-%cpu | head -n 10; sleep 5; clear; done

Можно обернуть в watch или bash-циклы для простейшего мониторинга.

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

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

❓Вопрос: Чем отличается fork() от exec() в Linux и когда использовать каждый из них?

✅Ответ: fork() — это системный вызов, создающий новый процесс путём копирования текущего. Получившийся дочерний процесс будет точной копией родительского: он унаследует дескрипторы файлов, переменные окружения и текущее состояние. Основное отличие — у него будет свой PID. Это полезно, если вы хотите создать процесс, который продолжит выполнять ту же программу, но, например, с другими параметрами.

exec() — это семейство функций (execl, execp, execve и др.), которое заменяет текущий процесс на новый, загружая в его адресное пространство другую программу. После вызова exec() оригинальный код процесса больше не выполняется — он полностью замещается. Это удобно, если вы после fork() хотите в дочернем процессе запустить другую программу (что и делает большинство шеллов при запуске команд).

Живая миграция LXC-контейнера с минимальным downtime: CRIU + rsync

Иногда нужно перенести LXC-контейнер на другой сервер без остановки сервисов внутри — например, при плановой миграции, апгрейде хоста или изменении инфраструктуры.

С помощью CRIU (Checkpoint/Restore In Userspace) и rsync это возможно почти без прерывания работы.

⏺Подготовка контейнера

На обоих серверах должны быть:
•одинаковые версии LXC и CRIU (apt install criu lxc)
• идентичные ядра (или как минимум — поддержка CONFIG_CHECKPOINT_RESTORE)
• включён nesting и features.criu в конфиге LXC

Пример конфигурации:

lxc.apparmor.profile = unconfined
lxc.mount.auto = proc:rw sys:rw
lxc.cap.drop =
lxc.cgroup.devices.allow = a
lxc.seccomp.profile = unconfined

⏺Первый rsync контейнерной файловой системы

Копируем всё, кроме /proc, /sys, сокетов и временных данных:

rsync -aAXv --exclude={"/proc/*","/sys/*","/dev/pts/*","/run/*","/tmp/*"} /var/lib/lxc/myct root@target:/var/lib/lxc/

⏺Заморозка и снятие чекпоинта

На исходном сервере:

lxc-checkpoint -n myct -D /tmp/myct-ckpt -s

Ключ -s говорит заморозить (stop) контейнер после дампа.

⏺Инкрементальный rsync чекпоинта и изменений

rsync -aAXv /tmp/myct-ckpt root@target:/tmp/
rsync -aAXv /var/lib/lxc/myct/ root@target:/var/lib/lxc/myct/

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

⏺Восстановление контейнера

На целевом сервере:

lxc-start -n myct -s -F -D --restore --directory=/tmp/myct-ckpt

Контейнер стартует с того же состояния, с которого был заморожен, включая открытые сокеты, процессы и даже ssh-сессии.

Редактирование systemd-юнитов с rollback и временными изменениями

Иногда нужно изменить поведение systemd-сервиса, но:

– не хочется трогать /etc/systemd/system/*.service,
– правка временная или нужна только до следующей перезагрузки,
– важно быстро откатиться без git, ручного копирования и боли.

Решение — systemctl edit и friends.

1️⃣Временные правки без записи на диск

systemctl edit --runtime my-service

Создаёт юнит-оверклайд в /run/systemd/system/ — изменения исчезнут после ребута. Идеально для тестов на проде.

Пример содержимого:

[Service]
Environment="DEBUG=1"
ExecStart=
ExecStart=/usr/bin/my-app --debug

ExecStart= сначала сбрасывает оригинальную строку, затем задаётся новая.

2️⃣Постоянные override-файлы, не трогая оригинал

systemctl edit my-service

Создаёт или редактирует /etc/systemd/system/my-service.service.d/override.conf. При обновлении пакета оригинальный юнит не затирается.

3️⃣Проверка и rollback

Проверяем итоговый конфиг:

systemctl cat my-service

Откат:

systemctl revert my-service

Удаляет override-файлы и возвращает дефолт.

4️⃣Перезапуск с атомарной подменой

Если правите в проде — перезапускайте юнит с минимальным downtime:

systemctl daemon-reexec
systemctl try-restart my-service

Или через socket activation (если настроено) — тогда сам сервис не нужен в момент старта, но запросы не теряются.

5️⃣Подводные камни

– systemctl edit не валидирует синтаксис — можно легко сделать опечатку. Проверяйте через systemd-analyze verify.

– Если меняете ExecStart, не забудьте сначала сбросить его через ExecStart= без аргументов.