10$ за техническое собеседование на английском языке:

1. Отправьте запись технического собеседования на английском языке файлом на этот аккаунт
2. Добавьте ссылку на вакансию или пришлите название компании и должность
3. Напишите номер кошелка USDT (Tether) на который отправить 10$

🛡 Важно:

– Запись будет использована только для сбора данных о вопросах
– Вы останетесь анонимны
– Запись нигде не будет опубликована

🤝 Условия:

– Внятный звук, различимая речь
– Допустимые профессии:
• Любые программисты
• DevOps
• Тестировщики
• Дата сайнтисты
• Бизнес/Системные аналитики
• Прожекты/Продукты
• UX/UI и продукт дизайнеры

📌 Как убить зомби процесс ?

💬 Спрашивают в 13% собеседований

Зомби-процесс (или дефункциональный процесс) — это процесс, который завершился, но его запись еще не была удалена из таблицы процессов, так как родительский процесс не прочитал его статус с помощью системного вызова wait(). Не используют системные ресурсы, кроме записи в таблице процессов, но могут стать проблемой, если их слишком много.

Удаление зомби-процесса

Напрямую это сделать невозможно, так как он уже завершен. Вместо этого необходимо воздействовать на его родительский процесс, чтобы тот выполнил wait() и освободил запись зомби-процесса.

Шаги:

1️⃣ Найти родительский процесс зомби-процесса:

Сначала нужно определить идентификатор (PID) и его родительского процесса (PPID).

      ps aux | grep 'Z'
   

Пример вывода:

   user     1234  0.0  0.0      0     0 ?        Z    13:00   0:00 [my_zombie_process] <defunct>
   

   В данном примере 1234 — это PID зомби-процесса.

2️⃣ Найти родительский процесс (PPID):

   Чтобы узнать родительский процесс, используйте команду ps -o ppid=:

      ps -o ppid= -p 1234
   

Пример вывода:

   5678
   

   Здесь 5678 — это PID родительского процесса.

3️⃣ Перезапустить или завершить родительский процесс:

➕ Если родительский процесс важен и его нельзя завершить, попробуйте его перезапустить. Это может вызвать выполнение wait(), и зомби-процесс будет очищен.

➕ Если перезапуск невозможен или не помогает, можно попытаться завершить родительский процесс. Используйте команду kill для этого:

      sudo kill -HUP 5678
   

Команда kill -HUP отправляет сигнал перезапуска родительскому процессу, что может вызвать выполнение wait(). Если это не помогает, можно использовать сигнал SIGTERM или SIGKILL:

      sudo kill -TERM 5678
   sudo kill -KILL 5678
   

Внимание: Прежде чем завершать родительский процесс, убедитесь, что это не повредит системе или важным службам.

1️⃣ Найти все зомби-процессы:

      ps aux | grep 'Z'
   

2️⃣ Для каждого зомби-процесса найти его PPID:

      ps -o ppid= -p <PID_зомби>
   

3️⃣ Перезапустить или завершить родительский процесс:

      sudo kill -HUP <PPID>
   

Если это не помогает:

      sudo kill -TERM <PPID>
   sudo kill -KILL <PPID>
   

Зомби-процесс — это завершившийся процесс, запись которого не удалена, так как родительский процесс не выполнил wait(). Чтобы удалить зомби-процесс, нужно воздействовать на его родительский процесс.

🔥 ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Как сирота отличается от зомби процесса ?

💬 Спрашивают в 13% собеседований

Сиротский процесс (orphan process) и зомби-процесс (zombie process) представляют собой два разных состояния процессов в операционной системе Unix/Linux. Давайте рассмотрим, в чем их отличие.

Сиротский процесс

Это процесс, чей родительский процесс завершился до того, как завершился сам процесс. В этом случае сиротский процесс автоматически принимается на попечение процессом init (PID 1) или systemd, который становится его новым родителем. init или systemd затем отслеживает такие процессы и выполняет wait(), чтобы предотвратить появление зомби-процессов.

1️⃣ Процесс A создает процесс B.

2️⃣ Процесс A завершается, пока процесс B еще выполняется.

3️⃣ Процесс B становится сиротским и его родителем становится init или systemd.

Зомби-процесс

