Как работают демоны, процесс Init и как у процессов рождаются потомки — изучаем основы Unix
Авторизуйтесь
Как работают демоны, процесс Init и как у процессов рождаются потомки — изучаем основы Unix
Если вы когда-нибудь работали c Unix-системами, то наверняка слышали термин «демон». В этой статье я хочу объяснить, что это за демоны и как они работают, тем более что их название заставляет думать, что это что-то плохое.
Вообще демон — это фоновый процесс, который не привязан к терминалу, в котором был запущен. Но как они создаются, как они связаны с другими процессами, как они работают? Об этом мы и поговорим, но сперва давайте узнаем, как работает процесс init и как происходит рождение новых процессов.
Как работает процесс Init
Для начала поговорим о процессе init, также известном как PID 1 (поскольку его ID всегда равен 1). Это процесс создаётся сразу при запуске системы, то есть все другие процессы являются его потомками.
Обычно init запускается, когда ядро вызывает конкретный файл, обычно находящийся по адресу /etc/rc или /etc/inittab. Процесс устанавливает путь, проверяет файловую систему, инициализирует серийные порты, задаёт время и т.д. В последнюю очередь он запускает все необходимые фоновые процессы — в виде демонов. Все демоны обычно расположены в папке /etc/init.d/; принято оканчивать имена демонов на букву d (например, httpd, sshd, mysqld и т.п.), поэтому вы можете подумать, что директория названа так по этому же принципу, но на самом деле существует соглашение об именовании папок, содержащих конфигурационные файлы, именем с суффиксом .d. Итак, init запускает демонов, но мы так и не выяснили, как это происходит. Процесс init запускает демонов, создавая свои ответвления для запуска новых процессов.
Как работает разветвление процессов
Единственный способ создать новый процесс в Unix — скопировать существующий. Этот метод, известный как разветвление или форкинг, включает в себя создание копии процесса в виде потомка и системный вызов exec для запуска новой программы. Мы использовали слово «форкинг», поскольку fork — это реальный метод C в стандартной библиотеке Unix, который создаёт новые процессы именно таким образом. Процесс, вызывающий команду fork, считается родительским по отношению к созданному. Процесс-потомок почти полностью совпадает с родительским: отличаются лишь ID, родительские ID и некоторые другие моменты.
В современных дистрибутивах Unix и Linux процессы можно создавать и другим способами (например, при помощи posix_spawn), но большая часть процессов создаётся именно так.
Что такое демоны (daemons) в Linux?
Обновл. 20 Июл 2021 |
В этой статье мы рассмотрим, что такое демоны (и их примеры) в Linux, а также версии происхождения термина «daemon».
Что такое демоны?
Демоны (англ. «daemons») — это работающие в фоновом режиме служебные программы (или процессы), целью которых является мониторинг определенных подсистем ОС и обеспечение её нормальной работы. Например, демон принтера контролирует возможности печати, демон сети контролирует и поддерживает сетевые коммуникации и т.д.
Демоны являются аналогом служб (services) в Windows: они выполняют определенные действия в заранее определенное время или в ответ на определенные события. Существует множество различных демонов, работающих в Linux, каждый из которых создан специально для наблюдения за своей собственной маленькой частью системы. Из-за того, что демоны выполняют основную часть своей работы в фоновом режиме и не находятся под прямым контролем пользователя, бывает трудно определить предназначение того или иного демона.
Так как демон — это процесс, который выполняется в фоновом режиме и обычно находится вне контроля пользователя, то у него нет управляющего терминала.
Процесс — это запущенная программа. В определенный момент времени процесс может либо выполняться, либо ожидать, либо быть «зомби».
В Linux существует три типа процессов:
Процессы переднего плана (или «интерактивные процессы») — это те процессы, которые запускаются пользователем в терминале.
Фоновые процессы (или «автоматические процессы») — это объединенные в список процессы, не подключенные к терминалу; они не ожидают пользовательского ввода данных.
Демоны (англ. «daemons») — это особый тип фоновых процессов, которые запускаются при старте системы и продолжают работать в виде системных служб; они не умирают.
Процессы переднего плана и фоновые процессы не являются демонами, хотя их можно запускать в фоновом режиме и выполнять некоторую работу по мониторингу системы. Для данных типов процессов необходимо участие пользователя, который бы их запускал. В то время как демонам для их запуска пользователь не требуется.
Когда завершается загрузка системы, процесс инициализации системы начинает создавать демоны с помощью метода fork(), устраняя необходимость в терминале (именно это подразумевается под «отсутствием управляющего терминала»).
Я не буду вдаваться в подробности работы метода fork(), отмечу лишь, что, хотя существуют и другие методы, традиционный способ создания дочернего процесса в Linux заключается в создании копии существующего процесса (посредством своеобразного «ответвления»), после чего выполняется системный вызов exec() для запуска другой программы.
Примечание: Термин «fork» не был взят с потолка. Он получил свое название от метода fork() из Стандартной библиотеки языка программирования Си. В языке Си данный метод предназначен для создания новых процессов.
Примеры демонов в Linux
Команда pstree показывает процессы, запущенные в настоящее время в нашей системе, и отображает их в виде древовидной диаграммы. Откройте терминал и введите следующую команду:
Вывод команды pstree — это довольно хорошая иллюстрация того, что происходит с нашей системой. Перед нами появился список всех запущенных процессов, среди которых можно заметить и несколько демонов: cupsd, dbus-daemon, kdekonnectd, packagekitd и некоторые другие.
Вот несколько «популярных» примеров демонов, которые могут работать в вашей системе:
systemd — это системный демон, который (подобно процессу init) является родителем (прямым или косвенным) всех других процессов, и имеет PID=1.
rsyslogd — используется для регистрации системных сообщений. Это более новая версия syslogd, имеющая несколько дополнительных функций.
udisksd — обрабатывает такие операции, как: запрос, монтирование, размонтирование, форматирование или отсоединение устройств хранения данных (жесткие диски, USB-флеш-накопители и пр.).
logind — крошечный демон, который различными способами управляет входами пользователей в систему.
sshd — демон, отвечающий за управление службой SSH. Используется практически на любом сервере, который принимает SSH-соединения.
ftpd — управляет службой FTP. Протокол FTP (сокр. от англ. «File Transfer Protocol») является широко используемым протоколом для передачи файлов между компьютерами, где один компьютер действует как клиент, другой — как сервер.
crond — демон планировщика заданий, зависящих от времени. С его помощью можно выполнять обновление программного обеспечения, проверку системы и пр.
Версии происхождения термина «daemon»
Есть несколько версий происхождения термина «daemon»:
Научная версия: Использование термина «daemon» в вычислительной технике произошло в 1963 году. Project MAC (сокр. от англ. «Project on Mathematics and Computation») — это проект по математике и вычислениям, созданный в Массачусетском технологическом институте. Именно здесь термин «daemon» вошел в обиход для обозначения любого системного процесса, отслеживающего другие задачи и выполняющего предопределенные действия в зависимости от их поведения. Процессы были названы термином «daemons» в честь демона Максвелла.
Примечание: Демон Максвелла — это результат мысленного эксперимента. В 1867 году Джеймс Клерк Максвелл представил себе разумное и изобретательное существо, способное наблюдать и направлять движение отдельных молекул в заданном направлении. Цель мысленного эксперимента состояла в том, чтобы показать возможность противоречия второму закону термодинамики.
Талисман BSD: В операционных системах BSD есть свой талисман — красный чертёнок (этакая игра слов «daemon/demon»). BSD-демона зовут Beastie (Бисти), и его часто можно увидеть с трезубцем, который символизирует системный вызов fork(), активно используемый программами-демонами.
Примечание: «Бисти» по звучанию напоминает BSD (произносится как «Би-Эс-Ди»). При этом beastie является уменьшительной формой от слова beast (зверь).
Теологическая версия: Сторонники данной версии считают, что первоначальной формой произношения слова «daemon» было «daimon», что обозначает (по одной из версий) ангела-хранителя. В то время как «daemon» — помощник, «demon» — злой персонаж из Библии.
Примечание: Также «daemon» иногда произносится как «day-mon» или как рифма к слову «diamond».
Аббревиатура: Некоторые пользователи утверждают, что термин «daemon» является аббревиатурой от «Disk and Execution Monitor».
Поделиться в социальных сетях:
Android – это Linux? Сравнение Android и Linux
Процессы и демоны в Linux
(написано 16 марта 2003 г., опубликовано 13 февраля 2004 г.)
Понятие процесса, наравне с понятием файла, является, безусловно, одним из самых важных понятий любой операционной системы.
Понятие процесса
В самом первом приближении можно считать, что процесс — это программа, выполняющаяся в оперативной памяти компьютера. Но такая формулировка как бы подразумевает, что речь идет только о наборе машинных инструкций, последовательно выполняемых процессором. Фактически же в многозадачных системах понятие процесса является значительно более сложным.
В любой многозадачной системе одновременно может быть запущено много программ, то есть много процессов. Впрочем, слово «одновременно» здесь применено не совсем корректно, поскольку на самом деле в каждый момент времени выполняется только один процесс. Ядро (точнее, особый процесс ядра – планировщик) выделяет каждому процессу небольшой квант времени и по истечении этого кванта передает управление следующему процессу. Кванты времени, выделяемые каждому процессу, так малы, что у пользователя создается иллюзия одновременного выполнения многих процессов. Но, чтобы организовать переключение между процессами по истечении кванта времени, приходится делать как бы «мгновенный снимок» состояния программы и сохранять этот снимок где-то в памяти. Этот «снимок» содержит информацию о состоянии регистров центрального процессора на момент прерывания программы, указание на то, с какой команды возобновить исполнение программы (состояние счетчика команд), содержимое стека и тому подобные данные. Когда процесс снова получает в свое распоряжение ЦП, состояние регистров ЦП и стека восстанавливается из сделанного «снимка» и выполнение программы возобновляется в точности с того места, где она была остановлена. Примерно такие же действия выполняются в тех случаях, когда какому-то процессу необходимо вызвать некоторую системную функцию (вызов ядра).
Кроме организации переключения процессов, ядро в многозадачной системе берет на себя заботу о том, чтобы процессы не мешали друг другу, в частности, чтобы два процесса не пытались одновременно изменять какие-то данные в памяти. Для этого каждому процессу выделяется свое виртуальное адресное пространство. Его размер может даже превышать размер реальной оперативной памяти, что обеспечивается за счет применения страничной организации памяти и механизма свопинга. И физическая и виртуальная память организована в виде страниц – областей памяти фиксированного размера (обычно 4 Кбайта). Если страница долго не используется, ее содержимое переносится в область свопинга на жестком диске, а страница в оперативной памяти предоставляется в распоряжение другого процесса. Подсистема управления памятью поддерживает таблицу соответствия между страницами виртуальной памяти процессов и страницами физической памяти (включая страницы, перенесенные в область свопинга). В современных компьютерных системах эти механизмы реализуются на аппаратном уровне с помощью устройств управления памятью – Memory Management Unit ( MMU ). Если процесс обращается к странице виртуальной памяти, которая размещается в оперативной памяти, операция чтения или записи осуществляется немедленно. Если же страница в оперативной памяти отсутствует, генерируется аппаратное прерывание, в ответ на которое подсистема управления памятью определяет положение сохраненного содержимого страницы в области свопинга, считывает страницу в оперативную память, корректирует таблицу отображения виртуальных адресов в физические, и сообщает процессу о необходимости повторить операцию. Все эти действия невидимы для приложения, которое работает с виртуальной памятью. При этом один процесс не может прочитать что-либо из памяти (или записать в нее) другого процесса без «разрешения» на то со стороны подсистемы управления памятью. При такой организации работы крах одного процесса никак не повлияет на другие выполняющиеся процессы и на всю систему в целом.
Для хранения всех данных, которые необходимо запоминать в целях организации работы процессов, в памяти, выделенной для ядра, создается для каждого процесса особая структура данных типа task_struct (структура задачи, см. [ 1 ]). В ней можно выделить следующие функциональные группы данных:
Подробнее структура task_struct будет рассмотрена ниже, а пока отметим, что максимальное количество процессов, одновременно запущенных в системе, для ядер версии 2.4 определяется как раз объемом структур task_struct и ограничивается только объемом физической памяти. Точнее – структуры процессов не могут занимать больше половины имеющихся страниц памяти [ 1 ].
Как рождаются процессы
Новые процессы создаются в Linux методом «клонирования» какого-то уже существующего процесса, путем вызова системных функций clone(2) и fork(2). Процедура порождения нового процесса выполняется в режиме ядра и происходит следующим образом.
Приведенное описание позволяет сделать два важных вывода:
При чтении описания процедуры создания нового процесса может возникнуть вопрос: а зачем нужно копировать в новый процесс все данные процесса-родителя (например, код программы) и не слишком ли много времени займет копирование. Ответ на этот вопрос заключается в том, что при создании копии процесса его индивидуальные данные физически никуда не копируются. Вместо этого используется метод copy-on-write (копирование при записи): страницы данных обоих процессов особым образом помечаются, и только тогда, когда новый процесс пытается изменить содержимое какой-либо своей страницы, она дублируется.
Демоны и потоки
Среди всех процессов можно выделить несколько особых типов процессов.
Системные процессы являются частью ядра и всегда находятся в оперативной памяти. Такие процессы не имеют соответствующих им программ в виде исполняемых файлов и запускаются особым образом при инициализации ядра системы. Примерами системных процессов являются планировщик процессов, диспетчер свопинга, диспетчер буферного кэша, диспетчер памяти ядра. Такие процессы являются фактически потоками ядра.
Демоны отличаются от обычных процессов только тем, что они работают в неинтерактивном режиме. Если с обычным процессом всегда ассоциирован какой-то терминал или псевдотерминал, через который осуществляется взаимодействие процесса с пользователем, то демон такого терминала не имеет. Демоны обычно используются для выполнения сервисных функций, обслуживания запросов от других процессов, причем не обязательно выполняющихся на данном компьютере. Пользователь не может непосредственно управлять демонами, он может влиять на их работу, только посылая им какие-то задания, например, отправляя документ на печать.
Потоки могут быть реализованы не только внутри ядра, но в пользовательских программах (более подробно об этом вы можете прочитать в статье [ 3 ]). С точки зрения системы потоки отличаются от других процессов только тем, что они выполняются в виртуальном адресном пространстве родительского процесса. В Linux потоки реализованы как процессы, запускаемые со специальным флагом.
Структуры данных процесса
А теперь подробнее рассмотрим, какие данные о процессе хранятся в структуре task_struct.
Идентификационные данные процесса
как кольцевой двухсвязный список, в котором элементы ссылаются друг на друга посредством указателей next_task (предыдущий) и prev_task (последующий).
Контекст процесса
Под контекстом процесса понимают совокупность той информации, которая необходима для организации переключения между процессами, а именно:
Можно сказать, что контекст процесса и его виртуальное адресное пространство образуют как бы «виртуальный компьютер», в котором и исполняется процесс.
Состояния процессов
Каждый запущенный процесс в любой момент времени находится в одном из следующих состояний (которое называют еще статусом процесса)
Другие параметры процесса
Кроме перечисленных выше данных в структуре типа task _ struct хранятся и другие параметры (или атрибуты) процесса. Вот только некоторые из них:
Режимы выполнения процессов
В каждый момент времени процесс находится в одном из двух режимов выполнения: либо в режиме ядра (kernel mode), либо в режиме задачи или пользовательском режиме (user mode). В режиме задачи выполняются инструкции прикладной программы, допустимые на непривилегированном уровне защиты процессора. Когда процессу требуется выполнить какие-то операции на уровне ядра, он делает системный вызов. Выполнение процесса при этом переходит в режим ядра (но от имени процесса, сделавшего системный вызов). Таким образом система защищает собственное адресное пространство от доступа прикладного процесса, который мог бы иначе нарушить целостность структур данных ядра.
Существуют всего три события, при которых выполнение процесса переходит в режим ядра: аппаратные прерывания, особые ситуации и системные вызовы.
Аппаратные прерывания генерируются периферийными устройствами при наступлении определенных событий (например, завершение дисковой операции ввода/вывода или поступления данных на последовательный порт) и имеют асинхронный характер, то есть в рамках процесса невозможно предсказать, в какой момент поступит то или иное прерывание. Обработка таких прерываний не должна блокироваться, поскольку это может вызвать блокирование выполнения независимого процесса.
Особые ситуации вызваны самим процессом и связаны с выполнением каких-то недопустимых инструкций, например, делением на ноль или обращением к несуществующей странице памяти. Обработка таких ситуаций происходит в контексте процесса, при этом может использоваться его адресное пространство, а сам процесс, при необходимости, блокироваться.
Системные вызовы позволяют процессам воспользоваться базовыми услугами ядра. Обращение к ним изменяет режим выполнения процесса и позволяет выполнить привилегированные инструкции ядра. Выполнение системного вызова происходит в режиме ядра, но в контексте процесса, сделавшего вызов.
Во всех этих случаях ядро получает управление и вызывает соответствующую системную процедуру для обработки события. Перед вызовом этой процедуры ядро сохраняет состояние процесса, а после завершения процедуры состояние процесса восстанавливается, и процесс возвращается в исходный режим выполнения.
Средства межпроцессорного взаимодействия
Хотя процессы изолированы друг от друга, они могут обмениваться данными с помощью предоставляемых системой средств межпроцессорного взаимодействия. К таким средствам относятся каналы ( pipes ), именованные каналы ( FIFO ), сообщения ( messages ), разделяемая память ( shared memory ), семафоры ( semaphores ), сигналы ( signals ) и сокеты ( sockets ).
Каналы
Канал обеспечивает однонаправленную передачу данных между двумя процессами, причем только между «родственными» процессами. Например, когда выполняется команда
оба процесса cat и wc создаются процессом shell, и являются родственными. Поэтому каналы не могут использоваться в качестве средства межпроцессорного взаимодействия между независимыми процессами.
Сообщения
Очереди сообщений размещаются в адресном пространстве ядра и являются разделяемым системным ресурсом. Каждая очередь сообщений имеет свой уникальный идентификатор. Процессы могут записывать сообщения в очередь и читать сообщения из очереди. При этом процесс, пославший сообщение в очередь, не обязан ожидать приема этого сообщения другим процессом (или процессами). Он может даже завершиться, а его сообщение будет прочитано позже. Отдельное сообщение содержит:
Процессы могут выбирать из очереди сообщения определенного типа, поэтому можно, например, организовать внеочередной прием срочных сообщений, если рассматривать тип как приоритет сообщений. Кроме того, процесс-отправитель может идентифицировать себя или клиента (например, указав в данных соответствующий PID ), за счет чего может быть организована передача сообщений определенным процессам.
Семафоры
Семафоры, собственно говоря, не являются средством передачи данных. Они выполняют в межпроцессорном взаимодействии вспомогательную роль и служат для организации одновременного использования разделяемых данных несколькими процессами. Если два процесса читают один набор данных и выполнение процессов — последовательное, то это, очевидно, не создает проблем. Если же два процесса пытаются изменить один и тот же набор данных, то результат уже будет зависеть от того, в какой последовательности выполняется считывание и запись этих данных. Для управления такими процессами и вводятся семафоры.
В простейшем случае семафор представляет собой просто счетчик, содержащий 0 или единицу. Значение счетчика, равное 1, означает доступность соответствующего ресурса (например, файла или страницы виртуальной памяти). Если же в счетчике 0, значит, ресурс занят, и операция недопустима.
В общем случае семафор представляет собой не один счетчик, а группу из нескольких счетчиков, причем каждый счетчик может принимать не только значения 0 и 1, а любое значение из определенного интервала. Чаще всего число в семафоре представляет собой количество процессов, которые могут получить доступ к данным. Каждый раз, когда процесс обращается к данным, значение в семафоре, должно быть уменьшено на единицу, и увеличено, когда работа с данными будет прекращена. Семафоры можно использовать и для других целей, например, для счётчика ресурсов. В этом случае число в семафоре — количество свободных ресурсов (например, количество свободных ячеек памяти).
Семафоры должны быть доступны различным процессам, поэтому они размещаются в адресном пространстве ядра и операции с ними осуществляются через интерфейс системных вызовов.
Разделяемая память
Интенсивное использование таких механизмов межпроцессорного взаимодействия, как каналы, FIFO и очереди сообщений, может привести к значительному падению производительности системы. Это связано с тем, что данные, передаваемые с помощью этих механизмов, копируются из буфера передающего процесса в буфер ядра, а затем в буфер принимающего процесса. Механизм разделяемой памяти позволяет избавиться от излишних пересылок данных, предоставляя двум и более процессам доступ к одной и той же области оперативной памяти. Проблема совместного обращения двух процессов к одним и тем же данным решается с помощью семафоров.
Сокеты
Сокеты имеют соответствующий интерфейс доступа в файловой системе (имя, подобное имени файла или, точнее, устройства) и обращение к ним, так же как к обычным файлам, осуществляется через дескрипторы. Однако, в отличие от обычных файлов, сокеты представляют собой виртуальный объект, который существует, пока на него ссылается хотя бы один из процессов.
Сигналы
Сигналы принято обозначать номерами или символическими именами. Все имена начинаются на SIG, но эту приставку иногда опускают: например, сигнал с номером 1 обозначают или как SIGHUP, или просто как HUP. Всего в Linux существует 63 разных сигнала, их перечень можно посмотреть по команде
Если после этой опции указать номер сигнала, то будет выдано его символическое имя, а если указать имя, то получим соответствующий номер.
Существуют несколько причин генерации сигналов или ситуаций, в которых отправляются сигналы.
Когда процесс получает сигнал, то возможен один из двух вариантов развития событий. Если в исполняемой процессом программе для данного сигнала определена подпрограмма обработки, то вызывается эта подпрограмма. В противном случае ядро выполняет от имени процесса действие, определенное по умолчанию для данного сигнала. Вызов подпрограммы обработки называется перехватом сигнала. Когда завершается выполнение подпрограммы обработки, процесс возобновляется с той точки, где был получен сигнал.
Можно заставить процесс игнорировать или блокировать некоторые сигналы. Игнорируемый сигнал просто отбрасывается процессом и не оказывает на него никакого влияния. Блокированный сигнал ставится в очередь на выдачу, но ядро не требует от процесса никаких действий до разблокирования сигнала. После разблокирования сигнала программа его обработки вызывается только один раз, даже если в течение периода блокировки данный сигнал поступал несколько раз.
Следует заметить, что любая обработка сигналов процессом производится только тогда, когда процесс выполняется. То есть процесс не получит сигнал, пока не будет выбран планировщиком и ему не будут предоставлено время центрального процессора.
Файловая система / proc
Каталог /proc выглядит как часть общей каталоговой структуры, но фактически хранится в памяти, а не на диске. Если просмотреть файл /proc/mounts (который перечисляет все смонтированные файловые системы), то вы увидите строку:
/proc /proc proc rw 0 0
/proc контролируется ядром и не имеет соответствующего устройства.
В каталоге / proc содержится множество файлов и подкаталогов. Каждый подкаталог соответствует одному из запущенных в системе процессов и его имя совпадает с идентификатором процесса. В таблице 1 приведены для примера некоторые файлы, содержащиеся в каждом из подкаталогов, соответствующих процессам.
Таблица 1. Некоторые файлы из подкаталога процесса
Этот файл содержит полную командную строку запуска процесса до тех пор, пока процесс не будет «выгружен» или не станет «зомби». В последних двух случаях любое чтение информации из этого файла вернет 0 байтов информации.
Это символьная ссылка на текущий рабочий каталог процесса. Например, для того, чтобы узнать рабочий каталог процесса под номером 20, Вы можете ввести следующее:
cd /proc/20/cwd; /bin/pwd
Этот файл содержит окружение процесса. Записи отделяются друг от друга символами с кодом 0; 0 может также стоять в конце окружения. Чтобы узнать содержимое окружения процесса 1, надо выполнить следующее:
(cat /proc/1/environ; echo) | tr «\000» «\n»
Информация о процессе, представленная в довольно удобном для просмотра виде. Она содержит, в частности, следующие строки:
Имя исполняемого файла процесса в скобках;
Идентификатор родительского процесса.
Идентификатор группы процессов процесса.
Содержание других строк мы пока не рассматриваем.
В корневом каталоге файловой системы / proc содержатся файлы, в которых хранится информация, относящаяся к параметрам ядра (см. табл. 2).
Таблица.2. Некоторые файлы из каталога / proc
Аргументы, переданные ядру Linux при загрузке.
Файл, отображающий физическую память системы.
Счетчики количества прерываний IRQ в архитектуре i386.
Эта строка идентифицирует версию текущего ядра
Управление процессами
Команда ps
Наиболее известной из таких команд является команда ps. Для того чтобы увидеть все процессы, выполняющиеся в данный момент в системе, достаточно запустить команду ps в следующем формате:
Команда top
Рис. 1. Вывод команды top
В верхней части окна отображается астрономическое время, время, прошедшее с момента запуска системы, число пользователей в системе, число запущенных процессов и число процессов, находящихся в разных состояниях, данные об использовании ЦПУ, памяти и свопа. А далее идет таблица, характеризующая отдельные процессы. Число строк, отображаемых в этой таблице, определяется размером окна: сколько строк помещается, столько и выводится.
Содержимое окна обновляется каждые 5 секунд. Список процессов может быть отсортирован по используемому времени ЦПУ (по умолчанию), по использованию памяти, по PID, по времени исполнения. Переключать режимы отображения можно с помощью следующих клавиатурных команд:
С помощью команды можно завершить некоторый процесс (его PID будет запрошен), а с помощью команды можно переопределить значение nice для некоторого процесса.
Команды nice и renice
nice [- adnice] command [args]
Команда, renice служит для изменения значения nice для уже выполняющихся процессов. Суперпользователь может изменить приоритет любого процесса в системе. Другие пользователи могут изменять значение приоритета только для тех процессов, для которых данный пользователь является владельцем. При этом обычный пользователь может только уменьшить значение приоритета. Поэтому процессы с низким приоритетом не могут породить «высокоприоритетных детей».
Управление процессами с помощью сигналов
[user]$ kill [- сигн ] PID [PID..]
где сигн — это номер сигнала, причем если указание сигнала опущено, то посылается сигнал 15 ( SIG TERM — программное завершение процесса). Чаще всего используется сигнал 9 (KILL), с помощью которого суперпользователь может завершить любой процесс. Но сигнал этот очень «грубый», если можно так выразиться, потому что он просто «убивает» процесс, не давая ему времени на корректное сохранение всех обработанных данных. Поэтому в большинстве случаев рекомендуется использовать сигналы TERM или QUIT, которые завершают процесс более «мягко».
Перевод процесса в фоновый режим
Команда nohup
При завершении сессии оболочка посылает всем порожденным ею процессам сигнал «отбой», по которому порожденные ею процессы могут завершиться, что не всегда желательно. Если вы хотите запустить в фоновом режиме программу, которая должна выполняться и после вашего выхода из оболочки, то ее нужно запускать с помощью утилиты nohup: