Линукс вОпросах


Гео и язык канала: Весь мир, Русский
Категория: Технологии


Проверь себя и готовься к собеседованиям.
• Linux
• DevOps
• Infrastructure
Каждый пост — один вопрос.
Каждый вопрос — одна Anki-карточка.

Связанные каналы

Гео и язык канала
Весь мир, Русский
Категория
Технологии
Статистика
Фильтр публикаций


Реальный кейс: kernel panic с сообщением "soft lockup - CPU#3 stuck for 22s". Что это значит?
Опрос
  •   Hardware fault — CPU физически завис
  •   Один поток ядра удерживает CPU без отдачи управления > 22 сек — обычно бесконечный цикл kernel code
  •   RAM сбойнула, ядро не может прочитать stack
  •   Сработал watchdog systemd на пользовательский процесс


Странная картина: ping до сервера 0.5 мс, curl к нему же — 200 мс на handshake. Где теряется время?
Опрос
  •   curl делает DNS-резолв на каждый запрос
  •   TCP handshake включает RTT + время на accept() — приложение медленно принимает соединения
  •   Ping использует ICMP fast path в ядре, TCP идёт через netfilter
  •   curl ждёт SSL handshake даже на http://


Любопытное: процесс делает много мелких write() в файл — диск загружен на 100%. Один большой write() тех же данных — диск на 10%. Почему?
Опрос
  •   Маленькие write() обходят page cache
  •   Каждый write() триггерит проверки и метаданные; batching снижает overhead
  •   Ядро шифрует мелкие записи через dm-crypt
  •   Большой write() использует DMA, маленькие — programmed I/O


Тонкость с epoll: добавили fd, получили event, обработали — а событий больше нет, хотя данные приходят. Почему?
Опрос
  •   epoll забыл fd после первого срабатывания
  •   Нужно вызывать epoll_ctl(MOD) после каждого read()
  •   Сокет в edge-triggered режиме — нужно читать до EAGAIN, иначе событие не повторится
  •   Level-triggered режим не работает с неблокирующими сокетами


Контейнер видит 64 ядра в /proc/cpuinfo, но cgroup ограничен двумя. Как ведёт себя приложение?
Опрос
  •   Приложение получит SIGXCPU при попытке использовать больше 2 ядер
  •   Ядро автоматически режет /proc/cpuinfo до 2 записей
  •   Приложение видит 64 ядра, создаёт 64 потока — все конкурируют за 2 cgroup-ядра, throttling
  •   cgroup перехватывает sched_getaffinity и возвращает 2


Загадка: nice -n -20 запустили процесс, но CPU он почти не получает. Что мешает?
Опрос
  •   Ядро игнорирует отрицательный nice без CAP_SYS_NICE
  •   Другие процессы в SCHED_FIFO/RR — RT-приоритет бьёт любой nice
  •   CFS не учитывает nice ниже -10 по умолчанию
  •   Процесс попал в cgroup с лимитом cpu.weight


Странность с памятью: процесс закрылся, но free -h не показывает прироста свободной RAM. Куда делось?
Опрос
  •   Память утекла в kernel space и потеряна до перезагрузки
  •   Память ушла в page cache — ядро держит файлы прочитанные процессом
  •   free некорректно учитывает анонимную память
  •   Память забрал systemd для своих внутренних кэшей


Загадка из реальной отладки: gdb attach к процессу — и весь сервис встал. Что произошло?
Опрос
  •   gdb сбрасывает page cache процесса
  •   ptrace_attach останавливает все потоки процесса — сервис заморожен пока gdb думает
  •   gdb меняет приоритет процесса на idle
  •   ptrace отключает signal handlers и сервис не отвечает на запросы


Любопытное свойство: strace -p PID тормозит процесс в десятки раз. Почему?
Опрос
  •   strace копирует всю память процесса при каждом syscall
  •   Каждый syscall вызывает два context switch через ptrace — оверхед огромный
  •   ptrace отключает кэш L1 на время трассировки
  •   strace переводит процесс в режим single-step CPU


Хитрый момент с TCP: соединение в ESTABLISHED, но данные не идут. tcpdump молчит. Где затык?
Опрос
  •   Сетевая карта в promiscuous mode не передаёт пакеты в стек
  •   Окно нулевое — receive buffer одной стороны заполнен, peer ждёт window update
  •   MTU mismatch на пути — пакеты молча дропаются
  •   TCP_NODELAY не выставлен и Нагл копит данные


В логах ядра: "Out of memory: Kill process". Но free показывает 2 GB свободно. Что случилось?
Опрос
  •   OOM killer сработал ошибочно — это известный баг
  •   Свободно по zone — закончилась память в конкретной зоне (DMA, Normal) или NUMA-узле
  •   Память была фрагментирована и не нашлось contiguous блока
  •   free не учитывает память cgroup — лимит был превышен


Загадка которую любят на собесах: что напечатает printf("hello"); fork(); без \n?
Опрос
  •   hello один раз — fork() копирует уже выведенное
  •   hello ноль раз — буфер потеряется при fork()
  •   hello трижды — родитель, ребёнок и сам printf
  •   hello дважды — буферизованная строка скопируется в оба процесса


Странный баг: процесс жрёт CPU, но top показывает 0%. Куда уходит время?
Опрос
  •   Время уходит в kernel space — нужно смотреть top в режиме system time
  •   Процесс прячет нагрузку через nice -20
  •   top считает только foreground процессы
  •   Это баг top — на самом деле CPU свободен


Странная ситуация в проде: df показывает 80% занято, du — 20%. Где разница?
Опрос
  •   du не считает hidden файлы, df считает
  •   df считает кэш страниц как занятое место
  •   Удалённые файлы всё ещё открыты процессами — занимают место, но du их не видит
  •   Разные FS используют разный размер блока для подсчёта


Часто встречается: процесс убит через kill -9, в /proc его нет, а порт занят. Что происходит?
Опрос
  •   Ядро держит порт зарезервированным 60 секунд после kill
  •   Другой процесс мгновенно занял тот же порт
  •   SIGKILL не закрывает сокеты — нужен shutdown() заранее
  •   Сокет ушёл в TIME_WAIT — живёт на уровне ядра без процесса


Боль каждого кто писал на сокетах: select() сказал readable, read() заблокировался. Почему?
Опрос
  •   select() на UDP сокетах врёт по дизайну
  •   Ядро сбросило буфер между вызовами при нехватке памяти
  •   Другой поток успел прочитать раньше — классический TOCTOU
  •   select() в принципе не гарантирует наличие данных


Любопытный эксперимент: chmod 000 на работающий бинарь. Процесс упадёт?
Опрос
  •   Да — упадёт с SIGSEGV на следующем page fault
  •   Ядро отзовёт маппинги .text секции
  •   Дочерние процессы через fork() сразу упадут
  •   Нет — права проверяются при open()/exec(), не при исполнении


Любимый вопрос на собесах: два потока читают одну int переменную без локов. Это безопасно?
Опрос
  •   Да, на x86 чтение int атомарно — гонок не будет
  •   Нет, ядро бросит SIGSEGV при конкурентном доступе
  •   Нет — компилятор закэширует переменную в регистре и обновлений не увидит
  •   Да, гонка возможна только при записи




Многие думают что exit() — это просто "умри". А что реально происходит до завершения процесса?
Опрос
  •   Ничего — ядро мгновенно убивает процесс
  •   Выполняются только signal handlers напоследок
  •   Только деструкторы глобальных C++ объектов
  •   atexit(), деструкторы C++, fflush() всех stdio — потом уже _exit() в ядро

Показано 20 последних публикаций.

838

подписчиков
Статистика канала