Это процесс, который завершился, но его запись в таблице процессов все еще существует, потому что его родительский процесс не вызвал системный вызов wait() для получения кода завершения и других данных. Зомби-процессы не используют системные ресурсы, кроме записи в таблице процессов, но если родительский процесс не выполняет wait(), то такие записи могут накапливаться.

1️⃣ Процесс A создает процесс B.

2️⃣ Процесс B завершается.б

3️⃣ Процесс A не вызывает wait(), чтобы забрать статус завершения процесса B.

4️⃣ Процесс B остается в состоянии зомби.

Отличия:

1️⃣ Состояние родительского процесса:

➕ Сиротский процесс: Родительский процесс завершился до завершения дочернего процесса

➕ Зомби-процесс: Дочерний процесс завершился, но родительский процесс не вызвал wait(), чтобы забрать статус завершения.

2️⃣ Состояние дочернего процесса:

➕ Сиротский процесс: Процесс продолжает выполняться и получает нового родителя (init или systemd).

➕ Зомби-процесс: Процесс уже завершился, но запись о нем все еще существует в таблице процессов.

3️⃣ Ресурсы:

➕ Сиротский процесс: Использует системные ресурсы как обычный процесс.

➕ Зомби-процесс: Не использует системные ресурсы, кроме записи в таблице процессов.

Сиротский процесс — это процесс, чей родитель завершился, и он был передан под управление init или systemd. Зомби-процесс — это завершившийся процесс, запись о котором все еще существует, потому что родительский процесс не вызвал wait().

ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Чем DevOps отличается от Agile ?

💬 Спрашивают в 13% собеседований

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

Agile

Это методология разработки программного обеспечения, которая акцентирует внимание на гибкости, скорости и итеративном подходе к разработке. Основные принципы Agile изложены в Манифесте Agile, который включает четыре ключевых ценности и двенадцать принципов.

Основные характеристики:

1️⃣ Итеративный и инкрементальный подход:

➕ Проект делится на небольшие итерации, каждая из которых заканчивается выпуском работающего программного продукта.

2️⃣ Коллективная работа и коммуникация:

➕ Акцент на тесное взаимодействие между членами команды и с заказчиком.

3️⃣ Адаптивное планирование:

➕ Возможность быстро адаптироваться к изменениям требований в ходе проекта.

4️⃣ Постоянное улучшение:

➕ Регулярные ретроспективы для анализа и улучшения процесса разработки.

Примеры:

➕ Scrum: Подход, основанный на спринтах, регулярных встречах (ежедневные stand-up, спринт-планирование, ретроспективы) и определенных ролях (Scrum Master, Product Owner, команда разработки).

➕ Kanban: Метод, ориентированный на визуализацию рабочего процесса и управление потоком задач.

DevOps

Это культурный и методологический подход, направленный на интеграцию и сотрудничество между командами разработки (Dev) и эксплуатации (Ops) для более быстрой и надежной доставки программного обеспечения.

Основные характеристики:

1️⃣ Автоматизация:

➕ Автоматизация процессов сборки, тестирования, развертывания и мониторинга.

2️⃣ Непрерывная интеграция и доставка (CI/CD):

➕ Практика частой интеграции кода и его автоматического развертывания на различных средах (разработка, тестирование, продакшн).

3️⃣ Инфраструктура как код (IaC):

➕ Управление инфраструктурой через код для обеспечения репликации и масштабирования сред.

4️⃣ Мониторинг и логирование:

➕ Постоянный мониторинг приложений и инфраструктуры для быстрого обнаружения и устранения проблем.

5️⃣ Культурное изменение:

➕ Сдвиг в культуре организации для улучшения сотрудничества между командами разработки и эксплуатации.

Примеры:

➕ Jenkins: Инструмент для автоматизации CI/CD.

➕ Docker: Платформа для контейнеризации приложений.

➕ Kubernetes: Система оркестрации контейнеров.

➕ Terraform: Инструмент для управления инфраструктурой как кодом.

➕ Prometheus и Grafana: Инструменты для мониторинга и визуализации данных.

Основные различия

1️⃣ Фокус:

➕ Agile: Сосредоточен на процессе разработки и управлении изменениями требований через итерации и инкременты.

➕ DevOps: Сосредоточен на всей цепочке создания стоимости — от разработки до развертывания и эксплуатации, обеспечивая быструю и стабильную доставку программного обеспечения.

