Какие существуют риски при остановке и возобновлении процессов в Linux?

Question

Допустим, я остановил процесс с помощью Ctrl+Z и возобновил его через пять часов с помощью fg . Насколько это рискованно в отношении правильного функционирования процесса?

Например, представьте, что vim работает над записью большого файла на диск, и я остановил его во время записи. Удастся ли vim без проблем написать файл, когда я его возобновлю? Как чрезвычайная ситуация, что произойдет, если я удалю файл за это время? Могу ли я в конечном итоге повредить файловую систему? (Возможно ли даже удаление файла, который записывал остановленный vim , или драйверы файловой системы не позволят мне удалить файл, пока vim не закончит запись в него?)

Очевидно, что vim - это относительно простая программа, являющаяся "просто" текстовым редактором. Могу ли я остановить и возобновить сложные части программного обеспечения, такие как apache или X11 не ожидая слишком много проблем (кроме времени ожидания клиентов, в случае Apache)?

Answer 1

По сути, Ctrl-Z не представляет опасности. Ты не должен этого бояться.

Что именно произойдет, зависит от того, что делает процесс. Ваши примеры хороши для рассмотрения.

Во-первых, когда vim пишет файл ... ничего плохого не произойдет. Если при возобновлении работы vim все еще остается свободное место на диске, он завершит запись файла. Если вы убьете vim, пока он приостановлен, файл будет усечен с таким количеством данных, которое было записано до его приостановки (в любом случае, насколько вам это нужно). Если вы удалите файл, когда vim приостановлен, по сути, vim продолжит видеть файл столько, сколько ему нужно. Снаружи vim файл будет считаться удаленным, но vim будет видеть его до тех пор, пока не закончит запись, и закроет его, после чего он исчезнет. (Если vim попытается открыть его снова, оно исчезнет.) После того, как вы привыкли к этому последнему поведению, вы чувствуете, что используете глупую игрушку, когда Windows блокирует файлы.

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

Apache перестанет обслуживать веб-страницы, очевидно. X11 перестанет толкать пиксели вокруг. Но, как правило, когда вы запускаете его снова, все, что блокировалось, возобновляется, и, если время ожидания истекло, если вы перезапустите их, они тоже будут работать нормально.

Answer 2

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

Что касается второго вопроса, касающегося удаления файла, когда программа все еще "работает", см. Вопрос «Когда rm удаляет открытые файлы?"

Answer 3

В основном это зависит от программы. С помощью vim(1) (или с помощью vi (1)) вы можете даже убить его, так что у вас будет возможность восстановить файл до момента уничтожения без потери данных, даже если вся система потерпела крах (посмотрите на справочная страница vi (1)/vim(1))

В общем, остановка программы на пять часов может иметь некоторые побочные эффекты, которые могут повредить все, что вы делаете.

Предположим, что открытая вами программа является сетевым клиентом (например, сеанс ssh (1) с другой машиной). Обычно серверы активируют опцию TCP под названием SO_KEEPALIVE, которая позволяет поддерживать соединение в активном состоянии , даже если вам нечего сказать. В этом случае это не помешает, так как ядро, имея открытое TCP-соединение, делает KEEPALIVE от имени остановленного процесса (tcp-соединения - это ресурсы ядра, а не пользовательские ресурсы процесса), и вы можете поддерживать процесс остановленным бесконечно.

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

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