какие сигналы процесс не может игнорировать или обработать по своему

Какие сигналы процесс не может игнорировать или обработать по своему

Главное отличие сигналов от других средств взаимодействия между процессами заключается в том, что их обработка программой обычно происходит сразу же после поступления сигнала (или не происходит вообще), независимо от того, что программа делает в данный момент. Сигнал прерывает нормальный порядок выполнения инструкций в программе и передает управление специальной функции – обработчику сигнала. Если обработка сигнала не приводит к завершению процесса, то по выходе из функции-обработчика выполнение процесса возобновляется с той точки, в которой оно было прервано. У программ также есть возможность приостановить обработку поступающих сигналов временно, на период выполнения какой-либо важной операции. В традиционной терминологии приостановка получения определенных сигналов называется блокированием. Если для поступившего сигнала было установлено блокирование, сигнал будет передан программе, как только она разблокирует данный тип сигналов. Этим блокирование отличается от игнорирования сигнала, при котором сигналы соответствующего типа никогда не передаются программе. Следует помнить, что не все сигналы могут быть проигнорированы. Например, при получении программой сигнала принудительного завершения SIGKILL система ничего не сообщает программе, а просто прекращает ее работу. Таким образом, преимущество сигналов перед другими средствами взаимодействия с программой заключается в том, что посылать программе сигналы можно в любой момент ее работы, не дожидаясь наступления каких-то особых условий. Источником сигналов может быть как сам операционная система, так и другие программы пользователя. Если вам показалось, что сигналы похожи на прерывания, то вы совершенно правы. Для реализации сигналов действительно используются программные прерывания.

Нужно ли обрабатывать сигналы в вашей программе? Большинство программ не делают этого. В случае программирования для графических оболочек многие функции сигналов берут на себя механизмы сообщений графической оболочки. Тем не менее, есть целый ряд программ (например, демоны и консольные многопоточные приложения), в которых обработка сигналов необходима. Большинству сигналов системы присвоена конкретная роль и, хотя у программиста существует возможность использовать сигналы для передачи произвольной информации, не соответствующей их стандартному назначению, делать этого не рекомендуется. Собственно говоря, с помощью сигналов можно передать не так уж и много информации – только номер сигнала (хотя на платформе x86, например, можно было бы организовать и передачу дополнительных параметров). Скудость данных, передаваемых сигналами, не удивительна, если учесть, что по умолчанию большинство сигналов просто завершают работу программы. При этом в некоторых случаях на диске сохраняется образ памяти выгруженной программы (знаменитый файл core dump). Соответственно и программа-источник сигнала обычно не ждет никакого ответа от программы-приемника.

Сигнал SIGABRT (номер 6) посылается программе в результате вызова функции abort(3). В результате программа завершается с сохранением на диске образа памяти.

Сигнал SIGKILL (номер 9) завершает работу программы. Программа не может ни обработать, ни игнорировать этот сигнал.

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

Сигнал SIGTERM (номер 15) вызывает «вежливое» завершение программы. Получив этот сигнал, программа может выполнить необходимые перед завершением операции (например, высвободить занятые ресурсы). Получение SIGTERM свидетельствует не об ошибке в программе, а о желании ОС или пользователя завершить ее.

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

Сигнал SIGCONT (номер 18) возобновляет выполнение процесса, остановленного сигналом SIGSTOP.

Сигнал SIGSTOP (номер 19) приостанавливает выполнение процесса. Как и SIGKILL, этот сигнал не возможно перехватить или игнорировать.

Сигнал SIGTSTP (номер 20) приостанавливает процесс по команде пользователя (обычно эта команда – сочетание клавиш Ctrl-Z).

Сигнал SIGIO/SIGPOLL (в Linux обе константы обозначают один сигнал – номер 29) сообщает процессу, что на одном из дескрипторов, открытых асинхронно, появились данные. По умолчанию этот сигнал, как ни странно, завершает работу программы.