2️⃣ Команды и роли:

➕ Agile: Включает роли, такие как Product Owner, Scrum Master и команда разработки.

➕ DevOps: Включает разработчиков, специалистов по эксплуатации, инженеров по автоматизации и других, кто работает над интеграцией и доставкой.

3️⃣ Процессы и инструменты:

➕ Agile: Использует методологии, такие как Scrum и Kanban, для управления процессом разработки.

➕ DevOps: Использует инструменты и практики для автоматизации и мониторинга всего жизненного цикла приложения.

4️⃣ Цели:

➕ Agile: Ускорить процесс разработки, улучшить взаимодействие внутри команды и с заказчиком.

➕ DevOps: Ускорить и автоматизировать процесс доставки программного обеспечения, улучшить качество и надежность выпускаемых продуктов, а также обеспечить непрерывное развертывание и мониторинг.

Agile — это методология разработки, фокусирующаяся на итеративном подходе и гибкости, а DevOps — это культурный и методологический подход, направленный на интеграцию разработки и эксплуатации для обеспечения быстрой и надежной доставки программного обеспечения.

ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Какая файловая система бывает с динамическими inode ?

💬 Спрашивают в 13% собеседований

Одной из файловых систем с динамическим управлением inodes является XFS.

XFS и динамическое управление inodes

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

🤔 Как работает динамическое управление inodes

1️⃣ Динамическое выделение inodes:

➕ В отличие от файловых систем, таких как ext2/ext3/ext4, где количество inodes задается при создании файловой системы и не может быть изменено, XFS выделяет inodes по мере необходимости. Это значит, что файловая система XFS не имеет фиксированного числа inodes при создании.

2️⃣ Адаптация к рабочей нагрузке:

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

3️⃣ Использование свободного пространства:

➕ Использует свободное пространство файловой системы для хранения inodes. Это позволяет эффективно использовать доступное дисковое пространство и предотвращает ситуацию, когда место на диске еще есть, но новые файлы создать невозможно из-за нехватки inodes.

Для создания файловой системы XFS на диске /dev/sdX1 используется утилита mkfs.xfs:

mkfs.xfs /dev/sdX1

Проверка использования inodes на XFS

Для этого на файловой системе XFS можно использовать команду df -i:

df -i /mnt/myxfs

Пример вывода:

Filesystem     Inodes IUsed IFree IUse% Mounted on
/dev/sdX1         0     0     0     -    /mnt/myxfs

На XFS файловых системах команда df -i может показывать значения inodes как 0, что указывает на динамическое управление inodes.

Файловая система XFS использует динамическое управление inodes, выделяя их по мере необходимости и позволяя эффективно использовать дисковое пространство. Это предотвращает проблемы с нехваткой inodes, которые могут возникать в файловых системах с фиксированным числом inodes.

ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Что такое OOM ?

💬 Спрашивают в 13% собеседований

OOM (Out of Memory) — это состояние, в котором операционная система или приложение сталкивается с нехваткой оперативной памяти для выполнения текущих задач или запросов. Когда система исчерпывает доступную память, она не может выделить необходимое количество памяти для новых или уже работающих процессов.

🤔 Что происходит при OOM?

Когда система сталкивается с ним, она может попытаться освободить память, завершив некоторые процессы. В Linux, например, существует специальный процесс под названием OOM Killer, который запускается, когда система испытывает критическую нехватку памяти.

Основные шаги:

1️⃣ Выделение памяти:

➕ Приложения запрашивают память у операционной системы для выполнения своих задач. Если доступной памяти недостаточно, система начинает испытывать нехватку.

2️⃣ Использование swap:

➕ Если оперативная память заканчивается, система может использовать swap (файл или раздел на диске, используемый как дополнительная память). Однако, swap медленнее, чем оперативная память, и при интенсивном использовании swap производительность системы может существенно снизиться.

3️⃣ Активация:

➕ Если свободной памяти и swap все равно недостаточно, в Linux запускается OOM Killer. Это механизм, который выбирает и завершает один или несколько процессов для освобождения памяти.

4️⃣ Завершение процессов:

➕ Делает это, основываясь на различных метриках, таких как использование памяти, приоритет процесса и т.д. Обычно он выбирает процессы с наибольшим использованием памяти или процессы с низким приоритетом.

