Ему написали в ответ что с этим делать.
Почему? Есть ведь другие классы шедулера, а там есть и иные приоритеты. Плюс, есть приоритеты CPU. Плохо уже то - что бекап и чекинг происходит не различаются приоритетами шедулера, на что я указал выше.
"Любой разумный человек" - не будет тупо плакаться "у меня не работает скрипт в конфигурации по-умолчанию", а разберется почему не работает и поправит это. Что именно сделать - я предложил варианты.
Забавно, вы стало быть Dimanych'а разумным не посчитали? - т.к. у него "остальные" процессы тоже с ionice запущены. Конкретно - проверка рейда.
Вас кто-то жестоко обманул. Все чуть сложнее, рассинхронизация не обязательно будет. man md, раздел UNCLEAN SHUTDOWN - читаем до просветления.
Отнюдь. Но лучше пользоваться им осознанно, не загоняя все тупо в один класс Idle.
Кстати, может иметь смысл поиграться и с приоритетами - выставить их там же, где и вызывается ionice. Редхетовский скрипт это делает.
Это вообще к кому вопрос был?
Может приоритеты-то имеет смысл выставить разные? Технически, там вообще-то выставлен не приоритет, а класс шедулера: -с3 не имеет приоритетов.
Глупо. Нужно решать проблему, а не плодить новые.
Выясните сперва что кому мешает и почему. Покрутите настройки бекапа и скрипта для проверок рейда, измените приоритеты.
Как вариант, тут есть решение для запуска инкрементальных проверок. По часику, во время наименьшей нагрузки - глядишь за несколько заходов и проверите.
С высокой вероятностью - у вас и нет рейда.
Замечал обратное. В отличие от - могу объяснить почему, в каких вариантах нагрузки.
Кто только подобное не делал - это говорит только в пользу умения сделать пакет "абы собралось". Его наличия я у вас и не отрицал.
"Личное делание" не отменяет того факта, что деб с nginx.org срет ошибками lintian при сборке. Список ваших пакетов в centos или debian в студию, тогда поговорим об умениях и знаниях.
Ядро. Так /proc работает.
А не будет никаких подводных камней у auditd с /proc?
Кому, интересно, вы пишете? :)
Было бы странно, если б оно перестало работать.
/ru/forum/comment/9796458
Собственно, даже "обновить PHP+mysql" - фактически эквивалентно "обновить все".
Да, CGI-интерепретатором. ПХП от этого "нестандартным" не станет - просто для отдельного сайта будет работать своя версия.
Может он работает для конкретного пути. Я упомянул это как вариант.
Работа PHP в качестве CGI-скрипта - стандартный функционал:
http://www.php.net/manual/en/install.unix.commandline.php
Оно типа и есть даром. Давайте за глаза не осуждать людей - ТС ведь не объяснил что входит в услугу администрирования, на каких условиях.
Ты скорее всего не знаком ни с тем не с другим, почему и троллишь о "прогрессивности".
Некоторые не берутся судить определенные вещи, имея с ними только шапочное знакомство (к примеру, просто нарисовав десяток спеков "абы собралось"). Вот и я не берусь судить rpm-ки от nginx.org - а о дебах написал как есть.
Просто они лучше знакомы с конкретным дистрибутивом, чем люди случайные...
Пакеты для centos от nginx.org ругать не берусь, а ихних дебах это заметно, мягко говоря. В проект они бы as-is не попали просто даже по формальным критериям.
Простите, в чем "костыль" использования стандартного функционала PHP?
Вы готовы отвечать за то, что обновление всего нафиг - не поломает ТС другие проекты? Я - нет, потому и не даю заочно советы подобное феерической тупости.