В стандартной системе Unix определены два сигнала, SIGUSR1 (в Linux – номер 10) и SIGUSR2 (номер 12), предназначенные для передачи произвольной информации, но использование этих сигналов не приветствуется. Одной из причин негативного отношения программистов Unix к пользовательским сигналам является то, что сигналы, вообще говоря, представляют собой ограниченный ресурс, совместное использование которого может вызвать конфликты (например, если программист задействовал эти сигналы в своей программе и при этом использует стороннюю библиотеку, в которой эти сигналы также задействованы). Если вы не знали, то вам, возможно, будет интересно узнать, что обработка сигналов является частью стандарта языка Си и, как таковая, поддерживается даже на платформе Microsoft Windows. Однако, стандартный интерфейс сигналов Си, основанный на функции signal(), довольно неуклюж (недостатки интерфейса сигналов Си подробно описаны в книге [2]), так что мы воспользуемся более совершенным вариантом интерфейса, основанным на функции sigaction(2). Для демонстрации работы обработки сигналов мы напишем небольшую программу (файл sigdemo.c в исходниках).

Наша программа делает две вещи: обрабатывает сигнал SIGTERM (при получении этого сигнала программа выводит диагностическое сообщение и завершает свою работу) и блокирует сигнал SIGHUP, так что этот сигнал не может завершить ее работу. В тексте программы мы первым делом определяем функцию- обработчик сигнала SIGTERM term_handler(). Функции-обработчики сигналов – это обычные функции Си, они имеют доступ ко всем глобально видимым переменным и функциям. Однако, поскольку мы не знаем, в какой момент выполнения программы будет вызвана функция-обработчик, мы должны проявлять особую осторожность при обращении к глобальным структурам данных из этой функции.

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

Перейдем теперь к тексту главной функции программы. Установка и удаление обработчиков сигналов осуществляются функцией sigaction(2). Первым параметром этой функции является номер сигнала, а в качестве второго и третьего параметров следует передать указатели на структуру sigaction. Эта структура содержит данные об операции, выполняемой над обработчиком сигнала. Второй параметр sigaction() служит для передачи новых значений для обработки сигнала, а третий – возвращает ранее установленные значения. В таблице 1 приводится краткое описание полей структуры sigaction.

Таблица 1. Поля структуры sigaction.

Поле sa_handler должно содержать либо адрес функции-обработчика, либо специальную константу, указывающую, что нужно делать с сигналом. Константа SIG_IGN указывает, что сигнал следует игнорировать, а константа SIG_DFL – что нужно восстановить обработку сигнала, заданную системой по умолчанию. Поле sa_mask позволяет заблокировать некоторое множество сигналов на время выполнения обработчика данного сигнала. Делается это для того, чтобы обработка других сигналов не могла прервать обработку данного (это может быть необходимо, особенно, если один обработчик обрабатывает несколько разных сигналов). Параметр sa_flags позволяет задать ряд флагов для выполнения более тонкой настройки обработчика сигналов. Например, флаг SA_RESETHAND указывает, что после завершения обработки сигнала заданным обработчиком должен быть восстановлен обработчик, заданный по умолчанию, так что все последующие сигналы будут обрабатываться умалчиваемым обработчиком.

В результате вызова функции sigaction() мы устанавливаем обработчик сигнала SIGTERM. Затем наша программа распечатывает значение PID (это значение понадобится нам для вызова команды kill) и входит в бесконечный цикл, из которого она может быть выведена одним из сигналов. Следует отметить, что функция sleep() возвращает управление (возобновляет выполнение программы раньше срока) если обработчик какого-либо сигнала возвращает управление в этот момент. Иначе говоря, любой обрабатываемый сигнал прерывает выполнение sleep(). Впрочем, в нашем примере с бесконечным циклом это не помогло бы программе завершиться. Сигнал SIGTERM приведет к тому, что программа выдаст диагностическое сообщение и завершит работу, а сигналы SIGINT и SIGABRT – к тому, что программа завершится без всякого сообщения. Скомпилируйте и запустите программу в окне терминала. В другом окне скомандуйте kill