Причины возникновения

1️⃣ Неоптимизированное программное обеспечение:

➕ Приложения могут потреблять больше памяти, чем необходимо, из-за утечек памяти или неправильного управления ресурсами.

2️⃣ Недостаток ресурсов:

➕ Физическая память системы может быть недостаточной для текущей рабочей нагрузки.

3️⃣ Непредвиденные рабочие нагрузки:

➕ Внезапное увеличение рабочих нагрузок или запуск ресурсовоемких приложений может привести к исчерпанию памяти.

Примеры предотвращения и решения

1️⃣ Мониторинг использования памяти:

➕ Регулярное наблюдение за использованием памяти позволяет своевременно выявлять проблемы. Инструменты, такие как top, htop, free и vmstat, помогают отслеживать использование памяти.

2️⃣ Настройка swap:

➕ Увеличение размера swap раздела или файла может помочь временно компенсировать нехватку оперативной памяти.

3️⃣ Оптимизация приложений:

➕ Оптимизация кода для снижения потребления памяти и устранение утечек памяти может предотвратить возникновение OOM.

4️⃣ Настройка OOM Killer:

➕ В Linux можно настроить поведение OOM Killer, используя /proc файловую систему и такие параметры, как /proc/sys/vm/oom_adj и /proc/<pid>/oom_score_adj, чтобы контролировать приоритеты завершения процессов.

Пример

Команда free показывает использование оперативной памяти и swap:

free -h

Пример вывода:

              total        used        free      shared  buff/cache   available
Mem:            16G         12G        1.5G        512M        2.5G         3G
Swap:           4G          2G         2G

Команда top позволяет наблюдать за процессами в реальном времени и их использованием памяти:

top

OOM (Out of Memory) — это состояние нехватки оперативной памяти, когда система не может выделить память для новых или существующих процессов. Для решения этой проблемы используется OOM Killer, который завершает процессы для освобождения памяти.

ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Как linux выбирает, какой из процессов завершить ?

💬 Спрашивают в 13% собеседований

Когда в системе Linux возникает состояние OOM (Out of Memory), в дело вступает специальный механизм под названием OOM Killer. Его задача — выбрать и завершить один или несколько процессов, чтобы освободить память и стабилизировать систему. Процесс выбора происходит на основе нескольких факторов, и система старается минимизировать ущерб при завершении процессов.

Основные факторы выбора процесса для завершения

1️⃣ OOM Score:

➕ Каждый процесс в системе имеет параметр под названием oom_score, который показывает, насколько вероятно, что данный процесс будет завершен OOM Killer. Чем выше значение, тем более вероятно, что процесс будет завершен.

2️⃣ Использование памяти:

➕ Предпочитает завершать процессы, которые потребляют больше всего памяти, так как это позволит освободить больше ресурсов сразу.

3️⃣ Приоритет процесса (niceness):

➕ Система учитывает приоритет процесса. Процессы с низким приоритетом (высоким значением niceness) более вероятно будут завершены по сравнению с процессами с высоким приоритетом.

4️⃣ Состояние процесса:

➕ Процессы, находящиеся в состоянии "спящего" (sleeping) или "ожидания" (waiting), могут быть менее приоритетными для завершения по сравнению с процессами, которые активно выполняют задачи.

5️⃣ Семейство процессов:

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

Пример: Вычисление oom_score

Система использует несколько файлов в файловой системе /proc для определения и управления поведением OOM Killer. Основные файлы:

➕ /proc/<pid>/oom_score — показывает текущий OOM score для процесса с идентификатором PID.

➕ /proc/<pid>/oom_adj и /proc/<pid>/oom_score_adj — позволяют изменить приоритет процесса для OOM Killer.

Проверка oom_score для процесса:

cat /proc/<pid>/oom_score

Настройка приоритета процесса:

echo -17 > /proc/<pid>/oom_score_

Значение -17 минимизирует вероятность того, что процесс будет выбран для завершения.

Пример

Система испытывает нехватку памяти, и его необходимо выбрать процесс для завершения. Он будет анализировать текущие процессы и их oom_score. Например:

➕ Процесс A: Использует 2 ГБ памяти, oom_score = 500

