Как предотвратить процесс от остановки?

Почему будет убито?

Потому что это не автоматически, что-то убито. Когда вы ответите на это и объясните, почему что-то будет выбрано для уничтожения, вы сможете найти решение.

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

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

Вы не можете запретить root'у убивать процесс. Или в этом отношении: вы не можете запретить серверу уничтожать процесс, который пожирает все ваши ресурсы.

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

Пример использования кода:

• https://stackoverflow.com/a/6538718/2920227

Я понимаю, что это старый вопрос, но поскольку оба ответа игнорируют очевидное - или, в лучшем случае, поверхностно - я почувствовал побуждение написать свой собственный. Учитывая формулировку вопроса, первое, что пришло мне в голову, было «убийца OOM!». В одном из других ответов даже содержится утверждение, что «убивают что-то не автоматически», что абсурдно с точки зрения пользователя. Что такое убийца OOM, если не автоматизм?

Убийца OOM - ваш самый большой враг в сценариях, подобных описанному, как показано в связанной статье.

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

Ваш вопрос в разбивке:

Есть ли способ предотвратить завершение процесса несмотря ни на что?

Нет, к счастью нет. Например, ядро ​​уничтожит неправильно работающие процессы (например, отправив SIGSEGV ). Это также применимо, если ваша задача ведет себя неправильно из-за превышения ограничений ресурсов (см. limits.conf , getrlimit / setrlimit ).То есть, если что-то внутри вашей задачи rake (которая, по всей вероятности, будет использовать другие процессы для выполнения некоторой работы) разыменовывает нулевой указатель, вам все равно не повезло, и эта часть выйдет из строя, что впоследствии может провалить задачу.

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

Я знаю о nice , но не уверен, что если дать такой задаче, как длительное выполнение задачи rake , интенсивно использующей память, то наивысший приоритет, то это предотвратит ее завершение: [...]

Это не предотвратит этого, но будет использоваться как один из нескольких эвристик для убийцы OOM. Так что да, на самом деле значение nice поможет ... немного. Статья LWN , на которую я уже ссылался выше, дает следующую эвристику:

• если задача имеет значение nice выше нуля , ее оценка удваивается
• суперпользователь или прямой доступ к оборудованию ] задачи (CAP_SYS_ADMIN, CAP_SYS_RESOURCE или CAP_SYS_RAWIO) имеют оценку, разделенную на 4. Это совокупное значение, то есть задача суперпользователя с доступом к оборудованию будет иметь свой счет делится на 16.
• , если условие OOM произошло в одном процессоре и проверено задача не входит в этот набор, ее оценка делится на 8.
• полученный результат умножается на два в степени oom_adj (т. Е. points << = oom_adj, когда он положительный, и points >> = - (oom_adj) в противном случае)

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

1. mount -t cgroup -o oom oom / mnt / oom-killer
2. mkdir / mnt / oom-killer / invincibles
3. echo 0> /mnt/oom-killer/invincibles/oom.priority
4. echo > / mnt / oom-killer / invincibles / tasks , где - это идентификатор процесса вашей rake-задачи ...

Итак, поехали. Вы можете освободить определенные группы процессов от гнева убийцы OOM.

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

Если ничего из этого не работает, вам следует перейти на сайт Брендана Грегга и начать измерение различных показателей эффективности; также посмотри, сможешь ли ты взять одну из его книг. Например, возможно, у вас действительно возникла неконтролируемая ситуация с распределением памяти внутри вашей задачи rake . Потому что вы подчеркиваете длительное выполнение и интенсивное использование памяти , но они не обязательно связаны.BPF и друзья позволят вам получить информацию, которую вы иначе не получите.