Что такое непрерывный процесс?

Иногда всякий раз, когда я пишу программу в Linux, и она выходит из строя из-за какой-то ошибки, она становится непрерывным процессом и продолжается до тех пор, пока я не перезагружу свой компьютер (даже если я выйду из системы). Мои вопросы:

• Что заставляет процесс становиться непрерывным?
• Как мне остановить это?
• Вероятно, это глупый вопрос, но есть ли способ прервать его, не перезагружая мой компьютер?

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

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

Пока процесс спит в системном вызове, он может получить асинхронный сигнал Unix (скажем, SIGTERM), тогда происходит следующее:

• Системные вызовы завершаются преждевременно и настроены на возврат -EINTR в пространство пользователя.
• Обработчик сигнала выполнен.
• Если процесс все еще выполняется, он получает возвращаемое значение из системного вызова и может повторить тот же вызов.

Ранний возврат из системного вызова позволяет коду пользовательского пространства немедленно изменить свое поведение в ответ на сигнал. Например, завершается чисто в ответ на SIGINT или SIGTERM.

С другой стороны, некоторые системные вызовы не могут быть прерваны таким образом. Если система по какой-либо причине вызывает остановку, процесс может оставаться в этом состоянии до бесконечности.

LWN опубликовала хорошую статью, которая затрагивала эту тему в июле.

Чтобы ответить на оригинальный вопрос:

• Как предотвратить это: выясните, какой драйвер доставляет вам неприятности, и либо прекратите использование, либо станьте хакером ядра и исправьте его.

• Как убить непрерывный процесс без перезагрузки: как-то заставить системный вызов завершиться. Часто наиболее эффективный способ сделать это, не нажимая на выключатель питания, это тянуть за шнур питания. Вы также можете стать хакером ядра и заставить драйвер использовать TASK_KILLABLE, как описано в статье LWN.

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

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

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

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

• TASK_INTERRUPTIBLEПрерванный сон. Если задание помечено этим флагом, оно спит, но может быть разбужено сигналами. Это означает, что код, пометивший задачу как спящий, ожидает возможного сигнала, а после его запуска проверит его и вернется из системного вызова. После обработки сигнала системный вызов может быть автоматически перезапущен (и я не буду вдаваться в подробности о том, как это работает).
• TASK_UNINTERRUPTIBLEНепрерывный сон. Если задача помечена этим флагом, она не ожидает, что ее разбудит что-либо, кроме того, что она ожидает, либо потому, что ее нелегко перезапустить, либо потому, что программы ожидают, что системный вызов будет атомарным. Это может также использоваться для снов, которые, как известно, очень короткие.

TASK_KILLABLE (упоминается в статье LWN, на которую ссылается ответ ddaa) - это новый вариант.

Это отвечает на ваш первый вопрос. Что касается вашего второго вопроса: вы не можете избежать непрерывных снов, они нормальные (это происходит, например, каждый раз, когда процесс читает / пишет с / на диск); тем не менее, они должны длиться лишь доли секунды. Если они длятся намного дольше, это обычно означает проблему с оборудованием (или проблему с драйвером устройства, которая выглядит так же для ядра), когда драйвер устройства ждет, пока оборудование сделает что-то, что никогда не произойдет. Это также может означать, что вы используете NFS, а сервер NFS не работает (он ожидает восстановления сервера; вы также можете использовать опцию «intr», чтобы избежать проблемы).

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

Непрерывные процессы обычно ожидают ввода-вывода после сбоя страницы.

Учти это:

• Поток пытается получить доступ к странице, которая не находится в ядре (или исполняемый файл, который загружен по требованию, страница анонимной памяти, которая была выгружена, или файл mmap () d, который загружен по требованию, которые во многом то же самое)
• Ядро сейчас (пытается) загрузить его в
• Процесс не может продолжаться, пока страница не станет доступной.

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

Когда я говорю «процесс», я действительно имею в виду «задачу», которая в Linux (2.6) примерно переводится как «нить», которая может иметь или не иметь отдельную запись «группы потоков» в / proc

В некоторых случаях это может ждать долго. Типичным примером этого является случай, когда исполняемый файл или файл mmap'd находятся в сетевой файловой системе, где произошел сбой сервера. Если ввод / вывод в конце концов завершится успешно, задача продолжится. Если это в конечном счете терпит неудачу, задача обычно получает SIGBUS или кое-что.

На ваш третий вопрос: я думаю, что вы можете убить непрерывные процессы, запустив sudo kill -HUP 1. Он перезапустит init без остановки запущенных процессов, и после его запуска мои бесперебойные процессы исчезли.

Если вы говорите о процессе «зомби» (который обозначен как «зомби» в выводе ps), то это безвредная запись в списке процессов, ожидающая, когда кто-то соберет код возврата, и ее можно было бы безопасно проигнорировать.

Не могли бы вы описать, что и для вас означает "непрерывный процесс"? Выживает ли он после «убить -9» и радостно пыхтит? Если это так, то он застрял на каком-то системном вызове, который застрял в каком-то драйвере, и вы застряли с этим процессом до перезагрузки (а иногда лучше перезагрузить в ближайшее время) или выгрузки соответствующего драйвера (что вряд ли произойдет) , Вы можете попытаться использовать «strace», чтобы узнать, где застрял ваш процесс, и избежать этого в будущем.