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

Прежде всего, процесс может клонировать себя (это действие называется fork). Ядро выделяет пространство в памяти (точно такое же как и для исходного процесса), и новый процесс его занимает. Единственная разница между этими двумя процессами - их pid. Новый процесс обычно зовется дочерним процессом, а оригинальный (pid которого не изменился) - родительским процессом.

Иногда, дочерний процесс продолжает жить своей собственной жизнью независимо от родителя, со своими собственными данными, скопированными у родительского процесса. Во многих случаях, однако, этот дочерний процесс выполняется другой программой. За некоторыми исключениями, его память просто замещается новой программой, и начинается выполнение новой программы. Это механизм, используемый init процессом (с процессом #1) для запуска дополнительных сервисов и выполнения последовательности всей загрузки. В определенный момент один процесс из потомства init запускает графический интерфейс для пользователей и входа в систему (подробно эта последовательность событий описана в Раздел 9.1, «Загрузка системы»).

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

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

Несколько таких демонов подробно описаны в Глава 9, Сервисы Unix.

Изолированный процесс, демон или интерактивное приложение, редко бывает полезным сам по себе, поэтому существует несколько методов, позволяющих отдельным процессам взаимодействовать друг с другом для обмена данными или управления друг другом. Общий термин обозначающий их - межпроцессное взаимодействие, или коротко IPC (от англ. Inter-Process Communication).

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

В случае, когда вы не хотите сохранять данные на диск, вы можете использовать канал, который является простым объектом с двумя концами; байты, написанные в одном конце, доступны для чтения на другом. Это простой и удобный способ межпроцессного взаимодействия, т.к. концы управляются отдельными процессами. Каналы могут быть разделены на две категории: именованные и анонимные. Именованный канал представляет собой запись в файловой системе (хотя передаваемые данные не хранятся там), так оба процесса могут самостоятельно открыть его, если расположение именованного канала заранее известно. В тех случаях, когда взаимодействующие процессы связаны между собой (например, родительский и дочерний процессы), родительский процесс также может создать анонимный канал перед тем как "форкнется", а дочерний процесс наследует его. Таким образом оба процесса могут обмениваться данными через канал без необходимости задействовать файловую систему.

Однако, межпроцессное взаимодействие используется не только для передачи данных. Во многих ситуациях, единственная информация, которую нужно передать: это управляющие сообщения такие как “приостановить выполнения” или “возобновить выполнение”. Unix (и Linux) предоставляют механизм, известный как сигналы, через которые процесс может легко отправлять другому процессу специальные сигналы, выбранные из определенного списка. Необходимо лишь знать pid целевого процесса.

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

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

Это нормально для Unix-подобных систем: использовать все эти механизмы в разной степени.

Библиотеки функций играют решающую роль в Unix-подобных операционных системах. Они не являются программами (они не могут быть выполнены самостоятельно), а представляют собой фрагменты кода, которые могут быть использованы обычными программами. Среди общих библиотек вы можете найти:

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

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