⌨️ Внутри процесса (thread inside)

#process_management

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

Основные компоненты потока:

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

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

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

Аналогия: продолжая наши офисные инсинуации, где процесс — это клерк, потоки можно представить как его левую и правую руку. Одна рука может делать заметки, а другая параллельно печатать годовой отчет. Эти руки работают независимо, но при этом остаются частью одного и того же клерка. Ничто не мешает одной руке помочь другой: например, левая рука может подать папку с документами правой, передвинуть курсор мыши или выполнить другую вспомогательную задачу. Руки клерка не являются изолированными единицами; они могут взаимодействовать и координировать свои действия. Однако, они также могут мешать друг другу, конкурируя за доступные клерку ресурсы, но об этом как-нибудь в другой раз.

Более подробно читаем тут

👰‍♀️ Так почему они вредные?

#рекрутинг

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

1. Чем больше контактов вы укажете в резюме - тем легче и удобнее будет вас найти. Если вы не хотите, чтобы коллеги с нынешней работы видели, что вы в поиске, то на ХХ есть возможность скрыть резюме от конкретной компании или нескольких.

2. В каждой компании существуют (более или менее) отлаженные процессы, и никто не станет делать исключение ради одного, пусть даже сильного кандидата. По крайней мере, не на начальных этапах. Требуя пропустить эйчар-интервью, вы, в лучшем случае, испортите настроение рекрутеру и попадете в “черный список” компании, а в худшем - в “черный список” побольше, ведь многие эйчары общаются между собой 👾

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

4. Ни для кого не секрет, что айти - очень желанная сфера, поэтому обман со стороны кандидатов встречается часто. Для многих работодателей выключенная камера даже на первичном собеседовании, не говоря уже о техническом - это огромный красный флаг. Если вы хотите подстраховаться на интервью, делайте это с умом.

5. Ходит легенда, что итоговую сумму в оффере можно повышать бесконечно, но это не так. Да, может получиться прыгнуть на 10-20 тысяч выше верха вилки, но, если торговаться во множество этапов и особенно прикрываться несуществующими офферами на значительно большую цифру, чем та, о которой вы говорили изначально, скорее всего, к такому кандидату потеряют интерес.

Всем привет! Благодарю за активность под постом про выбор любимой OS. Победила ubuntu, хотя лично я болел за debian. Мэйнил же я совершенно разные оси, и это, конечно, зависело от текущего место работы. В разные годы это были rhel, centos и debian. Как-нибудь обязательно напишу пост на схожую тематику, а сегодня поздравляем победителя! Как и обещал, его символ повисит в названии канала неделю. 👩‍💻
Upd. Оказалось, что кастомный эмодзи в название канала поставить нельзя, придется выкручиваться.
Upd2. Теперь у пингвина на неделю брендирована кружка.

⌨️ Имя отчество (PID PPID)

#process_management

Здесь все довольно очевидно: PID (Process ID) — это уникальный номер, присваиваемый процессу ядром для контроля его выполнения и предоставления ресурсов. Каждый процесс также имеет атрибут PPID (Parent Process ID), который совпадает с идентификатором PID родительского процесса, то есть процесса, который его инициировал. В системе каждый процесс имеет родительский процесс, который запустил его, ну или усыновил, о чем ниже.

Варианты получения PID и PPID процесса вы найдете в статье по этой ссылке.  Лично мне нравится использовать команду:

pstree -p

(доступна через установку пакета psmisc на вашей OS) для построения дерева процессов, а далее в /proc/<PID> выяснять подробности.
Если знаете какие-то интересные примеры работы с PID и PPID пишите в комментарии ⬇️

⌨️ Как они размножаются? fork()/clone() exec()

#process_management

Итак, мы погружаемся в жизнь процессов всё глубже и глубже, и настало время узнать, откуда берутся новые процессы. Чтобы создать новый процесс, существующий процесс использует системный вызов fork() (технически в Linux используется вызов clone(), но для удобства повествования пока пропустим это). В результате выполнения fork() мы получаем два почти идентичных процесса, с одним важным исключением: системный вызов fork() возвращает два разных значения. В дочернем процессе это значение равно 0 (всегда помним, что согласно Linux-нумерологии 0 обозначает успех), а в родительском процессе возвращается идентификатор PID процесса-потомка.

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

👰‍♀️ Странные вопросы на интервью