где PID – идентификатор процесса программы. Вы увидите, что перед тем как завершиться, программа выдает диагностическое сообщение, тогда как при завершении с помощью Ctrl-C никакого сообщения не выводится.

Первым параметром этой функции должна быть одна из констант, определяющих операцию над заданными сигналами. Константа SIG_BLOCK указывает, что сигналы из нового набора должны быть добавлены к списку уже заблокированных сигналов. Константа SIG_SETMASK указывает, что новый набор блокируемых сигналов должен заменить уже существующий (при этом заблокированные ранее сигналы будут разблокированы, если они не заблокированы в новом наборе), а константа SIG_UNBLOCK указывает на необходимость разблокировать сигналы, переданные в наборе. В нашей программе мы блокируем сигнал SIGHUP и вы можете видеть, что программа не обрабатывает этот сигнал. Послать нашей программе сигнал SIGHUP вы можете с помощью консольной команды где PID – идентификатор процесса.

Сигналы прерывают нормальный порядок выполнения программы и могут завершить работу программы, не способной завершиться иным образом. Но иногда бывает так, что программе просто нечего делать до тех пор, пока она не получит какой-либо сигнал. Иначе говоря, программу нужно заставить ждать появления сигнала, по возможности не нагружая процессор. Такая ситуация может возникнуть, например, в многопоточном программировании, когда нужно синхронизировать завершение нескольких потоков. Ожидание сигнала можно реализовать с помощью цикла, проверяющего значение флажка, который может сбросить обработчик сигнала. В некоторых случаях (таких как рассмотренный выше пример) можно реализовать ожидание и с помощью бесконечного цикла. Очевидно, однако, что эти методы не эффективны и не элегантны. В POSIX- системах существует специальная функция sigwait(3), которая «усыпляет» процесс до тех пор, пока процессу не будет передан один из заданного набора сигналов.

Модифицируем нашу программу так, чтобы вместо бесконечного цикла она входила в цикл ожидания сигнала SIGHUP (файл swdemo.c на компакт-диске):

Первым параметром функции sigwait() является указатель на набор сигналов, получения которых будет ждать функция. Во втором параметре sigwait() вернет номер того сигнала, который возобновил работу программы (эта информация может быть полезна, если установлено несколько ожидаемых сигналов). Перед тем как вызывать sigwait(), набор ожидаемых сигналов следует заблокировать с помощью функции sigprocmask(), иначе, при получении сигнала, вместо выхода из sigwait() будет вызван соответствующий обработчик. Сигнал, который возобновил работу программы после вызова sigwait(), уже не может быть перехвачен назначенным ему обработчиком. В нашем примере мы «усыпляем» программу до тех пор, пока она не получит сигнал SIGHUP, распечатываем соответствующее сообщение и снова усыпляем (функция sigwait() возвращает 0, если ее вызов прошел успешно). В то время, когда программа приостановлена в ожидании некоторых сигналов, обработчики всех не заблокированных и не игнорируемых сигналов выполняются обычным образом.

Функцию sigwait() можно использовать и для исследования сигналов. На компакт-диске вы найдете программку siglog.c, которая распечатывает информацию о каждом поступившем сигнале (естественно, исследуются только те сигналы, которые могут быть заблокированы). Рассмотрим здесь фрагмент этой программы:

С помощью вызовов sigfillset()и sigdelset()мы создаем набор из всех сигналов, за исключением сигнала SIGTERM (этот сигнал понадобится нам для того, чтобы мы могли завершить работу программы). Далее мы блокируем сигналы набора sset и вызываем для них функцию sigwait(). Функция вернет управление при получении любого сигнала, кроме SIGTERM (для которого назначен отдельный обработчик). Получив новый сигнал, мы распечатываем информацию о нем. Массив char * sys_siglist[] определен в стандартной библиотеке glibc. Этот массив содержит наименования сигналов на «человеческом» языке (эти наименования можно использовать при выводе диагностических и отладочных сообщений). Наименования расположены так, чтобы их индексы в массиве соответствовали номерам сигналов. Те же данные возвращает и функция strsignal(), единственным параметром которой является номер сигнала.