➕ Процесс B: Использует 1 ГБ памяти, oom_score = 300

➕ Процесс C: Использует 4 ГБ памяти, oom_score = 700

В этом случае, процесс C с наибольшим значением oom_score и использованием памяти будет наиболее вероятным кандидатом для завершения.

Управление поведением

Администраторы могут управлять его поведением, изменяя значения в /proc. Например, можно повысить приоритет критически важного процесса:

echo -1000 > /proc/<critical_process_pid>/oom_score_adj

Или, наоборот, снизить приоритет ненужного процесса:

echo 1000 > /proc/<non_critical_process_pid>/oom_score_adj

OOM Killer используется для завершения процессов при нехватке памяти. Oн выбирает процессы на основе значений oom_score, использования памяти, приоритета процессов и их состояния.

ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Какой из сигналов SIGTERM / SIGKILL вызывает команда kill ?

💬 Спрашивают в 13% собеседований

Команда kill в Unix и Unix-подобных системах (например, Linux) используется для отправки сигналов процессам. По умолчанию команда kill отправляет сигнал SIGTERM. Сигнал SIGKILL можно отправить явно, указав его как параметр.

Основные сигналы

➕ SIGTERM (сигнал номер 15):

Это сигнал завершения, который может быть перехвачен и обработан процессом. Процесс может выполнить очистку и корректно завершить свою работу. SIGTERM является сигналом завершения по умолчанию, отправляемым командой kill.

➕ SIGKILL (сигнал номер 9):

Это сигнал принудительного завершения, который не может быть перехвачен, заблокирован или проигнорирован процессом. Он немедленно завершает процесс. SIGKILL используется, когда необходимо немедленно завершить процесс, который не отвечает на другие сигналы.

Примеры

Отправка сигнала SIGTERM (по умолчанию):

Когда используется команда kill без указания конкретного сигнала, отправляется сигнал SIGTERM:

kill <PID>

где <PID> — идентификатор процесса, которому отправляется сигнал.

Например:

kill 1234

Отправка сигнала SIGKILL:

Чтобы это сделать, необходимо явно указать его номер (9) или имя (SIGKILL):

kill -9 <PID>

или

kill -SIGKILL <PID>

Например:

kill -9 1234

или

kill -SIGKILL 1234

Различия

1️⃣ SIGTERM:

➕ Процесс может перехватить и обработать сигнал, выполняя очистку и корректное завершение.

➕ Процесс может игнорировать сигнал (если он настроен на это).

➕ Это "вежливый" способ завершения процесса.

2️⃣ SIGKILL:

➕ Процесс не может перехватить, обработать или игнорировать сигнал.

➕ Процесс немедленно завершает работу без возможности выполнения очистки.

➕ Используется в случаях, когда процесс не отвечает на SIGTERM.

Примеры

1️⃣ Отправка сигнала SIGTERM:

kill 1234

Если процесс 1234 настроен на перехват и обработку SIGTERM, он выполнит необходимые операции по завершению и затем завершится. Если процесс не отвечает на SIGTERM, можно использовать SIGKILL.

2️⃣ Отправка сигнала SIGKILL:

kill -9 1234

Процесс 1234 будет немедленно завершен, без возможности выполнения каких-либо операций по завершению.

Команда kill по умолчанию отправляет сигнал SIGTERM, который может быть перехвачен и обработан процессом. Сигнал SIGKILL (отправляемый с помощью kill -9 или kill -SIGKILL) немедленно завершает процесс и не может быть перехвачен или проигнорирован.

ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Что такое хендлеры ?

💬 Спрашивают в 13% собеседований

Хендлеры (handlers) в контексте программирования и системного администрирования представляют собой функции или процедуры, которые отвечают на определенные события или сигналы. Могут использоваться в различных областях, таких как обработка сигналов в операционных системах, обработка событий в графических интерфейсах пользователя (GUI), веб-программировании и автоматизации задач.

1️⃣ Обработка сигналов в Unix/Linux

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

import signal
import time

# Определение хендлера для сигнала SIGTERM
def handle_sigterm(signum, frame):
    print("Received SIGTERM, exiting gracefully...")
    exit(0)

# Регистрация хендлера
signal.signal(signal.SIGTERM, handle_sigterm)

