Что такое непрерывный процесс?
Иногда, когда я пишу программу в Linux, и она выходит из строя из-за какой-то ошибки, она становится непрерывным процессом и будет продолжаться до тех пор, пока я не перезагружу свой компьютер (даже если я выйду из системы). Мои вопросы:
- Что заставляет процесс становиться непрерывным?
- Как мне остановить это?
- Это, вероятно, глупый вопрос, но есть ли способ прервать его, не перезагружая мой компьютер?
5 ответов
Непрерывный процесс - это процесс, который находится в системном вызове (функция ядра) и не может быть прерван сигналом.
Чтобы понять, что это значит, вам нужно понять концепцию прерывистого системного вызова. Классический пример 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 или кое-что.
Возможно ли, что программа может быть написана для запуска процесса, который входит в TASK_UNINTERUPTIBLE состояние, когда система не находится в режиме ожидания, что приводит к принудительному сбору данных в ожидании передачи после выхода суперпользователя? Это было бы золотой жилой для хакеров, чтобы получать информацию, возвращаться в состояние зомби и передавать информацию по сети в режиме ожидания. Некоторые могут утверждать, что это один из способов создания Blackdoor для полномочий, чтобы войти и выйти из любой системы по желанию. Я твердо верю, что эта лазейка может быть закрыта навсегда, устраняя TASK_UNINTERUPTIBLE государство.
Я рассматриваю это как серьезную, но тонкую проблему безопасности для систем Linux, которые имеют репутацию безопасности благодаря расширению полномочий суперпользователя. Я работаю над тем, чтобы стать Kernel Hacker, однако, я думаю, что есть хакеры ядра, которые могут исправить этот разгром.
На ваш третий вопрос: я думаю, что вы можете убить бесперебойные процессы, запустивsudo kill -HUP 1, Он перезапустит init без остановки запущенных процессов, и после его запуска мои бесперебойные процессы исчезли.
Если вы говорите о процессе "зомби" (который обозначен как "зомби" в выводе ps), то это безвредная запись в списке процессов, ожидающая, когда кто-то соберет его код возврата, и его можно было бы безопасно проигнорировать.
Не могли бы вы описать, что и для вас означает "непрерывный процесс"? Выживает ли он после "убить -9 " и радостно пыхтит? Если это так, то он застрял на каком-то системном вызове, который застрял в каком-то драйвере, и вы застряли с этим процессом до перезагрузки (а иногда лучше перезагрузить в ближайшее время) или выгрузки соответствующего драйвера (что вряд ли произойдет), Вы можете попытаться использовать "strace", чтобы узнать, где застрял ваш процесс, и избежать этого в будущем.