#из_первых_рук
#рекрутинг

Профессия системного администратора - что-то среднее между “настоящим” айти и мемами про потных бородатых мужиках в очках, своеобразный Лимб, откуда иногда попадают в девопсы. Из-за расплывчатого круга обязанностей, от “я что-то нажала и все исчезло” до настройки серверов, на собеседованиях на эту позицию частенько присутствует элемент хаоса. Я попросила знакомых админов рассказать об их опыте.

Самый странный вопрос, с которым я столкнулась на первичном интервью:
"Зачем вы работу ищете, почему бы просто замуж не выйти?"

А самый смешной диалог — это вот:

— Вам звонят из офиса, говорят, что ничего не работает. Ваши действия?
— Эээ... у вас в офисе свет есть сейчас?
— Поздравляю, проблема диагностирована!

Был ещё случай, как раз при приёме на нынешнюю работу, спросили на техсобесе про сокеты, я давай про сетевые, а они переглянулись — не, мы про матплаты. А я им на это честно сказала, что мне такие моменты погуглить проще.

Лариса, системный администратор и junior DevOps

⌨️ Отцы и дети (parent - child processes)

#process_management

Отношения родителей и потомков после непосредственно рождения/деления/клонирования, очень кратко, начнем с
наследства/наследственности/наследия, а закончим родительскими обязанностями.

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

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

⌨️ Родился, потерпел и умер: Жизненный цикл процесса.

#process_management

Быть процессом в OS Linux — довольно безрадостное существование. Ты — клон своего родителя, созданный системным вызовом fork(). Затем ты изменяешься под чьи-то нужды с помощью вызова exec(), который полностью заменяет твое содержимое. То, что недавно было идентично родительскому, теперь становится новым и уникальным. Этот вызов дает старт твоей самостоятельной жизни: ты получаешь новую цель от exec(), а также ресурсы, инструменты и настройки, унаследованные от родителя.

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

У тебя будут коллеги, с которыми ты сможешь перекинуться парой слов у кулера, то есть, обмениваться данными и сигналами через механизмы IPC, такие как пайпы, очереди сообщений, разделяемая память и сокеты. Ты сможешь посылать и получать сигналы для уведомления о событиях или запросы на выполнение определенных действий (например, завершение работы). Твой внутренний обработчик сигналов позволит тебе реагировать на изменения в системе или запросы других процессов.

Все хорошее рано или поздно заканчивается, как закончится и твоё существование в качестве процесса. Это случится, когда ты получишь сигнал завершения (например, SIGTERM или SIGKILL) или когда у тебя закончатся задачи. При завершении ты отправишь своему родительскому процессу весточку с просьбой гордиться тобой (сигнал SIGCHLD, сообщающий о твоём состоянии). Он, в свою очередь, подождет, убедится, что ты завершился и освободил ресурсы и, вызвав wait() или waitpid(), с чистой совестью уберет тебя из таблицы процессов. Ты выполнил свой долг, покойся с миром.

👰‍♀️ Лучший запрос самооценки, лучшая обратная связь

#из_первых_рук
#рекрутинг

Продолжаем цикл историй о самых смешных вопросах, которые слышали на интервью сисадмины!

Это был 2013 год, я только переехал в Москву, начал искать работу.
Сходил на около 10 собеседований, все они прошли стандартно для моей должности и были похожи друг на друга.
В итоге собеседовался в небольшую контору которая занималась разработкой ПО для метрологических служб, на должность сисадмина.

Собеседование было очень коротким. Шеф IT отдела был типичным бумером, как сейчас бы сказали. Сначала мне задали некоторые базовые технические вопросы уровня модели OSI и что делать если не открывается сайт или не печатает принтер, и довольно быстро прерывали мой развернутый ответ фразой "понятно, это тоже знаешь".

В итоге удовлетворившись ответами, очередной вопрос прозвучал примерно так: "Ну ты вообще нормально себя оцениваешь, не тупой?"
Я ответил, что в тех сферах где не хватает опыта, проконсультируюсь с коллегами и погуглю. Удовлетворившись ответом, шеф ответил "Вижу что не тупой, когда готов выходить?"
Так получил свою первую работу в Москве, на которой проработал до 2017 года.

Е., системный администратор, сейчас работает в Германии

⌨️ Биография. Вспоминаем и делимся

#process_management

