Системные вызовы Linux, которые должен знать каждый разработчик

[alexgreendev]

Спасибо за комментарий) На Python пишут не только CRUD.

Например, на Python есть реализация supervisor, где по сути всё работает через системные вызовы.

https://github.com/Supervisor/supervisor

В целом, я бы сказал: если ваша программа будет выполняться на Linux (даже если это просто CRUD), вам всё равно полезно знать, как она взаимодействует с операционной системой. На небольших проектах это не так очевидно, но если речь идёт о high load или сферах, где критична производительность, — без этих знаний разработка становится работой вслепую.

[alexgreendev]

Важно не то, что вы пишете и на чём, а какие требования предъявляются к продукту. Как правило, мы не взаимодействуем с системными вызовами напрямую, но понимание того, что происходит под капотом, помогает в разработке и отладке.

Например, добавление строки в конец файла в Python:

with open(path, "a") as file:
    file.write(data + "\n")

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

Возможно, мы знаем, что данные не сразу записываются в файл, а сначала попадают в буфер интерпретатора Python.

Давайте чуть поправим и добавим вызов flush(), который передаст данные в ОС:

with open(path, "a") as file:
    file.write(data + "\n")
    file.flush()

Сделали — и всё равно данные иногда теряются. Скажем, мы знаем, что, кроме передачи данных в ОС, мы ещё можем сказать ей сбросить буфер на диск через системный вызов fsync:

with open(path, "a") as file:
    file.write(data + "\n")
    file.flush()
    os.fsync(file.fileno())

Всё равно данные иногда теряются и не записываются. Копаем дальше. Возможно, у нас на сервере кэш на уровне жёсткого диска или SSD, и даже если ОС вызвала fsync(), диск может принять команду, но отложить запись.

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

Это пример при работе с файлами, но что-то стреляет и в других вещах, смотря что делает ваша программа.

Интересное видео Разработка и эксплуатация ядра Linux в инфраструктуре Яндекса

На больших масштабах, при наличии высоких требований, выстреливает всё. И люди, которые способны что-то с этим сделать, всегда будут высоко цениться.

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

[Peter1010]

Не вижу связи между linux и разработкой. А тем более стстемными вызовами в linux.
Одно дело если пишешь на сях/расте/крестах под линь. Другое если пишешь на питоне сидя под маком.
Я вот в своё время писал утлитку на крестах под линь, мне и то системные вызовы не понадобились. Почти для всего есть нормальная обёртка в std. Или псевдофайлы. ИМХО.
Ps если что питон не мой стек.

[alexgreendev]

Спасибо за комментарий) На Python пишут не только CRUD.

Например, на Python есть реализация supervisor, где по сути всё работает через системные вызовы.

https://github.com/Supervisor/supervisor

В целом, я бы сказал: если ваша программа будет выполняться на Linux (даже если это просто CRUD), вам всё равно полезно знать, как она взаимодействует с операционной системой. На небольших проектах это не так очевидно, но если речь идёт о high load или сферах, где критична производительность, — без этих знаний разработка становится работой вслепую.

[event1]

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

Пока жива ваша стратегия, я спокоен за свои доходы и карьерный рост.

[Noah1]

Наконец-то кто-то, кто понимает как относиться к вайб-кодерам :)

[VBKesha]

Интересно а win32 какой аналог mlock?

[randomsimplenumber]

VirtualLock наверное. Гуглится.

[izibrizi2]

Спасибо за статью! Даже удивительно, что под капотом всё рабоиает на этих кирпичиках, которых и не так уж много. Также можно заметить, что параметры системных вызовов особо то и не менялись на протяжении десятков лет, что говорит о том, что это удачные, продуманные решения, которых именно столько, сколько и должно быть для реализации чего угодно.

Во истину, всё гениальное - просто.

[event1]

Также можно заметить, что параметры системных вызовов особо то и не менялись на протяжении десятков лет

Это не оттого, что они удачные, а из-за диктатуры пролетариата Линуса: WE DONT BREAK THE USERSPACE

[crlf]

Хороший ликбез, но больша́я часть из всего этого — библиотечные функции.

Раз упомянули signal(), то хорошо бы и про atexit() сказать.

Ну и про sysfs аналогично, хотя штука уже более специфичная, чем procfs

[Perekhod_I]