# Бесконечный цикл, который будет прерван сигналом
while True:
    print("Running...")
    time.sleep(1)

2️⃣ Веб-программирование

В нем хендлеры используются для обработки запросов к веб-серверу. В различных фреймворках, таких как Django или Flask, хендлеры определяются для обработки различных маршрутов и методов HTTP.

from flask import Flask, request

app = Flask(__name__)

# Определение хендлера для GET запроса к корневому маршруту
@app.route('/', methods=['GET'])
def handle_root():
    return "Hello, World!"

# Определение хендлера для POST запроса к маршруту /submit
@app.route('/submit', methods=['POST'])
def handle_submit():
    data = request.form['data']
    return f"Received: {data}"

if __name__ == '__main__':
    app.run(debug=True)

3️⃣ Обработка событий в GU

В графических интерфейсах пользователя (GUI) хендлеры используются для обработки событий, таких как нажатия кнопок, перемещения мыши или ввода с клавиатуры.

import tkinter as tk

# Определение функции-хендлера для нажатия кнопки
def on_button_click():
    print("Button clicked!")

# Создание основного окна
root = tk.Tk()
root.title("Example GUI")

# Создание кнопки и привязка хендлера
button = tk.Button(root, text="Click Me", command=on_button_click)
button.pack()

# Запуск основного цикла приложения
root.mainloop()

Хендлеры

Ansible

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

- name: Ensure nginx is installed and configured
  hosts: webservers
  tasks:
    - name: Install nginx
      apt:
        name: nginx
        state: present

    - name: Copy nginx configuration
      template:
        src: templates/nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify:
        - Restart nginx

  handlers:
    - name: Restart nginx
      service:
        name: nginx
        state: restarted

Хендлеры — это функции или процедуры, которые обрабатывают определенные события или сигналы в различных контекстах, таких как операционные системы, веб-программирование, графические интерфейсы и автоматизация задач.

ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Что такое системные вызовы и системные сигналы ?

💬 Спрашивают в 13% собеседований

Системные вызовы и системные сигналы являются основными механизмами взаимодействия программного обеспечения с операционной системой в Unix и Unix-подобных системах, таких как Linux. Они обеспечивают доступ к аппаратным и программным ресурсам системы и позволяют управлять различными аспектами работы процессов.

Системные вызовы (system calls)

Это интерфейс, предоставляемый операционной системой для выполнения низкоуровневых операций, таких как работа с файловой системой, управление процессами, работа с сетью и управление памятью. Программы вызывают системные вызовы для взаимодействия с ядром операционной системы, которое управляет аппаратными ресурсами.

1️⃣ Работа с файлами:

➕ open(): открывает файл.

➕ read(): читает данные из файла.

➕ write(): записывает данные в файл.

➕ close(): закрывает файл.

2️⃣ Управление процессами:

➕ fork(): создает новый процесс путем копирования текущего.

➕ exec(): заменяет текущий процесс новым.

➕ wait(): ожидает завершения дочернего процесса.

➕ exit(): завершает процесс.

3️⃣ Работа с памятью:

➕ mmap(): отображает файл или устройство в память.

➕ munmap(): отменяет отображение памяти.

Пример открытия файла, чтения из него и записи в другой файл с использованием системных вызовов:

#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>

int main() {
    int fd_src, fd_dest;
    char buffer[1024];
    ssize_t bytes_read, bytes_written;

    // Открытие исходного файла
    fd_src = open("source.txt", O_RDONLY);
    if (fd_src < 0) {
        perror("open source.txt");
        exit(EXIT_FAILURE);
    }

    // Открытие (или создание) файла назначения
    fd_dest = open("destination.txt", O_WRONLY | O_CREAT, 0644);
    if (fd_dest < 0) {
        perror("open destination.txt");
        close(fd_src);
        exit(EXIT_FAILURE);
    }

    // Чтение и запись данных
    while ((bytes_read = read(fd_src, buffer, sizeof(buffer))) > 0) {
        bytes_written = write(fd_dest, buffer, bytes_read);
        if (bytes_written != bytes_read) {
            perror("write");
            close(fd_src);
            close(fd_dest);
            exit(EXIT_FAILURE);
        }
    }

    // Закрытие файлов
    close(fd_src);
    close(fd_dest);

    return 0;
}

Системные сигналы (signals)