Прошлый пост о процессах нагнал безысходности, но не всё так печально, давайте немного конкретики, попробуем представить более или менее реальный процесс, скажем процесс относящийся к веб-серверу, apache или nginx не столь важно. Попробуем написать краткую биографию этого процесса и хоть в своей сути это будет всё тот-же лайф цикл Born-Life-Death, сосредоточимся в этом посте на второй стадии.

I.Родился (Born or forked) Веб-сервер запускается, и для обработки запросов может создать несколько дочерних процессов или потоков с помощью системного вызова fork(). Наш герой один из них.

II.Жажда служения (Ready to run or runnable): Процесс находится в состоянии готовности к выполнению и ждёт процессорного времени. Он ожидает получения запроса от клиента (например, HTTP-запрос).

III. Бег (Running in user space or running in kernel space): Процесс начинает обрабатывать входящий запрос, возможно передавая его другим компонентам, таким как PHP для динамических страниц. В зависимости от задачи, процесс может работать в пространстве пользователя или ядра (например, выполняя системные вызовы для чтения файлов с диска).

IV. Небег (Blocked, Waiting, Sleeping, in an Interruptable sleep, or in an Uninterruptable sleep): Если запрос требует ввода-вывода (например, чтение данных с диска или из базы данных), процесс переходит в состояние ожидания завершения операции ввода-вывода.

V. Дремлет чутко на работе (The process is sleeping, but it is present in main memory): Когда запрос обработан и сервер ждёт следующий запрос, процесс может оставаться в состоянии ожидания в оперативной памяти, готовый к быстрой активации.

VI. Спит крепко на дальних рубежах (The process is sleeping, but it is present in secondary memory storage): В случае, если сервер сильно нагружен и система вынуждена освобождать память, процесс может быть выгружен в swap, чтобы освободить оперативную память для более активных задач.

VII. Конечная (Terminated): Процесс завершает работу, когда веб-сервер завершает свою сессию или получает команду остановки.

Так вот то что между Родился и Конечная цикл может повториться энное количество раз и вариативно. Скажем Родился -> Жажда -> Бег -> Небег -> Бег -> Дремота -> Жажда -> Бег -> Небег -> Сон -> Конечная.

⌨️ STAT Жди, работай, спи

#process_management

Продолжаем искать в бытие процессов что-то хорошее, в прошлом и позапрошлом посте, выходило честно говоря не очень, но может быть в этом что-то получится. Итак статусы процессов. В этом посте рассмотрим только основные статусы процессов дополнительные флаги вроде (w,<,N, L, s) рассмотрим когда-нибудь ниже. сейчас набираем 'ps aux' и сосредотачиваем своё внимание на колонке STAT:

R — Running (Бегущий)
Это процесс в действии. Он либо выполняется прямо сейчас на одном из процессоров, либо ожидает своей очереди на выполнение. Развивая наши офисные метафоры, такой статус могут иметь белые воротнички активно что-то выстукивающие на клавиатуре, энергично идущие куда-то со своим отчетом или стоящие в очереди к копировальной машине.

S — Sleeping (Спящий)
Процесс ждёт события или ресурса. Возможно, он ожидает ввода от пользователя или данных из сети. Это лёгкий сон, из которого процесс легко пробудить. Представьте коллегу, который дремлет на рабочем месте, но сразу просыпается при звуке входящего письма.

D — Uninterruptible Sleep (Непрерывный сон)
Это глубокий сон, из которого процесс не может быть выведен сигналами. Обычно это происходит при ожидании операций ввода-вывода (записи на диск) на уровне ядра. Подобно человеку, в спрятавшегося от внешнего мира за амбушюры мощных наушников и смотрящего на экран монитора в ожидании завершения загрузки.

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

T — Stopped (Остановлен)
Процесс приостановлен, обычно сигналом SIGSTOP. Он не выполняется, но может быть возобновлён сигналом SIGCONT. Представьте, что вы поставили фильм на паузу — действие замерло, но может продолжиться в любой момент.

I — Idle (Бездействующий)
Процесс не активен и находится в режиме ожидания. Это может касаться как системных процессов, так и пользовательских, которые временно не выполняют никаких операций и ждут определенного события, чтобы продолжить работу. Статус появился в некоторых версиях ядра Linux и относится к процессам, которые не требуют активных ресурсов. Например, это может быть фоновая задача, ожидающая запуска по расписанию, подобно тому, как человек бездействует, ожидая, когда закончится время его обеденного перерыва и придет время начать следующую задачу.