На протяжении всей этой статьи мы занимались обработкой сигналов, но не их генерацией. Поскольку основным источником сигналов является операционная система, нам и в «реальной жизни» чаще приходится заниматься именно обработкой. Однако, в заключение статьи следует рассмотреть и функции генерации сигналов. Для генерации сигналов в Unix предусмотрены две функции – kill(2) и raise(3). Первая функция предназначена для передачи сигналов любым процессам, к которым владелец данного процесса имеет доступ, а с помощью второй функции процесс может передать сигнал самому себе. Как это обычно принято в мире Unix, семантика вызова функции kill()совпадает с семантикой одноименной команды ОС. У функции kill()два аргумента –PID процесса-приемника и номер передаваемого сигнала. С помощью функции kill()как и с помощью одноименной команды можно передавать сообщения не только конкретному процессу, но и группе процессов.

Источник

linux-notes.org

Команда kill в Unix/Linux

Сигналы — программные прерывания. Они используются для связи между процессами в UNIX и UNIX-подобных операционных систем, таких как Linux, Mac OS.

Сигналы использовались еще с Bell Labs UNIX в 1970 и сегодня официально определено стандартом POSIX. Когда сигнал поступает на процесс, операционная система прерывает нормальный поток выполнения процесса и обеспечивает уведомление.

Не имеет значения, какую операционную систему вы используете, вы несомненно столкнетесь с тем что ваши приложения, блокируются и отказаться работать должным образом. В Unix, Linux, есть команда «kill», которую вы можете использовать, чтобы прекратить процесс немедленно, но и не только это, но об этом немного позже я расскажу. В этой статье «Команда kill в Unix/Linux» я расскажу и покажу на готовых примерах различные команды утилиты kill.

Команды kill и сигналы

Когда вы выполняете команду «kill», вы на самом деле посылает е сигнал к системе и даете указание расторгнуть работу некорректной роботы приложения. Существует в общей сложности 60 сигналов, которые можно использовать, но все, что вы действительно должны знать, SIGTERM (15) и SIGKILL (9).

Вы можете просмотреть все сигналы с помощью команды:

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

Основные сигналы

Следующие сигналы являются частью стандарта POSIX. Каждый сигнал макрос, определенный в Файл заголовка системы. Они, как правило, сокращенны, без их SIG- префикса; например SIGHUP часто называют просто как HUP.

SIGTERM – Этот сигнал запрашивает остановку процесса который работает. Этот сигнал может быть проигнорирован.Процессу дается время, чтобы хорошо выключился. Когда программа хорошо выключается, это означает, что ей дано время, чтобы спасти его прогресс и освободить ресурсы. Другими словами, он не «forced» прекращение работы процесса.

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

Синтаксис для «kill».

Синтаксис команды такой:

Сигнал по умолчанию (если он не указан) является SIGTERM. Когда данный сигнал не помогает и не работает, вы можете использовать следующие опции для «kill» чтобы завершить процесс принудительно:

где «-9» — это флаг относится к сигналу SIGKILL.

Если вы не знаете какой нужно использовать PID приложения которого следует избавиться, то запустите команду:

А если знаете конкретное приложение (например apache), то можно отсеять ненужное и вывести все процессы по данной службе:

И это отобразит все запущенные приложения вместе с его PID-ом(ами).

Стоит также отметить, что вы можете использовать несколько процессов одновременно чтобы их можно было » убить»:

Перезагурзить конфигурационные файлы или перезапуск утилит:

Особенно полезными сигналы включают HUP, INT, kill, STOP, CONT, и 0.

-s signal_name
Символическое имя сигнала, задающее сигнал для отправки сигнала не по умолчанию.

-l [exit_status]
Если операнд не указан, то показать имена сигналов; В противном случае, написать название сигнала, соответствующего exit_status.

