Иногда, когда я пишу программу в Linux, и она выходит из строя из-за какой-то ошибки, она становится непрерывным процессом и будет продолжаться до тех пор, пока я не перезагружу свой компьютер (даже если я выйду из системы). Мои вопросы:
Непрерывный процесс - это процесс, который находится в системном вызове (функция ядра) и не может быть прерван сигналом.
Чтобы понять, что это значит, вам нужно понять концепцию прерываемого системного вызова. Классический пример - read(). Это системный вызов, который может занять много времени (секунд), поскольку он может включать в себя раскрутку жесткого диска или перемещение головок. В течение большей части этого времени процесс будет находиться в спящем режиме, блокируя аппаратное обеспечение.
Пока процесс спит в системном вызове, он может получить асинхронный сигнал Unix (скажем, SIGTERM), тогда происходит следующее:
Ранний возврат из системного вызова позволяет коду пользовательского пространства немедленно изменить свое поведение в ответ на сигнал. Например, завершается чисто в ответ на SIGINT или SIGTERM.
С другой стороны, некоторые системные вызовы не могут быть прерваны таким образом. Если по какой-либо причине система вызывает остановку, процесс может оставаться в этом состоянии до бесконечности.
LWN опубликовала хорошую статью, которая затрагивала эту тему в июле.
Чтобы ответить на оригинальный вопрос:
Как предотвратить это: выясните, какой драйвер доставляет вам неприятности, и либо прекратите использование, либо станьте хакером ядра и исправьте его.
Как убить непрерывный процесс без перезагрузки: как-то заставить системный вызов завершиться. Часто наиболее эффективный способ сделать это, не нажимая на выключатель питания, это тянуть за шнур питания. Вы также можете стать хакером ядра и заставить драйвер использовать TASK_KILLABLE, как описано в статье LWN.
Когда процесс находится в пользовательском режиме, его можно прервать в любое время (переход в режим ядра). Когда ядро возвращается в пользовательский режим, он проверяет наличие ожидающих сигналов (включая те, которые используются для уничтожения процесса, например SIGTERM и SIGKILL). Это означает, что процесс может быть убит только при возврате в пользовательский режим.
Причина, по которой процесс не может быть убит в режиме ядра, заключается в том, что он может потенциально повредить структуры ядра, используемые всеми другими процессами на одном компьютере (так же, как убить поток может потенциально повредить структуры данных, используемые другими потоками в тот же процесс).
Когда ядру нужно сделать что-то, что может занять много времени (ожидание на трубке, написанном другим процессом или ожидающее, когда аппаратное обеспечение что-то сделает, например), он спит, отмечая себя как спящий и вызывающий планировщик переключитесь на другой процесс (если нет процесса без сна, он переключается на процесс "dummy", который сообщает процессору замедлить бит и сидит в цикле цикла).
Если сигнал отправляется в спящий процесс, его нужно разбудить, прежде чем он вернется в пространство пользователя и, таким образом, обработает ожидающий сигнал. Здесь мы имеем различие между двумя основными типами сна:
TASK_INTERRUPTIBLE, прерывистый сон. Если задача отмечена этим флагом, она спит, но может быть разбужена сигналами. Это означает, что код, обозначающий задачу как спящий, ожидает возможного сигнала, и после того, как он просыпается, он проверит его и вернется с системного вызова. После обработки сигнала системный вызов может быть автоматически перезапущен (и я не буду вдаваться в подробности о том, как это работает).TASK_UNINTERRUPTIBLE, непрерывный сон. Если задача отмечена этим флагом, она не ожидает, что ее разбудят что-либо, кроме того, что она ожидает, либо потому, что ее невозможно перезапустить, либо потому, что программы ожидают, что системный вызов будет атомарным. Это также можно использовать для сна, которые, как известно, очень короткие. TASK_KILLABLE (упоминается в статье LWN, связанной с ответом ddaa) - это новый вариант.
Это отвечает на ваш первый вопрос. Что касается вашего второго вопроса: вы не можете избежать бесцельных сна, это обычная вещь (это происходит, например, каждый раз, когда процесс читает/записывает с/на диск); однако они должны длиться всего лишь часть секунды. Если они длится намного дольше, обычно это означает аппаратную проблему (или проблему с драйвером устройства, которая аналогична ядру), когда драйвер устройства ожидает, что аппаратное обеспечение сделает что-то, чего никогда не произойдет. Это также может означать, что вы используете NFS, а сервер NFS недоступен (он ждет восстановления сервера, вы также можете использовать опцию "intr", чтобы избежать проблемы).
Наконец, причина, по которой вы не можете восстановить, по той же причине, что ядро ждет, пока не вернется в пользовательский режим, чтобы доставить сигнал или убить процесс: это потенциально повредило бы структуры данных ядра (ожидающий код в прерывистом сне может получить ошибку который говорит ему вернуться в пространство пользователя, где процесс может быть убит, ожидающий в режиме бесперебойного сна ожидания код не ожидает никакой ошибки).
Бесперебойные процессы в USUALLY ждут ввода/вывода после сбоя страницы.
Рассмотрим это:
Процесс/задача не может быть прервана в этом состоянии, поскольку он не может обрабатывать какие-либо сигналы; если бы это произошло, произошла ошибка другой страницы, и она вернется туда, где она была.
Когда я говорю "процесс", я действительно имею в виду "задачу", которая под Linux (2.6) грубо переводит на "поток", который может иметь или не иметь отдельную запись "группы потоков" в /proc
В некоторых случаях он может долго ждать. Типичным примером этого будет то, что исполняемый файл или файл mmap'd находятся в сетевой файловой системе, где сервер потерпел неудачу. Если сбой ввода-вывода будет завершен, задача будет продолжена. Если он в конечном итоге не удастся, задача, как правило, получит SIGBUS или что-то еще.
Возможно ли, что программа может быть записана для инициирования процесса, который переходит в состояние TASK_UNINTERUPTIBLE всякий раз, когда система не находится в состоянии ожидания, тем самым принудительно собирает данные, ожидая передачи после выхода супер пользователя? Это было бы золотым моментом для хакеров для получения информации, возврата в состояние зомби и передачи информации через сеть на холостом ходу. Некоторые могут утверждать, что это один из способов создания Blackdoor для полномочий, которые должны быть, для входа и выхода из любой системы по желанию. Я твердо верю, что эта лазейка может быть запечатана навсегда, устраняя состояние TASK_UNINTERUPTIBLE.
Я рассматриваю это как серьезную, но тонкую проблему безопасности для Linux-систем, которые имеют репутацию безопасности благодаря расширению полномочий суперпользователя. Тем не менее, я работаю над тем, чтобы стать хакером. Я думаю, что есть хакеры ядра, которые могут исправить этот фиаско.
К вашему третьему вопросу:
Я думаю, вы можете убить непрерывные процессы, запустив
sudo kill -HUP 1.
Он перезапустит init, не закончив запущенные процессы, и после его запуска мои непрерывные процессы исчезли.
Если вы говорите о процессе "зомби" (который обозначается как "зомби" в выпуске ps), то это безобидная запись в списке процессов, ожидающая, когда кто-то соберет код возврата, и ее можно было бы безопасно игнорировать.
Не могли бы вы описать, что и "непрерывный процесс" для вас? Выживает ли он "убить -9" и счастливо ли цепляется? Если это так, то он застрял на каком-то системном компьютере, который застрял в каком-то драйвере, и вы застряли в этом процессе до перезагрузки (а иногда и лучше перезагрузить) или разгрузки соответствующего драйвера (что вряд ли произойдет), Вы можете попытаться использовать "strace", чтобы узнать, где ваш процесс застрял и избежать его в будущем.