Это - почти всегда плохой диск, у меня есть тысячи дисков, которые мы используем и хотя эти ошибки никогда не вызывают диск перестать работать, они привели к повреждению файловой системы. Я думаю, что это действительно имеет отношение к проблеме с платой контроллера на диске.
я попробовал все для решения этой проблемы, фиксация должна заменить диск и вещи работа над теми же кабелями и контроллерами.
Удача
Как предложено другим ответом, ядро Linux/proc/sys/kernel/core_pattern файл является хорошим местом для запуска: в http://www.mjmwired.net/kernel/Documentation/sysctl/kernel.txt#141
Как документация говорится, что можно указать специальный символ "|", который скажет ядру производить файл к сценарию. Как предложено Вы могли использовать |/bin/gzip-1>/var/crash/core-% t-% p-% u.gz как имя, однако это, кажется, не работает на меня. Я ожидаю, что причина состоит в том, который на моем системном ядре не рассматривает> символ как вывод, скорее это, вероятно, передает его в качестве параметра gzip.
для предотвращения этой проблемы, как другой предложенный, можно создать файл в некотором месте, я использую / домой//crash/core.sh, создайте его с помощью следующей команды, заменив пользователем. Кроме того, можно также, очевидно, изменить весь путь.
echo -e '#!/bin/bash\nexec /bin/gzip -f - >"/home/<username>/crashes/core-$1-$2-$3-$4-$5.gz"' > ~/crashes/core.sh
Теперь этот сценарий возьмет 5 входных параметров и свяжет их и добавит к базовому пути. Полные пути должны быть указаны в ~/crashes/core.sh. Также местоположение этого сценария может быть указано. Теперь позволяет, говорят ядру использовать туристический исполняемый файл с параметрами при генерации файла:
sudo sysctl -w kernel.core_pattern="|/home/<username>/crashes/core.sh %e %p %h %t"
Снова должен быть заменен (или весь путь для соответствия местоположению и названию core.sh сценария). Следующий шаг должен разрушить некоторую программу, позволяет, создают пример, отказывающий cpp файл:
int main (){
int * a = nullptr;
int b = *a;
}
После компиляции и выполнения там 2 опции, любой, которого мы будем видеть:
отказ Сегментации (выведенное ядро)
Или
отказ Сегментации
В случае, если мы видим последнего, существует немного возможных причин.
существует ошибка в сценарии, который мы записали, я предлагаю, чем проверка некоторого основного пути дампа к проверке, если другими вещами не является причина ниже, должен создать/tmp/core.dump:
sudo sysctl -w kernel.core_pattern="/tmp/core.dump"
я знаю, что уже существует ответ для этого вопроса однако, не было очевидно для меня, почему он не работает "из поля", таким образом, я хотел суммировать свои результаты, надеяться, что он помогает кому-то.