-signal_name
Символическое имя сигнала, задающее сигнал для отправки в TERM по умолчанию.

-signal_number
Неотрицательное десятичное целое, задающее сигнал для отправки в TERM по умолчанию.

Следующие PID-ы, имеют особое значение:
-1 Если суперпользователь, то транслирует сигнал всем процессам; в противном случае вещает на все процессыbelong-
ing для пользователя.

Некоторые из наиболее часто используемых сигналов:

PKill

Так как он соответствует шаблону регулярного выражения, вы также можете ввести часть имени процесса, например:

Pkill команда имеет гораздо больше вариантов, например если указать опцию «-u», то она позволит вам указать имя пользователя или ID. В этом примере мы посылаем сигнал TERM всем процессам, принадлежащие пользователю ‘nobody’:

Killall

В Gnome, вы можете перезапустить Nautilus с помощью команды:

xkill

Xkill является графическим способом «убить» приложение. При вводе «XKill» в терминале, курсор мыши будет немедленно стать «крест». Все, что вам нужно сделать, это нажать «крест» на провинившихся приложение и он убьет приложение мгновенно. Если вы заинтересованы, вы можете добавить сочетание клавиш для включения функции XKill.

Еще сигналы которые используются

SIGABRT

Этот сигнал посылает сигнал процессу, чтобы прервать операцию. ABRT как правило, направлен на сам процесс, когда он вызывает функцию abort() языка программирования С, чтобы сигнализировать аварийное завершение, но он может быть направлен из любого процесса, как и любой другой сигнал.

SIGALRM, SIGVTALRM и SIGPROF

ALRM, VTALRM и / или сигнал PROF отправляется процессу, когда лимит времени, указанный при вызове функции сигнализации (например, setitimer) истекает.

ALRM

Посылается, когда настоящее время или часы с течением времени.

VTALRM

Посылается, когда процессорное время, используемое в процессе истечет.

PROF

Посылается, когда процессорное время, используемое процессом и системы от имени процесса истекает.

SIGBUS

BUS сигнал посылает процессу, когда это приводит к ошибке шины. Условия, которые приводят к данному сигналу, например, неправильное выравнивание доступа к памяти или отсутствие физического адреса.

SIGCHLD

Сигнал CHLD отправляет процессу, когда дочерний процесс завершается, прерывается или возобновляется после прерывания. Один из распространенного использование сигнала — это дать сигнал ОС на очистку ресурсов, которые используются в процессе дочернего процесса после его окончания без явного системного вызова.

SIGCONT

Сигнал CONT инструктирует операционную систему, и дает сигнал перезапустить процесс который ранее был приостановлен в режиме СТОП или сигнала TSTP. Одной из важных особенностей этого сигнала является контроль работы в оболочке Unix.

SIGFPE

Сигнал FPE посылает процессу, когда он выполняет ошибочное, арифметические срабатывания, например, такие как деление на ноль.

SIGHUP

Сигнал HUP посылает процессу, когда его управляющий терминал закрыт. Первоначально он был разработан, чтобы уведомить процесс после последовательного падения линии (HUP ответственный за «зависания»). В современных системах, этот сигнал обычно означает, что контроль псевдо или виртуальным терминалом был закрыт.

SIGILL

ILL сигнал, посылаемый процессу при попытке выполнить вредоносные, неизвестные или привилегированные команды (инструкции).

SIGINT

Сигнал INT посылает процессу от управляющего терминала, когда пользователь желает прервать процесс. Это как правило, инициируется нажатием Control-C, но на некоторых системах, «delete» или «break».

SIGKILL

Сигнал KILL посылает процессу чтобы он немедленно прекратил работу. В отличие от SIGTERM и SIGINT этот сигнал не может быть захвачен или проигнорирован и принимающий процесс не может выполнить какие-либо очистку после получения этого сигнала.

SIGPIPE

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

SIGQUIT

QUIT сигнал посылается процессу от его управляющего терминала, когда пользователь запрашивает процесс выполнения дампа.