Это механизмы асинхронного уведомления процессов о различных событиях. Сигналы могут быть отправлены процессу ядром операционной системы, другим процессом или самим процессом для уведомления о событиях, таких как ошибки, завершение процессов или пользовательские события.

Примеры:

1️⃣ SIGINT (2): прерывание (например, нажатие Ctrl+C).

2️⃣ SIGTERM (15): запрос на завершение процесса.

3️⃣ SIGKILL (9): принудительное завершение процесса (не может быть перехвачен или игнорирован).

Пример программы, которая обрабатывает сигнал SIGINT (Ctrl+C):

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <unistd.h>

void handle_sigint(int sig) {
    printf("Caught signal %d (SIGINT). Exiting...\n", sig);
    exit(0);
}

int main() {
    // Установка обработчика сигнала SIGINT
    signal(SIGINT, handle_sigint);

    // Бесконечный цикл
    while (1) {
        printf("Running...\n");
        sleep(1);
    }

    return 0;
}

➕ Системные вызовы — это интерфейс между программами и операционной системой, позволяющий выполнять низкоуровневые операции, такие как работа с файлами, управление процессами и памятью.

➕ Системные сигналы — это механизм асинхронного уведомления процессов о различных событиях, таких как ошибки, завершение процессов или пользовательские события.

ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Чем контейнер отличается от пола ?

💬 Спрашивают в 13% собеседований

Kubelet — это один из ключевых компонентов Kubernetes, который отвечает за управление состоянием контейнеров на каждом узле кластера. Действует как агент на каждом узле и выполняет задачи, необходимые для поддержания правильного функционирования контейнеров в соответствии с определенными спецификациями.

Основные функции

1️⃣ Управление подами:

➕ Принимает манифесты Pod и гарантирует, что все описанные контейнеры запущены и работают в соответствии с указанными спецификациями. Он периодически проверяет состояние контейнеров и перезапускает их в случае сбоя.

2️⃣ Мониторинг и отчетность:

➕ Собирает информацию о состоянии подов и контейнеров и отправляет эту информацию в основной компонент управления Kubernetes — API Server. Это позволяет отслеживать состояние всей системы и принимать решения о перераспределении ресурсов при необходимости.

3️⃣ Контроль состояния контейнеров:

➕ Использует cAdvisor для сбора метрик о работе контейнеров, таких как использование CPU, памяти и сетевых ресурсов.

4️⃣ Взаимодействие с контейнер-рантаймом:

➕ Взаимодействует с контейнер-рантаймами, такими как Docker, containerd или CRI-O, через Container Runtime Interface (CRI). Это позволяет ему запускать, останавливать и управлять контейнерами.

5️⃣ Обеспечение конфигурации и секретов:

➕ Обеспечивает контейнеры конфигурацией и секретами, необходимыми для их работы, извлекая эти данные из Kubernetes API Server и монтируя их в контейнеры.

6️⃣ Проби здоровья (Liveness, Readiness):

➕ Выполняет проверки здоровья контейнеров, такие как liveness и readiness probes, чтобы определить, являются ли контейнеры здоровыми и готовы ли они обрабатывать запросы. Если контейнер не проходит проверку, Kubelet может перезапустить его.

🤔 Как он работает

1️⃣ Получение спецификации подов:

➕ Получает спецификации подов от API Server. Это может происходить автоматически через систему управления Kubernetes или через локальные манифесты, находящиеся в определенных директориях.

2️⃣ Запуск контейнеров:

➕ Использует контейнер-рантайм для запуска контейнеров в соответствии с полученными спецификациями.

3️⃣ Обновление состояния:

➕ Регулярно обновляет API Server информацией о текущем состоянии подов и контейнеров на узле.

4️⃣ Выполнение проб здоровья:

➕ Выполняет регулярные проверки здоровья контейнеров и принимает меры в случае обнаружения проблем (например, перезапуск контейнера).

Может быть настроен через командную строку, конфигурационные файлы или параметры, передаваемые при запуске. Пример конфигурационного файла Kubelet:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
address: 0.0.0.0
readOnlyPort: 10255
cgroupDriver: cgroupfs
clusterDNS:
  - 10.96.0.10
