эхо с | sudo tee / proc / sysrq-trigger вызывает сбой, и система не перезагружается
Я изучаю Руководство по серверу из Ubuntu и не могу решить эту проблему.
Я выполняю следующие действия:
sudo -s
[sudo] password for ubuntu:
# echo c > /proc/sysrq-trigger
[ 31.659002] SysRq : Trigger a crash
[ 31.659749] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 31.662668] IP: [<ffffffff8139f166>] sysrq_handle_crash+0x16/0x20
[ 31.662668] PGD 3bfb9067 PUD 368a7067 PMD 0
[ 31.662668] Oops: 0002 [#1] SMP
[ 31.662668] CPU 1
Я тоже сделал sudo sysctl -w kernel.sysrq=1
Но экран остается замороженным, и система не перезагружается. Я могу перезагрузить систему вручную, но после перезагрузки ls /var/crash ничего не возвращает.
Как я могу это исправить?
2 ответа
Это то, что он должен делать.
Может потребоваться очень много времени для сервера, чтобы сбросить оперативную память, и в зависимости от вашего хоста они могут «поймать» его и сделать что-то странное с ним. Мой совет, "перестань с ним связываться".
Команда вызывает панику ядра. Ничего более. Все эти дополнительные вещи настраиваются и не очень надежны. Ваш хостинг-провайдер может поймать это (особенно если это что-то вроде Amazon EC2, где они создают свои собственные ядра и базовые образы).
Лучше всего поймать панику ядра производственного уровня с помощью какого-либо мониторинга хоста. Я использую и рекомендую Nagios. Когда сервер перестает отвечать в производственной среде, перезагрузка НИКОГДА НИКОГДА не дает ответа. Тестирование и построение протокола для этого типа обработки паники в ядре просто заставит вас потерпеть неудачу самым впечатляющим образом.
Если вам нужны системные журналы или журналы сбоев, обратите внимание на использование удаленных функций системного журнала.
Короче говоря, из хостинга 101, если вы не можете позволить себе простоя, не полагайтесь на дешевые приемы, такие как автоматическая перезагрузка, настройку правильного решения для мониторинга хоста и кластера.
Я сделал ту же команду, и это вызвало у меня панику в ядре. Поэтому решите зайти в Google и найти интересную информацию.
Мы вызываем сбой теста ядра, когда выполняем эту команду
echo c | sudo tee /proc/sysrq-trigger
Согласно документации по Ubuntu
Если все работает, там должно быть будет некоторая задержка (в зависимости от объема памяти). Затем система снова перезагружается в обычный режим. Обычно apport запускает и спрашивает о сообщении о проблеме. Кроме того, файл отчета можно найти в / var / crash и либо поместить в другое место, либо снова распаковать, вызвав:
#> apport-unpack <report file> <target directory>Все зависит от объема памяти. Я буду искать, сколько времени это займет для компьютера с 4 ГБ оперативной памяти. В моем случае я перезагружаю систему вручную, но это было менее чем за 2 минуты. Надеюсь, это поможет.