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

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

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

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

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

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

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

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

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

бесперебойные процессы обычно ждут ввода-вывода после ошибки страницы.

рассмотрим следующий пример:

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

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

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

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

возможно ли, что программа может быть написана, чтобы инициировать процесс, который идет в TASK_UNINTERUPTIBLE состояние, когда система не находится в состоянии ожидания, тем самым принудительно собирая данные, ожидая передачи после выхода суперпользователя? Это было бы золотой жилой для хакеров, чтобы получить информацию, вернуться в состояние зомби и передать информацию через сеть на холостом ходу. Некоторые могут утверждать, что это один из способов создания Blackdoor для власть имущих, для входа и выхода любой системы, как желанный. Я твердо верю, что эта лазейка может быть запечатана навсегда, устранив TASK_UNINTERUPTIBLE государство.

Я рассматриваю это как серьезную, но тонкую проблему безопасности для систем Linux, которые имеют репутацию безопасности, благодаря расширению возможностей суперпользователя. Я работаю над тем, чтобы стать хакером ядра, однако я думаю, что есть хакеры ядра, которые могут исправить это фиаско.

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

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

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