👰‍♀️ О моём опыте собеса на сисадмина (начало)

#изпервыхрук
#рекрутинг
#PersonalExperience

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

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

- Что вы знаете о компьютерных сетях?
- Честно? Ничего... - ответила я после долгого и тягостного молчания.

👰‍♀️ О моём опыте собеса на сисадмина (продолжение)

#изпервыхрук
#рекрутинг
#PersonalExperience

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

Чего я не знала - так это того, какие вопросы, в целом, мне могут задать. Тогда мне попался классный и понимающий интервьюер + удалось выехать на софтах. А чтобы не корить себя за то, что ты облажался с темой, которую знаешь, можно подготовиться к своему первому интервью в айти со вторым автором этого канала, Глебом.

⌨️ Сигналы: 30 способов умереть или быть убитым

#process_management

Сегодняшний пост в формате Linux катехизиса.

1.Что такое сигнал?
Это уведомление посылаемое для оповещения о каком-либо событии

2. Уведомление кому?
Процессу

3. Уведомление от кого?
Технически сигналы исходят всегда от ядра, но другие процессы и пользователи могут инициировать сигналы, которые будут переданы ядром.

4. Что обычно посылает ядро?
Сигналы завершения и управления (умри сразу, умри, когда завершишь свои задачи, остановись, возобновись, управляющий тобой терминал закрылся, что чаще всего тоже значит умри, а если ты демон и тебе не нужен терминал - перезагрузись)
Ошибки (сегментации, арифметической операции, например, деление на ноль, некорректного доступа к памяти, недопустимой машинной инструкции)
Сигналы, касающиеся, взаимодействия с другими процессами (твой потомок умер, ты используешь канал (pipe), не имеющий адресата)
Таймеры и события (ты просил разбудить, пора что-то делать, ты сам знаешь что, если не знаешь что умри)
Прерывание пользователем (например , после нажатия Ctrl+C ядро посылает сигнал SIGINT он же может быть инициирован командой kill -2)

5. Какие сигналы чаще всего инициируются пользователем?
Кроме сигнала SIGINT,через Ctrl+C, который часто получают процессы, не желающие отдавать консоль терминала, это SIGTERM (kill без аргументов или kill -15), который чаще всего описывают как сигнал корректно завершения, но на самом деле предоставляет процессу возможность перехватить этот сигнал (подробнее в следующем посте) и сделать с ним всё что ему вздумается, по умолчанию он всё-равно убьет процесс, но всё-таки.
С сигналом безусловного завершения процесса SIGKILL (вызывается командой kill -9) всё проще, его невозможно перехватить, заблокировать или сообщить ему другой смысл; он просто завершает процесс.
Вводя команду ‘nginx -s reload’ вы посылаете процессу nginx SIGHUP (kill -1) вынуждая его перечитать собственную конфигурацию. А после закрытия управляющего терминала, такую команду получает связанный с терминалом процесс (и умирает).

6. Какие сигналы используются для таймеров?
Таймеры в Linux используют сигнал SIGALRM. Когда истекает время таймера, ядро посылает этот сигнал процессу. Этот сигнал часто используется для реализации ограничений по времени для различных операций, таких как ожидание ввода от пользователя или выполнения длительных задач.

7. Что происходит, если процесс не может обработать сигнал?
Если процесс не может обработать сигнал или не настроил его обработку, ядро выполнит действие по умолчанию для данного сигнала. Например, для SIGTERM или SIGHUP процесс завершится. Для SIGKILL и SIGSTOP нет возможности установить обработчик, и они всегда приводят к завершению или остановке процесса.

8. Целых 30?
Может быть даже больше, все посмотреть и почитать их сверхкраткие описания можно тут это для OS Debian и на русском.

Небольшое техническое сообщение

Статьи в канал пишут два человека. Подписывать посты, пользуясь стандартным инструментарием ТГ мы не хотим, поэтому принято стратегическое решение подписывать посты эмодзи.
👰‍♀️ - посты Кати
🧙‍♂️ или 👨‍💻 или👨‍💻или ⌨️ - посты Глеба
Предлагаю выбрать эмодзи для Глеба ниже. Он будет стараться помечать свои посты так, пока ему не нарисуют что-то более подходящее.