clusterDomain: cluster.local
authentication:
  anonymous:
    enabled: false
  webhook:
    enabled: true
  x509:
    clientCAFile: "/etc/kubernetes/pki/ca.crt"
authorization:
  mode: Webhook

Kubelet — это агент, который работает на каждом узле кластера Kubernetes и отвечает за запуск, мониторинг и управление контейнерами в подах. Он взаимодействует с контейнер-рантаймом, выполняет проверки здоровья контейнеров и отправляет информацию о состоянии подов в API Server.

ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых

📌 Что за компонент kubelet ?

💬 Спрашивают в 13% собеседований

Kubelet — это один из ключевых компонентов Kubernetes, который работает на каждом узле кластера и отвечает за управление подами (pods) и контейнерами на этом узле. Он действует как агент, обеспечивая выполнение и поддержание заданного состояния контейнеров.

Основные функции

1️⃣ Управление подами:

➕ Принимает спецификации подов (PodSpecs) от Kubernetes API Server и гарантирует, что все описанные контейнеры запущены и работают в соответствии с указанными спецификациями. Он следит за состоянием подов и перезапускает контейнеры в случае их сбоя.

2️⃣ Мониторинг и отчетность:

➕ Собирает информацию о состоянии подов и контейнеров и отправляет эту информацию в API Server. Это помогает центральной системе управления Kubernetes отслеживать состояние всего кластера и принимать решения о перераспределении ресурсов при необходимости.

3️⃣ Интеграция с контейнер-рантаймом:

➕ Взаимодействует с контейнер-рантаймами (например, Docker, containerd или CRI-O) через интерфейс Container Runtime Interface (CRI). Это позволяет Kubelet запускать, останавливать и управлять контейнерами.

4️⃣ Проби здоровья (Liveness, Readiness):

➕ Выполняет проверки здоровья контейнеров (liveness и readiness probes), чтобы определить, являются ли контейнеры здоровыми и готовы ли они обрабатывать запросы. Если контейнер не проходит проверку, Kubelet может перезапустить его или принять другие меры.

5️⃣ Обеспечение конфигурации и секретов:

➕ Монтирует конфигурации и секреты (config maps и secrets), необходимые для работы контейнеров, извлекая их из Kubernetes API Server и предоставляя их контейнерам.

6️⃣ Логи и метрики:

➕ Собирает логи и метрики о работе контейнеров и узла в целом. Эти данные могут использоваться для мониторинга и диагностики.

🤔 Как он работает

1️⃣ Получение спецификации подов:

➕ Получает спецификации подов от API Server. Это может происходить автоматически через систему управления Kubernetes или через локальные манифесты, находящиеся в определенных директориях на узле.

2️⃣ Запуск и управление контейнерами:

➕ Использует контейнер-рантайм для запуска контейнеров в соответствии с полученными спецификациями.

3️⃣ Мониторинг и обновление состояния:

➕ Регулярно обновляет API Server информацией о текущем состоянии подов и контейнеров на узле. Он также выполняет регулярные проверки состояния контейнеров (probes) и принимает меры в случае обнаружения проблем.

Может быть настроен через конфигурационные файлы или параметры командной строки. Пример конфигурационного файла Kubelet:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
address: 0.0.0.0
readOnlyPort: 10255
cgroupDriver: cgroupfs
clusterDNS:
  - 10.96.0.10
clusterDomain: cluster.local
authentication:
  anonymous:
    enabled: false
  webhook:
    enabled: true
  x509:
    clientCAFile: "/etc/kubernetes/pki/ca.crt"
authorization:
  mode: Webhook

Взаимодействие с другими компонентами Kubernetes

➕ API Server: Взаимодействует с API Server для получения спецификаций подов и отправки отчетов о состоянии.

➕ Scheduler: Scheduler назначает поды на узлы, где работает Kubelet, который затем управляет этими подами.

➕ Controller Manager: Взаимодействует с контроллерами, обеспечивая реализацию различных политик и управляя состоянием подов.

Kubelet — это агент на каждом узле кластера Kubernetes, который управляет подами и контейнерами, следит за их состоянием, взаимодействует с контейнер-рантаймами и обеспечивает выполнение всех необходимых операций для поддержания корректной работы подов.

ТОП ВОПРОСОВ С СОБЕСОВ

🔒 База собесов | 🔒 База тестовых