думал сейчас потыкаюсь в примеры и всё такое, а тут просто перечисление, которое я уже забыл (да и не дочитал)
фу и бе)
вот бы гайдик цикл статей со всякими вот этими вызовами и расшифровкой, что да как и главное ЗАЧЕМ и КОГДА использовать)
а так, мкдир сд сд сд .. и хватит с меня)))

[randomsimplenumber]

и главное ЗАЧЕМ и КОГДА использовать)

Никогда и незачем ;) Умные люди не зря придумали POSIX и libc ;) Чтобы стучать прямо в ядро - нужно какие то очень серьезные обоснования

[Apoheliy]

Если говорим про работу именно с файлами, то лучше указать функции fopen/fclose/... (в смысле: лучше, чем open/close/...).

---

Общее впечатление от статьи сильно двоякое:

• с одной стороны, знать такие вещи полезно (общее развитие и т.д.);

• с другой стороны, в продуктовой разработке (основной язык C++14 и позднее) пишешь код так, чтобы этих функций не было даже на горизонте. При любой возможности использовать stl / boost / др. уходишь в библиотеки. Причины такого подхода: стабильность работы, кроссплатформенность.

Сарказм:

Поэтому приведённый список функций очень хорош для прохождения собеседования на позицию разработчика libc.

[semibiotic]

Не путайте функции stdio в libc и сисколы. Для функций fopen/fclose/fread/fwrite нет отдельных сисколов, они работают через соответствующие open/close/read/write с использованием userland-буфера.

Строго говоря, в libc есть и функции open/close/read/write но они представляют собой "обертки" вокруг вызова сискола.

[Apoheliy]

Согласен, я изначально ошибочно подумал, что речь именно про libc (которая при обсуждении python перепрыгивает на glibc). Но с упором именно на syscall становится вообще не понятно, для кого сей труд.

---

Первый заход:

Просто цитата:

Хотя функции malloc(), calloc(), realloc() и free() не являются системными вызовами напрямую, они работают поверх них. Эти функции — часть стандартной библиотеки libc, которая под капотом использует brk() и mmap() для выделения и освобождения памяти.

Второй заход:

Заходим сюда: https://syscalls.mebeim.net/?table=riscv/64/rv64/latest и смотрим на syscall-ы других архитектур, не x86-64. И ... там нет open! (э-э-э, openat2 ?).

---

В общем, очень чудесато.

[yaroslavp]

А что или на чем надо писать, чтобы столкнуться с этим в работе разработчика?

[alexgreendev]

Важно не то, что вы пишете и на чём, а какие требования предъявляются к продукту. Как правило, мы не взаимодействуем с системными вызовами напрямую, но понимание того, что происходит под капотом, помогает в разработке и отладке.

Например, добавление строки в конец файла в Python:

with open(path, "a") as file:
    file.write(data + "\n")

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

Возможно, мы знаем, что данные не сразу записываются в файл, а сначала попадают в буфер интерпретатора Python.

Давайте чуть поправим и добавим вызов flush(), который передаст данные в ОС:

with open(path, "a") as file:
    file.write(data + "\n")
    file.flush()

Сделали — и всё равно данные иногда теряются. Скажем, мы знаем, что, кроме передачи данных в ОС, мы ещё можем сказать ей сбросить буфер на диск через системный вызов fsync:

with open(path, "a") as file:
    file.write(data + "\n")
    file.flush()
    os.fsync(file.fileno())

Всё равно данные иногда теряются и не записываются. Копаем дальше. Возможно, у нас на сервере кэш на уровне жёсткого диска или SSD, и даже если ОС вызвала fsync(), диск может принять команду, но отложить запись.

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

Это пример при работе с файлами, но что-то стреляет и в других вещах, смотря что делает ваша программа.

Интересное видео Разработка и эксплуатация ядра Linux в инфраструктуре Яндекса

На больших масштабах, при наличии высоких требований, выстреливает всё. И люди, которые способны что-то с этим сделать, всегда будут высоко цениться.

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

[vanxant]

brk в современном malloc? А что, ещё остались актуальные 32-битные линупсы?

selectfd в 2025 при наличии libuv и io_uring? Вы серьёзно?

signalfd должен знать каждый разработчик? (видимо, helloworld.asm?)

fork в 2025, особенно в связке с kill, это очень ну такое... Для людей со стальными эцсамыми:) Ну или со слабоумием и отвагой.

В-общем, "крайне низкий технический уровень материала"

[randomsimplenumber]

А что, ещё остались актуальные 32-битные линупсы?

embedded на 32 битах ещё долго будет ездить. Правда там и ядра как правило антикварные