SIGSEGV

Сигнал SEGV отправляется в процесс, когда он делает недопустимую ссылку виртуальной памяти или сбой сегментации, то есть когда он выполняет нарушение сегментации.

SIGSTOP

STOP сигнал указывает ОС, чтобы остановить процесс для последующего возобновления.

SIGTERM

Сигнал TERM посылается в процесс чтобы запросить о его прекращении. В отличие от сигнала «kill», он может быть и интерпретируемым или игнорируемым в процессе. Это позволяет процессу выполнять «nice» выполнение для прекращения высвобождения ресурсов и сохранения состояния в случае необходимости. Следует отметить, что SIGINT почти идентичен SIGTERM.

SIGTSTP

Сигнал TSTP посылается в процесс его управляющего терминала и говорит ему, что нужно временно приостановить. Это обычно инициируется пользователем нажатием Control-Z. В отличие от SIGSTOP, этот процесс может зарегистрировать обработчик сигнала или чтобы игнорировать сигнал.

SIGTTIN и SIGTTOU

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

SIGUSR1 и SIGUSR2

Сигналы USR1 и USR2 отправляются процессу и указывают определенные пользователем условия.

SIGPOLL

Сигнал POLL отправляется в процессе, когда происходит асинхронное событие ввода / вывода.

SIGSYS

Сигнал SYS отправляется в процессе, когда он пропускает плохой аргумент для системного вызова.

SIGTRAP

TRAP сигнал посылает процессу когда возникает состояние что отладчик просил быть информированным — Например, когда конкретная функция выполняется или когда меняется определенное значение переменной.

SIGURG

Сигнал URG отправляется процессу, когда socket имеет срочные или вне диапазона данных, доступных для чтения.

SIGXCPU

Сигнал XCPU отправляется в процессе, когда он использует центральный процессор в течение времени превышающего определенное заданное значение, установленным пользователем. Прибытие сигнала XCPU обеспечивает процессу быстро сохранить все промежуточные результаты и завершиться хорошо, прежде чем он завершиться операционной системы с помощью сигнала SIGKILL.

SIGXFSZ

Сигнал XFSZ отправляется в процессе, когда файл вырастает (превышает заданное значение), чем максимально допустимое значение.

SIGRTMIN to SIGRTMAX

Сигналы RTMIN — RTMAX предназначены для использования в пользовательских целей. Они сигналы реального времени.

Разные сигналы

Следующие сигналы не стандартизированы POSIX, но иногда используются на некоторых системах.

SIGEMT

Сигнал ЕМТ отправляется в процессе, когда происходит прерывание эмулятора.

SIGINFO

Сигнал INFO отправляется в процессе, когда запрос статуса получен от управляющего терминала.

SIGPWR

Сигнал PWR отправляется в процессе, когда система испытывает сбой питания.

SIGLOST

LOST сигнал посылается к процессу, когда «file lock» теряется.

SIGWINCH

Сигнал WINCH отправляется в процессе, когда его управляющий терминал меняет свой размер.

Отправка сигналов с клавиатуры

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

CTRL-C

Отправить SIGINT (прерывание). По умолчанию это вызывает процесс прекращается.

CTRL-Z

Отправить SIGTSTP (Suspend). По умолчанию это вызывает процесс приостановить все операции.

CTRL-\

Отправить SIGQUIT (Quit). По умолчанию это вызывает процесс прекратить немедленно и сбросить ядро.

CTRL-T

Отправить SIGINFO (INFO). По умолчанию это заставляет операционную систему отображать информацию о команде. Не поддерживается на всех системах.

вывод

Когда приложения ведут себя неправильно и вызвают к зависанию системы, это очень заманчиво, чтобы перезагрузить компьютер и начать сеанс снова и снова. С помощью этих команд «kill», вы сможете лучше управлять плохим поведением приложений которые вызывают или могут вызвать крах системы. На этом, я завершаю данную тему «Команда kill в Unix/Linux».

Добавить комментарий Отменить ответ

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

Источник