IgorKa — Информационный ресурс
Немного обо всем и все о немногом, или практический опыт системного администратора.
| Пн | Вт | Ср | Чт | Пт | Сб | Вс |
|---|---|---|---|---|---|---|
| « Окт | Дек » | |||||
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | ||||||
Лекция №13 Сигналы в Linux
11 ноября 2009, 11:36
Прошлая лекция была посвящена процессам в Linux. Сегодня мы поговорим о взаимодействии процессом между собой, а также о том как мы можем воздействовать на процессы. Сначала посмотрим как процессы могу взаимодействовать между собой. Мы уже писали в командной строке конструкции подобные этой: less /etc/group | grep user . В этом примере процесс less взаимодействует с процессом grep посредством механизма, который называется неименований канал или пайп (pipe — канал). Мы не будем вдаваться в подробности, просто запомните, что посредством символа |, который можно в данном случае называть “пайпом” информация (результат выполнения) процесса less идет на вход другого процесса — grep. Таким образом один процесс передал информацию другому процессу.
Еще один способ общения процессов — это именованные каналы. Изучение именованный каналов не входит в этот курс, но на практическом примере расскажу, что это. Именованный канал можно создать командой mkfifo:
igor@adm-ubuntu:~/linux$ mkfifo my_pipe
igor@adm-ubuntu:~/linux$ ls -l | grep my_pipe
prw-r–r– 1 igor igor 0 2009-11-09 17:59 my_pipe
Теперь в одной консоли выполните команду:
igor@adm-ubuntu:~/linux$ echo Hello > my_pipe
Как видите команда не завершает свою работу, а ждет. Зарегистрируйтесь еще в одной консоли и выполните команду:
igor@adm-ubuntu:~/linux$ cat my_pipe
Hello
Если вернуться на первую консоль, то вы увидите, что команда echo завершила свою работу. Таким образом через именованный канал my_pipe команда (процесс) echo передала информацию (слово Hello) процессу cat, который ее принял и вывел на экран.
Давайте теперь рассмотрим основной способ “общения” процессов — сигналы. Один процесс при помощи ядра может передать другому процессу специальное числовое значение сигнала. Процесс вызывает функцию передачи сигнала и передает необходимую информацию (код сигнала, PID процесса) ядру. Ядро передает сигнал процессу получателю и отслеживает как этот сигнал обрабатывается. Сигналы обозначаются цифрами или мнемоническими обозначениями. Перечень сигналов можно вывести командой kill -l.
Мнемонические имена которые вы видите (SIGTERM, SIGINT, SIGKILL) начинаются с приставки SIG. Имена в этом виде используются в языках программирования таких как С. В интерпретаторе bash используются или числа или мнемонические имена, но без приставки SIG — TERM, INT, KILL.
Часть сигналов (INT, TERM) являются перехватываемыми. Это означает, что процесс при получении такого сигнала должен перейти на специальную подпрограмму, которая занимается обработкой сигнала. Если подпрограммы обработки нет (а ее написанием занимаются разработчики программы, которая выполняется в контексте процесса), то управление передается ядру, которое выполняет действия по умолчанию, описанные для каждого сигнала.
Часть сигналов являются такими которые можно заблокировать. Например, один процесс посылает сигнал TERM другому процессу, а он в свою очередь не закончил операции ввода/вывода. В таком случае второй процесс может заблокировать полученный сигнал (опять таки в обработчике сигнала) до момента выполнения необходимой операции ввода/вывода. Сигнал TERM — это сигнал корректного завершения работы процесса. Обработчик этого сигнала, должен выполнить все необходимые действия для правильного завершения работы.
И есть третья группа сигналов, которые не блокируются и для которых не нужны обработчики. Примером такого сигнала является сигнал KILL. Этот сигнал уничтожает процесс, так как для него нет обработчиков в процессах, то он будет обрабатываться ядром по умолчанию и так как он не блокируемый, то действия будут выполнятся немедленно.
Пока мы говорили о том как процессы “общаются” между собой с помощью сигналов. Но мы (пользователи) также можем посылать сигналы процессам. Например, комбинация клавиш Ctrl+C посылает процессу сигнал INT, который прерывает выполнение процесса. Если вы наберете в терминале команду sleep 100, то команда не вернет управление терминалу пока не завершится. Прервать выполнение этой команды можно нажав комбинацию клавиш Ctrl+C.
В чем же отличия между похожими сигналами INT, TERM, KILL (а также QUIT и HUP)? Несмотря на похожесть отличия есть:
Сигнал KILL не блокируется и не перехватывается и ведет к немедленному завершению процесса.
Сигнал INT в отличии от KILL является блокируемым сигналом и перехватываемым.
Сигнал TERM также является перехватываемым и блокируемым и предназначен для корректного (предпочтительного) завершения работы процесса.
Сигнал QUIT — похож на TERM, но позволяет сохранить дамп памяти.
Сигнал HUP — сейчас этот сигнал чаще всего интерпретируется процессами как “прочесть конфигурационные файлы”.
Рассмотрим два сигнала: STOP и CONT. Сигнал STOP останавливает процесс, то есть процесс переходит в состояние “остановленный“. В таком состоянии процесс будет до тех пор пока снова не получит сигнал. Если будет получен сигнал CONT, то процесс возобновит свою работу с того момента как он был остановлен. Практический пример:
Наберите в терминале команду sleep 1000 &.
Затем проверьте, что процесс находится в состоянии ожидания, о чем нам говорит буква S в столбце STAT:
igor@ubuntu:~$ ps x | grep [s]leep
PID TTY STAT TIME COMMAND
6301 pts/1 S 0:00 sleep 1000
Теперь пошлем процессу сигнал STOP. Для этого используем команду kill (kill -название процесса PID процесса):
igor@ubuntu:~$ kill -STOP 6301
[1]+ Stopped sleep 1000
Проверяем статус процесса:
igor@ubuntu:~$ ps x | grep [s]leep
PID TTY STAT TIME COMMAND
6301 pts/1 T 0:00 sleep 1000
Видим, что процесс действительно находится в состоянии “остановленный” (символ T в столбце STAT).
Теперь отправим процессу сигнал продолжения работы (CONT) и проверим состояние:
igor@ubuntu:~$ kill -CONT 6301
igor@ubuntu:~$ ps x | grep [s]leep
PID TTY STAT TIME COMMAND
6301 pts/1 S 0:00 sleep 1000
Если необходимо корректно завершить процесс, то необходимо послать ему сигнал TERM:
igor@ubuntu:~$ kill -TERM 6301
igor@ubuntu:~$ ps x | grep [s]leep
[1]+ Terminated sleep 1000
igor@ubuntu:~$ ps x | grep [s]leep
Если сразу же после посылки сигнала TERM выполнить команду ps x | grep [s]leep, то можно успеть увидеть сообщение о том, что процесс завершает работу, в при следующей попытке вывести информацию о нашем процессе sleep мы уже ничего не увидим — процесс прекратил существование. Команда kill без указания сигнала, по умолчанию передает процессу именно сигнал TERM. Поэтому можно было написать просто kill 6301.
Если необходимо срочно завершить процесс, или процесс не завершается по сигналу TERM, то тогда необходимо послать процессу сигнал KILL:
igor@ubuntu:~$ sleep 1000 &
[1] 6348
igor@ubuntu:~$ kill -KILL 6348
igor@ubuntu:~$ ps x | grep [s]leep
[1]+ Killed sleep 1000
Если необходимо послать один и тот же сигнал нескольким процессам, то можно перечислить их через пробел: kill -TERM 2345 3456 4567.
Команда kill довольно ограничена в возможностях и не позволяет выполнять более сложные действия. Поэтому рассмотрим еще одну команду — killall. Основное преимущество этой команды, то что она умеет посылать сигналы всем процессам с одинаковым именем или всем процессам одного пользователя. Запустите несколько раз подряд команду sleep 1000 &:
igor@ubuntu:~$ ps x | grep [s]leep
6460 pts/1 S 0:00 sleep 1000
6461 pts/1 S 0:00 sleep 1000
6462 pts/1 S 0:00 sleep 1000
6463 pts/1 S 0:00 sleep 1000
6464 pts/1 S 0:00 sleep 1000
6465 pts/1 S 0:00 sleep 1000
6466 pts/1 S 0:00 sleep 1000
Теперь, чтобы завершить все процессы с именем sleep, достаточно набрать команду killall sleep:
igor@ubuntu:~$ killall sleep
[1] Terminated sleep 1000
[2] Terminated sleep 1000
[3] Terminated sleep 1000
[4] Terminated sleep 1000
[6]- Terminated sleep 1000
[7]+ Terminated sleep 1000
[5]+ Terminated sleep 1000
Выполните команду sleep 1000 & еще несколько раз, а затем зарегистрируйтесь в другой консоли от имени другого пользователя (например, test) и также от его имени выполните команду sleep 1000 &. Теперь вернитесь в свою консоль и просмотрите процессы sleep всех пользователей:
igor@ubuntu:~$ ps aux | grep [s]leep
igor 6540 0.0 0.0 2952 628 pts/1 S 22:30 0:00 sleep 1000
igor 6541 0.0 0.0 2952 632 pts/1 S 22:30 0:00 sleep 1000
igor 6542 0.0 0.0 2952 628 pts/1 S 22:30 0:00 sleep 1000
test 6543 0.0 0.0 2952 632 pts/3 S 22:30 0:00 sleep 1000
test 6544 0.0 0.0 2952 628 pts/3 S 22:30 0:00 sleep 1000
test 6545 0.0 0.0 2952 628 pts/3 S 22:30 0:00 sleep 1000
test 6546 0.0 0.0 2952 632 pts/3 S 22:30 0:00 sleep 1000
Теперь для того, чтобы удалить процессы только пользователя test необходимо выполнить (от имени пользователя root) команду killall -u test:
igor@ubuntu:~$ sudo killall -u test
igor@ubuntu:~$ ps aux | grep [s]leep
igor 6540 0.0 0.0 2952 628 pts/1 S 22:30 0:00 sleep 1000
igor 6541 0.0 0.0 2952 632 pts/1 S 22:30 0:00 sleep 1000
igor 6542 0.0 0.0 2952 628 pts/1 S 22:30 0:00 sleep 1000
Команда выше удалит не только процессы sleep, но вообще все процессы пользователя test. Если необходимо удалить конкретно процессы sleep, то тогда команду нужно было записать так: killall -u test sleep.
Если запустить команду killall c ключом -i, то перед посылкой сигнала будет запрашиваться подтверждение:
igor@ubuntu:~$ killall -i sleep
Прибить sleep(6540) ? (y/N) n
Прибить sleep(6541) ? (y/N) n
Прибить sleep(6542) ? (y/N) n
Следующая лекция будет завершающей по теме процессов и сигналов Linux. Мы поговорим о заданиях (jobs), командах jobs, fg, bg, strong>nohup, и top.
Сигналы
Предположим, что есть две программы. Одна программа должна передать другой большое количество данных. Передача данных будет происходить через файл типа FIFO. То есть одна программа открывает этот файл на запись и передает данные, другая должна открыть этот файл на чтение и получить данные. Проблема заключается в том, что вторая программа должна узнать, что пришло время открывать файл и читать данные.
Чтобы уведомить вторую программу, первая может послать ей сигнал. Сигнал — это число. Его можно представить в виде программного прерывания.
Мне сразу вспоминается очень известный анекдот про Петьку и Василия Ивановича:
Летят Петька и Василий Иванович на самолете.
Реакция программы на получаемый сигнал зависит от программиста, написавшего эту программу. Программист, написавший вторую программу из нашего примера, в документации к ней укажет, что если программе послать сигнал, например 10, то она откроет указанный FIFO-файл на чтение.
Если говорить более точно, то реакция программы на получаемый сигнал зависит от системы. Но программисты могут переопределить стандартную реакцию.
Чтобы получить список всех сигналов, которые поддерживаются системой, используйте программу kill с параметром –l:
$ kill -l 1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ 26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR 31) SIGSYS 35) SIGRTMIN 36) SIGRTMIN+1 37) SIGRTMIN+2 38) SIGRTMIN+3 39) SIGRTMIN+4 40) SIGRTMIN+5 41) SIGRTMIN+6 42) SIGRTMIN+7 43) SIGRTMIN+8 44) SIGRTMIN+9 45) SIGRTMIN+10 46) SIGRTMIN+11 47) SIGRTMIN+12 48) SIGRTMIN+13 49) SIGRTMIN+14 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7 58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2 63) SIGRTMAX-1 $
Количество поддерживаемых сигналов зависит от типа системы. Даже в разных версиях Linux (имеются в виду версии ядра) может применяться разное количество сигналов. Но их никогда не бывает меньше 32.
Каждый сигнал имеет номер, полное и краткое имена. Например, сигнал 1 имеет полное имя SIGHUP, краткое имя сигнала — HUP.
| Внимание! | В различных типах UNIX номера сигналов могут не совпадать, поэтому, если вы регулярно работаете в разных UNIX, используйте имена, а не номера сигналов. Тогда вы никогда не ошибетесь при указании сигнала. |
Как уже говорилось выше, у программ есть стандартная реакция на получаемые сигналы. Давайте рассмотрим некоторые из них.
| Сигнал | Описание сигнала | Стандартная реакция программы |
| HUP(1) | Сброс. | Завершение работы. Для демонов — перечитать конфигурационный файл. |
| INT(2) | Посылается, если нажата комбинация клавиш Ctrl+C. | Завершение работы. |
| KILL(9) | Безусловное завершение работы программы. | Завершение работы. |
| TERM(15) | Завершение работы программы. | Завершение работы. |
| CONT(18) | Продолжение выполнения приостановленной программы. | Игнорируется. |
| STOP(19) | Приостановление выполнения программы. | Приостановление выполнения программы. |
Сигнал TERM(15) посылается программе, если необходимо завершить ее выполнение. При получении этого сигнала программа выполняет все необходимые действия для завершения работы: закрывает соединения, открытые файлы, сохраняет данные. В общем, корректно завершает свою работу.
Теперь представьте, что каким-то чудом (это действительно будет чудо, при условии, что вы правильно управляете Linux-машиной) хакер поставил и запустил программу, которая, например, форматирует ваш диск с проверкой на сбойные блоки в режиме записи (очень длительная процедура). Вы обнаружили эту программу и решили завершить ее работу. При посылке 15-го сигнала программа не завершит работу, т.к. программист ее написавший поставил свой собственный обработчик сигналов. Он, конечно, предусмотрел возможность получения 15-го сигнала, и в ответ на сигнал программа либо просто продолжает свою работу, либо начинает форматировать диск в ускоренном режиме.
В системе предусмотрены сигналы, которые не могут быть переопределены программистом. И это в первую очередь сигнал KILL(9). Но этим сигналом следует пользоваться с особой осторожностью.
| Внимание! | Посылка сигнала KILL программе аналогична нажатию на кнопку reset, то есть программа завершает работу не корректно! Применять сигнал надо только в том случае, если программа не реагирует на посылку сигнала TERM. |
Еще один сигнал, который обрабатывает система, а не программа, — STOP(19). При посылке этого сигнала программе ее выполнение будет приостановлено. Оперативная память, выделенная под программу, не освобождается, просто программа не будет ставится в очередь на выполнение процессору. Продолжить выполнение программы можно послав ей сигнал CONT(18).
Сигнал INT(2) посылается программе, если нажата комбинация клавиш Ctrl+C.
Сигнал HUP(1) посылается программе, если произошло отключение терминала. Действительно, в далекие времена рабочие места подключались через модемы, и при отключении связи программам посылался сигнал HUP. Поскольку ресурсы систем тогда были очень дорогими, система отключала все программы, подключенные к этому терминалу. На данный момент система ведет себя таким же образом, и при завершении работы логин шелл, всем программам посылается HUP, что бы они завершили свою работу. Но есть группа программ, которые в принципе не могут получить HUP — это процессы демоны. В случае демонов сигнал HUP используется по другому. Его посылают для того, что бы программа перечитала свои конфигурационные файлы.
8.4.4. Сигналы и команда kill
Сигналы — это средство, с помощью которого процессам можно передать сообщения о некоторых событиях в системе. Сами процессы тоже могут генерировать сигналы, с помощью которых они передают определенные сообщения ядру и другим процессам. С помощью сигналов можно осуществлять такие акции управления процессами, как приостановка процесса, запуск приостановленного процесса, завершение работы процесса. Всего в Linux существует 63 разных сигнала, их перечень можно посмотреть по команде
Сигналы принято обозначать номерами или символическими именами. Все имена начинаются на SIG, но эту приставку иногда опускают: например, сигнал с номером 1 обозначают или как SIGHUP, или просто как HUP.
Когда процесс получает сигнал, то возможен один из двух вариантов развития событий. Если для данного сигнала определена подпрограмма обработки, то вызывается эта подпрограмма. В противном случае ядро выполняет от имени процесса действие, определенное по умолчанию для данного сигнала. Вызов подпрограммы обработки называется перехватом сигнала. Когда завершается выполнение подпрограммы обработки, процесс возобновляется с той точки, где был получен сигнал.
Можно заставить процесс игнорировать или блокировать некоторые сигналы. Игнорируемый сигнал просто отбрасывается процессом и не оказывает на него никакого влияния. Блокированный сигнал ставится в очередь на выдачу, но ядро не требует от процесса никаких действий до разблокирования сигнала. После разблокирования сигнала программа его обработки вызывается только один раз, даже если в течение периода блокировки данный сигнал поступал несколько раз.
В табл. 8.1. приведены некоторые из часто встречающихся сигналов.
Таблица 8.1. Сигналы
N Имя Описание Можно перехватывать Можно блокировать Комбинация клавиш 1 HUP Hangup. Отбой Да Да 2 INT Interrupt. В случае выполнения простых команд вызывает прекращение выполнения, в интерактивных программах — прекращение активного процесса Да Да ‹Ctrl›+‹C› или ‹Del› 3 QUIT Как правило, сильнее сигнала Interrupt Да Да ‹Ctrl›+‹› 4 ILL Illegal Instruction. Центральный процессор столкнулся с незнакомой командой (в большинстве случаев это означает, что допущена программная ошибка). Сигнал отправляется программе, в которой возникла проблема Да Да 8 FPE Floating Point Exception. Вычислительная ошибка, например, деление на ноль Да Да 9 KILL Всегда прекращает выполнение процесса Нет Нет 11 SEGV Segmentation Violation. Доступ к недозволенной области памяти Да Да 13 PIPE Была предпринята попытка передачи данных с помощью конвейера или очереди FIFO, однако не существует процесса, способного принять эти данные Да Да 15 TERM Software Termination. Требование закончить процесс (программное завершение) Да Да 17 CHLD Изменение статуса порожденного процесса Да Да 18 CONT Продолжение выполнения приостановленного процесса Да Да 19 STOP Приостановка выполнения процесса Нет Нет 20 TSTR Сигнал останова, генерируемый клавиатурой. Переводит процесс в фоновый режим Да Да ‹Ctrl›+‹Z›
Как видите, некоторые сигналы можно сгенерировать с помощью определенных комбинаций клавиш. Но такие комбинации существуют не для всех сигналов. Зато имеется команда kill, которая позволяет послать заданному процессу любой сигнал. Как уже было сказано, с помощью этой команды можно получить список всех возможных сигналов, если указать опцию -l. Если после этой опции указать номер сигнала, то будет выдано его символическое имя, а если указать имя, то получим соответствующий номер.
Для посылки сигнала процессу (или группе процессов) можно воспользоваться командой kill в следующем формате:
[user]$ kill [-сигн] PID [PID..]
где сигн — это номер сигнала, причем если указание сигнала опущено, то посылается сигнал 15 (TERM — программное завершение процесса). Чаще всего используется сигнал 9 (KILL), с помощью которого суперпользователь может завершить любой процесс. Но сигнал этот очень «грубый», если можно так выразиться, поэтому его использование может привести к нарушению порядка в системе. Поэтому в большинстве случаев рекомендуется использовать сигналы TERM или QUIT, которые завершают процесс более «мягко».
Естественно, что наиболее часто команду kill вынужден применять суперпользователь. Он должен использовать ее для уничтожения процессов-зомби, зависших процессов (они показываются в листинге команды ps как ‹exiting›), процессов, которые занимают слишком много процессорного времени или слишком большой объем памяти и т. д. Особый случай — процессы, запущенные злоумышленником. Но обсуждение этого особого случая выходит за рамки данной книги.
Читайте также
Сигналы
Сигналы Сигналы являются способом передачи от одного процесса другому или от ядра операционной системы какому-либо процессу уведомления о возникновении определенного события. Сигналы можно рассматривать как простейшую форму межпроцессного взаимодействия. В то же
Сигналы
Сигналы В некотором смысле сигналы обеспечивают простейшую форму межпроцессного взаимодействия, позволяя уведомлять процесс или группу процессов о наступлении некоторого события. Мы уже рассмотрели в предыдущих главах сигналы с точки зрения пользователя и
7.2 СИГНАЛЫ
7.2 СИГНАЛЫ Сигналы сообщают процессам о возникновении асинхронных событий. Посылка сигналов производится процессами — друг другу, с помощью функции kill, — или ядром. В версии V (вторая редакция) системы UNIX существуют 19 различных сигналов, которые можно классифицировать
5.8.2. Сигналы
5.8.2. Сигналы Демон syslogd реагирует на следующие сигналы: SYGTERM, SIGINT, SIGQUIT, SIGHUP, SIGUSR1, SIGCHLD. Реакция демона на сигналы описана в табл. 5.8.Реакция демона на сигналы Таблица 5.8 Сигнал Реакция SIGTERM Завершает работу демона SIGINT, SIGQUIT Завершает работу демона, если выключена отладка
3.3.2. Сигналы
3.3.2. Сигналы Механизм сигналов — это средство, позволяющее сообщать процессам о некоторых событиях в системе, а процессу-получателю — должным образом на эти сообщения реагировать. Послать сигнал может сам процесс (например, при попытке деления на ноль), ядро (при сбое
27.3.10. Сигналы и сокеты
27.3.10. Сигналы и сокеты С сокетами связаны три сигнала:? SIGIO — сокет готов к вводу/выводу. Сигнал посылается процессу, который связан с сокетом;? SIGURG — сокет получил экспресс-данные (мы их использовать не будем, поэтому особо останавливаться на них нет смысла);? SIGPIPE — запись
Завершение процесса с помощью команды KILL
Завершение процесса с помощью команды KILL В SQL Server администратор может удалить процесс, например пользовательское подключение или блокировку базы данных, с помощью команды KILL. Обычно эта команда применяется для чрезвычайного прекращения пользовательского сеанса,
7.2.6.2. Сигналы
7.2.6.2. Сигналы Самый простой и грубый способ сообщения между двумя процессами на одной машине заключается в том, что один из них отправляет другому какой-либо сигнал (signal). Сигналы в операционной системе Unix представляют собой форму программного прерывания. Каждый сигнал
7.2.6.2. Сигналы
7.2.6.2. Сигналы Самый простой и грубый способ сообщения между двумя процессами на одной машине заключается в том, что один из них отправляет другому какой-либо сигнал (signal). Сигналы в операционной системе Unix представляют собой форму программного прерывания. Каждый сигнал
3.3. Сигналы
3.3. Сигналы Сигналы — это механизм связи между процессами в Linux. Данная тема очень обширна, поэтому здесь мы рассмотрим лишь наиболее важные сигналы и методики управления процессами.Сигнал представляет собой специальное сообщение, посылаемое процессу. Сигналы являются
Пример 11-23. Сценарий, завершающий себя сам с помощью команды kill
Пример 11-23. Сценарий, завершающий себя сам с помощью команды kill #!/bin/bash# self-destruct.shkill $$ # Сценарий завершает себя сам. # Надеюсь вы еще не забыли, что «$$» — это PID сценария.echo «Эта строка никогда не будет выведена.»# Вместо него на stdout будет выведено сообщение «Terminated».exit 0# Какой
26.2. Сигналы
26.2. Сигналы Сигнал относится к типу сообщений, которые пересылаются из системы для информирования команды или сценария о совершении какого?либо события. Обычно речь идет об ошибках, связанных с функционированием памяти, о проблемах с доступом к информации или об
Глава 10. Процессы
Как мы уже упоминали ранее, некий процесс является исполняемой программой. Данная программа может собираться из кода языка программирования, причём некоторый исполняемый код, создаваемый после компиляции некоторой исходной программы, написанной на языке программирования верхнего уровня, таком как C++, либо некий код интерпретатора, написанный на LISP, JavaScript, Perl, интерпретируемом C (CINT) или в какой- то оболочке UNIX. Сама система UNIX создаёт некий процесс всякий раз, когда вы исполняете какую- либо внешнюю команду, причём такой процесс удаляется из этой системы по окончанию её исполнения. Мы применяем взаимозаменяемо термины программа и команда .
Создание процесса и его прекращение являются исключительными механизмами, применяемыми в системах Unix для исполнения внешних команд. В некоторой типичной системе с разделением времени, такой как UNIX, которые делают возможным множеству пользователей одновременно использовать некую вычислительную систему и исполнять множество процессов, причём от сотен до тысяч процессов создаётся и прекращается ежедневно. Помните, что собственно в компьютере исполняет процессы ЦПУ и что обычная система имеет только один ЦПУ. Основной вопрос заключается в том как система с единственным ЦПУ исполняет множество процессов одновременно? Даже для систем со множеством ЦПУ или со множеством ядер в ЦПУ, общее число процессов больше чем общее число ЦПУ или ядер. Как же некая система при общем числе процессов, превосходящем общее число ЦПУ или ядер ЦПУ исполняет такие процессы одновременно? Подробное обсуждение этой темы выходит за рамки данного учебного пособия, однако вкратце мы вернёмся к нему в Разделе 10.2 и позже в Разделе 10.5.1. Далее в этой главе мы обсудим просмотр статических и динамических состояний процессов, приоритетные (foreground) и фоновые (background) процессы, демоны, задания, атрибуты процессов и заданий, а также управление процессами и заданиями. Термины разделение времени (time sharing) и многозадачность (multitasking) мы будем применять как синонимы.
Планирование ЦПУ: одновременное исполнение множества процессов
В типичной вычислительной системе, состоящей из единственного ЦПУ и работающего под управлением операционной системы с разделением по времени исполнения, одновременное исполнение множества процессов выполняется путём быстрого переключения ЦПУ от одного процесса к другому. То есть, один процесс исполняется на в течении непродолжительного периода времени, а затем данный ЦПУ передаётся другому процессу. Этот новый процесс исполняется некое непродолжительное время и затем данный ЦПУ передаётся вновь следующему процессу. То время, которое некий процесс находится «внутри» данного ЦПУ прежде чем он переключится «вовне» данного ЦПУ имеет название квантом или срезом времени . В обычной UNIX системе такой квант обычно очень короткий: одна секунда или меньше. В Solaris данный квант некоторого процесса зависит от приоритета процесса. Для процессов пользователя с разделением времени значение кванта составляет 40 миллисекунд. Для более приоритетных процессов такое значение кванта выше. Например, для потоков ядра с приоритетом 0 значение кванта равно 200 миллисекундам, а для потоков ядра с приоритетом 10 160 миллисекунд. Во FreeBSD такое значение кванта времени равно 0.1 секунды. Когда данный ЦПУ свободен/ простаивает (idle, т.е. не используется каким- либо процессом), либо когда определённый текущий процесс завершил свой квант, само ядро применяет некий алгоритм чтобы решить какой процесс получит применение ЦПУ следующим. Та техника, которая применяется для выбора подобного процесса, который получает в своё пользование имеющийся ЦПУ называется планированием ЦПУ (CPU scheduling). Тот код ядра, который исполняет данную задачу называется краткосрочным планировщиком ЦПУ (short-term CPU scheduler), либо планировщиком ЦПУ (CPU scheduler).
Конкретная процедура забора ЦПУ обратно у исполняющегося в настоящее время процесса и предоставление его определённому по расписанию новому процессу называется контекстным переключением (context switching). Данная задача исполняется другой частью ядра, имеющей название диспетчера (dispatcher). В системе со множеством ЦПУ или для ЦПУ со множеством ядер, таких как выпускаемых Intel, AMD и другими компаниями, если общее число процессов в данной системе превышает общее число ЦПУ в данной системе (или общее число ядер для системы с единственным ЦПУ), планирование ЦПУ и контекстное переключение всё ещё происходят. Таким образом, в некоторой системе со множеством пользователей исполняющих множество процессов имеющиеся планировщик и диспетчер работают в тандеме с тем чтобы вы чувствовали себя единственным использующим всю систему. Хотя некая сосредоточенность на обсуждении алгоритмов планирования ЦПУ выходит за рамки данной книги, мы представим некоторое упрощённое видение того как работают планировщики UNIX SV, FreeBSD и Solaris.
В некоторой системе с разделением по времени, каждому процессу назначается некое значение приоритета, причём следующим получает в своё распоряжение ЦПУ тот процесс, который имеет более высокий приоритет. Для назначения какого- то значения некоторому процессу могут применяться различные методы. Один простой метод основывается на том значении времени когда он вошёл в систему. В данной схеме обычно тому процессу, который вошёл в данную систему первым, назначается более высокий приоритет и предоставляется следующее использование имеющегося ЦПУ; получаемый результат называется алгоритмом планирования первый вошедший обслуживается первым (FCFS, first-come, first-serve). Другой схемой является назначение некоторой величины приоритета на основе используемого неким процессом времени ЦПУ. Таким образом, некие недавно появившиеся процессы или какие- то процессы, которые тратят основное время на выполнение операций ввода и/ или вывода (I/O), получают более высокий приоритет. Процессы, которые тратят большую часть своего времени выполняя ввод/ вывод называются процессами, связанными со вводом/ выводои . Неким примером связанного со вводом/ выводом процесса является текстовый редактор, например, vim. В алгоритме планирования карусельным образом (RR, round robin), имеющийся ЦПУ предоставляется каждому ЦПУ в определённой очереди процессов на единственный квант времени по порядку, один за другим. Такой алгоритм является естественным выбором для систем с разделением времени, в которых все пользователи хотят видеть продвижение своих процессов. Если вам интересны прочие алгоритмы планирования ЦПУ, мы рекомендуем вам прочесть некую книгу по принципам и концепциям операционных систем. Тот код операционной системы, который реализует необходимый алгоритм планирования ЦПУ называется планировщиком процессора (processor scheduler). Подобный планировщик для большинства операционных систем, включая UNIX, находится в самом ядре.
Алгоритм планирования UNIX System V является смесью всех упомянутых алгоритмов и даже более. Он применяет некую простую формулу для назначения некоторого значения приоритета каждому процессу в данной системе если ог готов к исполнению. Такое значение приоритета для каждого процесса в данной системе повторно вычисляется каждую секунду. Когда наступает время планирования, данный ЦПУ отдаётся тому процессу, который имеет наименьшее численное значение приоритета. Если множество процессов имеют одно и то же численное значение приоритета, окончательное решение принимается на основе FCFS. Той формулой, на основании которой производится вычисление значения приоритета является:
значение приоритета = пороговое значение приоритета + значение любезности + (недавнее использование ЦПУ / 2),
где пороговое значение приоритета является неким целым обычно имеющим значение от 40 до 60, значение любезности (nice value) является положительное целое со значением по умолчанию 10, но может быть неким значением от -20 до 19 (20 в некоторых системах UNIX), а использование ЦПУ общее число тактов времени (1/60 или 1/50 секунды для более ранних систем, где 60 и 50 является частотой в линии электропитания в Герцах) в течении которых данный процесс применял этот ЦПУ. В современных системах UNIX временной такт намного ниже и не вычисляется на основе частоты линии электропитания. Имеющиеся часы программы обслуживания прерываний (ISR, interrupt service routine), обновляют использование ЦПУ для каждого процесса после каждого такта времени, что увеличивает общий счётчик тактов для того процесса, который в настоящее время использует данный ЦПУ. Такие часы ISR делят все насчитанные такты каждого процесса на два перед тем как повторно вычисляют приоритеты всех процессов применяя отображённую формулу. Такое деление на два известно как применение функции распада (decay function), так как оно экспоненциально уменьшает воздействие предыдущего использования ЦПУ. Таким образом, недавнее применение ЦПУ процессом оказывает большее воздействие на величину его приоритета, в его уходящее в историю использование имеет понижающееся влияние. Таким образом имеющееся значение использования ЦПУ увеличивается для тех процессов, которые используют ЦПУ и уменьшается для всех остальных.
Вы можете назначит более высокое любезное значение для своего процессора с помощью команды nice или renice , однако такое любезное значение не может быть установлено в отрицательную величину кем- то, не имеющим права суперпользователя. Более высокая величина любезного значения означает более высокую величину приоритета, следовательно, более низкий приоритет. Итак, когда вы увеличиваете величину хорошего значения для своего процесса, вы являетесь более любезным ко всем остальным процессам пользователей. Данная формула ясно указывает что чем выше значение недавнего использования ЦПУ некоторого процесса, тем выше его величина приоритета. Таким образом UNIX предпочитает те процессы, которые использовали меньше времени ЦПУ в недавнем прошлом. Текстовый редактор подобный vim получает более высокий приоритет нежели некий процесс, который вычисляет значение числа π (пи), так как vim проводит основное время в ожидании операций ввода/ вывода — то есть считывает с клавиатуры, выполняет чтение/ запись на диск и отображает данные файла или ввода с клавиатуры на основном экране. С другой стороны, тот процесс, который вычисляет π татит своё основное время на выполнение вычислений — то есть использует ЦПУ. Повторное вычисление всех значений приоритетов каждую секунду вызывает динамическое изменение приоритетов процессов (вверх и вниз). В Разделе 10.5 мы дальше исследуем имеющуюся концепцию планирования UNIX, в частности, по отношению к PC-BSD и Solaris.
Состояния процесса Unix
Процесс UNIX может находиться в одном из множества состояний, перемещаясь из одного состояния в другое, в конце концов завершая своё выполнение, причём оно может быть как нормальным, так и нештатным, но в конечном счёте управление передаётся самой системе. Процесс завершается нормально, когда он оканчивает свою работу и выходит в систему надлежащим образом. Процесс завершается нештатно когда он выходит в свою систему из- за некоторого прерывания (exception, наличие ошибки) или из- за вмешательства (intervention) его владельца или суперпользователя. Владелец процесса может вмешаться при помощи команды или определённого нажатия клавиш для преывания данного процесса. Мы обсудим такие команды или конкретные нажатия клавиш позже в данной главе. Все первичные состояния, в которых некий процесс может находиться отображены в диаграмме состояний на Рисунке 10.1.
Состояние ожидания (waiting state) охватывает определённые состояния; мы применяем данный термин здесь чтобы сохранить простой показанную схему. Некоторые из относящихся к состоянию ожидания состояний перечисляются под овалами, представляющими определённое состояние. Таблица 10.1 представляет краткое описание таких состояний процесса UNIX. В интересах краткости и придерживаясь темам данной книги, прочие состояния, в которых может находиться некий процесс UNIX не включены в данное обсуждение.
исполнение команд оболочки
Команда оболочки может быть внутренней (встроенной) или внешней. Некоторой внутренней/ встроенной командой является команда, код которой является частью самого процесса оболочки. Некоторыми обычно используемыми командами являются . (команда точки), bg , cd , continue , echo , exec , exit , export , fg , jobs , pwd , read , readonly , return , set , shift , test , times , trap , umask , unset и wait . внешней командой является команда выполненная в виде отдельного файла с кодом; содержимым этого кода может быть двичный код или некий сценарий оболочки. В качестве обычно применяемых команд можно представить grep , more , cat , mkdir , rmdir , ls , sort , ftp , telnet , lp и ps . Оболочка создаёт некий новый процесс для исполнения какой- то команды. Пока исполняется процесс данной команды, сама оболочка ожидает его завершении. В данном разделе мы описываем как некая оболочка (или некий процесс) создаёт другой процесс и исполняет внешние команды. Вы можете применить команду type для определения того факта, является ли ваша команда встроенной или внешней, как это показано в следующем разделе. В Bash вы можете воспользоваться параметром -a для отображения всех местоположений команд, как показано ниже. Вы можете отметить, что команда bg является встроенной, но также имеет и внешнюю версию. Однако, по умолчанию исполняется встроенная версия. Сама оболочка Bourne может быть запущена через два исполняемых файла, доступных в двух разных местах структуры вашей файловой системы.
Рисунок 10.1
Диаграмма состояний процесса UNIX
Ready
Данный процесс готов к исполнению, однако не имеет ресурса ЦПУ. Основываясь на алгоритме планирования, сам планировщик принимает решение по предоставлению ресурса ЦПУ другому процессу. В данном состоянии могут пребывать различные процессы, однако в машине с единственном ЦПУ только один может работать/ исполняться (т.е. применять ЦПУ).
Running
Данный процесс действительно исполняется (т.е. применяет ЦПУ).
Waiting
Данный процесс ожидает события. Возможными событиями могут быть: завершение некоторой операции ввода/ вывода (т.е. операции чтения или записи диска/ терминала), завершение дочернего процесс (данный родитель ожидает выхода одного или более детей) или сам процесс ожидает повторного пробуждения находясь в состоянии сна.
Swapped
Данный процесс готов к исполнению, однако временно помещён на имеющийся диск (в предоставленное пространство подкачки); может потребоваться дополнительная оперативная память, которой в данный момент не имеется.
Zombie
Убитый процесс называется находящимся в состоянии зомби. Обычно, когда его родительский процесс завершился до выполнения вызова выхода данного процесса, он становится неким процессом зомби. Такой процесс завершается и обнаруживает что его не ожидает его родительский процесс. Такой процесс зомби завершён в отношении всех практических целей и не располагается в оперативной памяти, но всё ещё имеет некоторые выделенные ему ресурсы ядра, которые не могут быть возвращены в данную систему. Все зомби и их исполняющиеся потомки со временем принимаются своим прародителем, основным процессом Code , который и удаляет их из данной системы.
$ type bg bg is a shell builtin $ type -a bg bg is a shell builtin bg is /usr/bin/bg $ type -a sh sh is /usr/bin/sh sh is /usr/sbin/sh $ Всякий процесс UNIX может создать другой процесс применив системный вызов fork() , который создаёт точную копию оперативной памяти первоначального процесса (т.е. того процесса, который вызвал fork() ). Оба процесса продолжат исполнение, начав с того оператора, который следует за таким ветвлением. Разветвляемый процесс именуется родительским процессом , а созданный (ответвлённый) процесс называется дочерним процессом (потомком) что отображается на Рисунке 10.2. Здесь мы отображаем оболочку Bourne, которая создала некий дочерний процесс (другую оболочку Bourne). Мы обсудим использование fork() и прочих системных вызовов, требующихся для создания и взаимодействия между процессами (IPC, interprocess communication) в Главах 18 — 21.
Рисунок 10.2
Создание процесса системным вызовом ветвления
Для исполнения внешней команды в виде исполняемого файла требуется некий механизм, который позволяет данному дочернему процессу стать самой исполняемой командой. Именно для этого и можем применяться системный вызов UNIX exec() , он делает возможным перезапись процесса самого собой тем исполняемым кодом, который представляет следующую команду. Оболочка применяет команды fork() и exec() в тандеме при исполнении внешних команд исполняемых файлов. Рисунок 10.3 отображает последовательность событий для выполнения внешней команды sort , чьим кодом является исполняемый файл /usr/bin/sort .
Рисунок 10.3
Этапы исполнения скомпилированной программы sort оболочкой UNIX
Шаг 1 : Оболочка при меняет fork для создания потомка.
Шаг 2 : Потомок применяет exec для перезаписи себя исполняемым файлом, соответствующим команде sort .
Шаг 3 : sort начинает исполнение, в то время как » sh » ожидает команду завершения. Когда sort оканчивается, данный дочерний процесс прекращается и » sh » начинает исполнение вновь, переходя к ожиданию предоставления пользователем другой команды для исполнения.
Само исполнение сценария оболочки (последовательности команд оболочки в некотором файле; см. Главы 12 — 15) слегка отличается от исполнения некоторого исполняемого файла/ команды. В данном случае сценария оболочки сама текущая оболочка создаёт некую дочернюю оболочку и позволяет ей исполнять команды в таком файле сценария одну за другой. Каждая команда в данном файле сценария исполняется в точности так же, как и команда, введённая с клавиатуры; то есть сама дочерняя оболочка создаёт некоторого потомка для каждой исполняемой команды. В то время, когда имеющаяся дочерняя оболочка исполняет команды в данном файле сценария, сама родительская оболочка ожидает завершения своего потомка. Когда такая дочерняя оболочка сталкивается в данном файле сценария с маркером eof , она прекращает своё исполнение. Единственной целью самой дочерней оболочки, как и любой другой оболочки, состоит в исполнении команд, а eof означает «больше нет команд». После окончания дочерней оболочки его родительская оболочка выходит из состояния ожидания и продолжает исполнение. Данная последовательность событий отображена на Рисунке 10.4, который также отображает само исполнение команды find из файла сценария.
Рисунок 10.4
Этапы исполнения сценария оболочки оболочкой UNIX
Шаг 2 : команды fork и exec повторяются для всех внешних команд; внутренние команды исполняются самой «дочерней» оболочкой.
Пока другое не определено в самом содержащем данный сценарий файле, данная дочерняя оболочка имеет тот тип, который определён для самой родительской оболочки. То есть, если родитель является оболочкой Bourne, сам потомок также является оболочкой Bourne. Таким образом, по умолчанию сам сценарий оболочки исполняется некоторой «копией» своей родительской оболочки. Однако, некий сценарий, написанный под любую оболочку (C, TC, Bourne, Bash, Korn и т.п.) может исполняться не взирая на имеющийся тип текущей оболочки. Для этого просто определите необходимый тип дочерней оболочки для каждого исполняемого сценария в самой первой строке содержащего её файла в виде #!полный-путь-к-имени-необходимой-оболочки . Например, следующая строка указывает, что дочерней оболочкой является оболочка C, поэтому тот сценарий, который следует за данной строкой исполняется под оболочкой C.
#!/bin/csh
Кроме того, вы можете исполнять команды в другой оболочке исполняя эту оболочку как дочернюю для текущей рабочей оболочки, выполнить в ней команды и завершить исполнение этой оболочки. Некая дочерняя оболочка также имеет название подоболочки (subshell). Повторим, что командами для исполнения различных оболочек являются sh для оболочки Bourne, csh для оболочки C, tcsh для оболочки TC, ksh для оболочки Korn, bash для оболочки Bourn again. Чтобы запустить некий новый процесс оболочки просто исполните ту команду, которая соответствует той оболочке, которую вы желаете исполнить.
В приводимом далее сеансе текущая оболочка является оболочкой C, а оболочка Bourne исполняется как её потомок. Команда echo исполняется в оболочке Bourne. Затем запускается некая оболочка Bash и команда echo исполняется в ней. Команда ps отображает исполнение всех трёх оболочек. Наконец, и оболочка Bash, и оболочка Bourne прекращаются последовательностью нажатий клавиатуры Ctrl+D , при этом управление возвращается обратно первоначальной оболочке, нашей оболочке C. Самое первое Ctrl+D прекращает исполнение оболочки Bash, передавая управление оболочке Bourne. Вы также можете покинуть исполняющуюся оболочку выполнив команду exit . Рисунок 10.5 иллюстрирует все задействованные этапы, отображая взаимоотношения родитель- потомок между процессами.
Рисунок 10.5
Исполнение команд под управлением дочерних оболочек (также именуемых подоболочками)
% ps PID TT STAT TIME COMMAND 44387 5 Ss 0:00.97 -csh (csh) 45878 5 R+ 0:00.01 ps % /bin/sh $ echo "This is Bourne shell." This is Bourne shell. $ bash [sarwar@pcbsd-srv ~]$ echo "This is Bourne Again SHell." This is Bourne Again SHell. [sarwar@pcbsd-srv ~]$ ps PID TT STAT TIME COMMAND 44387 5 Is 0:00.97 -csh (csh) 45910 5 I 0:00.02 /bin/sh 45935 5 S 0:00.07 bash 46008 5 R+ 0:00.01 ps [sarwar@pcbsd-srv ~]$ $ % Атрибуты процесса
Всякий процесс UNIX имеет некоторые атрибуты, включая идентификатор владельца (именуемый на жаргоне UNIX user ID [UID]), идентификатор процесса (PID), PID его родительского процесса (PPID), название процесса, состояние процесса, запустившая данный процесс исполняемая команда, приоритет данного процесса, время запуска процесса, процент времени исполнения ЦПУ, потреблённый данным процессом, процент объёма основной оперативной памяти, потреблённый данным процессом, размер данного процесса в виртуальной памяти, размер процесса, находящегося в данный момент в основной оперативной памяти, состояние данного процесса, то событие, которое ожидает данный процесс (в случае если он не исполняется), а также продолжительность времени, в течении которого данный процесс исполняется. С точки зрения пользователя и программиста одним из самых полезных среди данных атрибутов является PID, который применяется в качестве параметра в различных командах управления процессами, которые обсуждаются далее в этой главе.
UNIX предоставляет некоторые инструменты, которые позволяют вам наблюдать за атрибутами тех процессов, которые в настоящее время исполняются в вашей системе, изменять текущие состояния ваших процессов, а также выполнять над ними различные операции, включая их останов/ повторный запуск, отправку определённых сообщений, осуществления взаимодействия друг с другом, а также их прекращения. В данной главе мы обсудим некоторые их имеющихся команд и инструментов, которые позволят нам наблюдать за атрибутами процессов статически и динамически, а также выполнять различные операции над только что запущенными процессами.
Статическое отображение атрибутов процесса
Команда ps может применяться для просмотра моментального снимка всех атрибутов запущенных в настоящее время в данной системе процессов. PC-BSD и Solaris имеют свои собственные версии данной команды с различными параметрами. Однако, некоторые из этих команд являются общими. Прежде всего мы подробно обсудим версию данной команды для PC-BSD, а затем обсудим дополнительные свойства имеющейся версии Solaris. Ниже приводится краткое описание версии команды ps PC-BSD.
Синтаксис ps Назначение: Информация статистического отчёта (один снимок) о состоянии/ атрибутах процесса Вывод: Строка заголовка и моментальный снимок всех атрибутов исполняющихся в данной системе процессов Обычно применяемые параметры/ свойства: -D Отображает информацию о процессах, исполняющихся от имени групп пользователей, определяемых в разделяемым запятыми списке ID групп; не допускаются никакие пробелы до и после запятых -H Отображает информацию о видимых основному ядру UNIX потоках -L Отображает список ключевых слов, которые могут применяться с опцией -O или -o -O Отображает информацию о разделяемых запятыми или пробелами ключевых словах, после поля PID в определяемом по умолчанию выводе. Вы можете назначать по своему выбору заголовок для ключевых слов помещая после самого ключего слова = , за которым следует данный заголовок. -U Отображает информацию о всех процессах для тех пользователей, которые определены в разделяемом запятыми списке имён пользователей; не допускаются никакие пробелы до и после запятых -a Отображает информацию о ваших процессах и процессах прочих пользователей -c Отображает только само название исполняемого файла вместо полного имени пути -d Отображает иерархическую структуру процессов, показывая путём отступов взаимоотношения родитель- потомок и соотнесение к одному предку -e Отображает информацию среды для каждого процесса -j Для каждого процесса отображает информацию по следующим ключевым словам: user , pid , ppid , pgid , sid , jobc , state , tt , time и command . -l Для каждого процесса отображает информацию по следующим ключевым словам: uid , pid , ppid , cpu , pri , nice , vsz , rss , mwchan , state , tt , time и command . -e Отображает информацию, отсортированную согласно использованию памяти (использующие больше первыми) -o Аналогично -O , за исключением того, что не отображает все определённые по умолчанию поля и вы можете изменять тексты заголовка для множественного использования, применяя опцию -o несколько раз. Если не определён никакой заголовок с ключевыми словами, такая строка заголовка не отображается. -p Отображает информацию о процессах, определённых в заданном списке PID -r Отображает информацию, отсортированную согласно использованию ЦПУ (наиболее использующие первыми) -u Отображает для каждого процесса информацию по следующим ключевым словам: user , pid , %cpu , %mem , vsz , rss , tt , state , start , time и command . -v Отображает для каждого процесса информацию по следующим ключевым словам: user , pid , state , time , sl , re , pagein , vsz , rss , lim , tsiz , %cpu , %mem и command . -x Отображает информацию по процессам, которые не имеют управляющих терминалов (включая демоны)
Вывод команды ps вначале сортируется по связанным с процессами терминалам, а затем по их PID. Вы можете изменить такой установленный по умолчанию порядок сортировки применяя различные опции. Если определено множество таких опций, данная команда придерживается самой последней опции. Все сеансы оболочки в данном разделе демонстрируют данную команду ps с опциями или без них. Все их мы исполнили на машине PC-BSD под управлением оболочки C.
Вывод данной команды ps для версии PC-BSD, как это показано в приводимом ниже сеансе, отображает пять полей о процессах, чьи атрибуты выводятся построчно: идентификатор процесса ( PID ), тот термина, к которому подключён данный процесс ( TT ), состояние процесса ( STAT ), потреблённое данным процессом время ЦПУ ( TIME ) и использованная пользователем команда для исполнения данного процесса ( COMMAND ). Данный вывод показывает, что два процесса подключены к терминалу 1 : -csh (сама регистрация в оболочке C) и ps , а два подключены к терминалу 2 : -csh (опять регистрация в оболочке C) и текстовый редактор vim , — перед некоторой оболочкой, как в случае с -csh , указывает на то, что это регистрация в оболочке. Значение PID подключённого к терминалу 1 процессов -csh и ps равны 37838 и 41626, причём они, соответственно, проработали 19 секунд и 1 секунду. Аналогично, значения PID процессов, исполняющих -csh и vim равны 41496 и 41619, причём они, соответственно, проработали 27 секунд и 19 секунд каждый.
% ps PID TT STAT TIME COMMAND 37838 1 Ss 0:00.19 -csh (csh) 41626 1 R+ 0:00.01 ps 41496 2 Ss 0:00.27 -csh (csh) 41619 2 S+ 0:00.25 vim canleave % В предыдущем сеансе само состояние процесса отображается в виде строки символов — например, Ss , S+ и R+ . Таблица 10.2 поясняет различные символы в данной строке, перечисленные в колонке состояний процесса STAT ).
D
Процесс на диске или в другом режиме кратковременного ожидания