Ubuntu 14.04 случайным образом замораживается после длительных периодов и сбоев к перезагрузке автоматически (crontab)

В течение некоторого времени теперь у меня были проблемы с моей установкой человечности 14.04 на моем собранном ПК. Основной компонент является материнской платой, ASRock Q1900M Pro3, поршнем на 4 ГБ и двумя PCI sata контроллеры.

Я использую этот компьютер в качестве домашнего сервера, основные функции являются совместным доступом к файлам (самба), локальный веб-сервер (ЛАМПА), bittorrent загрузчик (Tixati) и "мультиплексирование станции" (потому что мне нужен он, не спрашивайте). К тому же я использую для просмотра веб-страниц каждый раз, когда я не чувствую, что должен включить свой основной ПК, который использует в 3 раза больше электричества, в то время как неактивный.

Я не могу установить серверную версию человечности, потому что Tixati не работал бы и просмотр Интернета, и мультиплексирование будет трудной задачей. Также настольная среда в целом является путем, более применимым, чем командная строка.

У меня есть 2 вида проблем:

  • машина случайным образом прекращает работать после довольно значительного включаемого промежутка времени и работающий (проблемы происходят приблизительно после 24 + часы времени работы, иногда еще раньше). Замораживание происходит большинство времен, когда я не использую непосредственно ПК, но в 2-3 раза, когда заморозилось, в то время как я давал вход. Эффект состоит в том, что экран замораживается к последнему кадру, который он обрабатывает (я предполагаю), и ЛЮБОЙ тип входа проигнорирован. Я также заметил, что это отключается от локальной сети, но светодиоды Ethernet все еще работают со ссылкой зеленый светодиод всегда на и оранжевое действие одно мигание некоторыми без любой определенной частоты (можно сказать случайным образом). От dd-wrt маршрутизатора I видят, что хост разъединяется и если я пытаюсь проверить с помощью ping-запросов ПК, я получаю 100%-ю потерю пакетов (сверх снижающейся доли самбы). Действие жесткого диска, ведомое также, не закрывает глаза на все в этом состоянии. Единственным путем я могу перезагрузить машину, твердый путь (удерживающий кнопку питания в нажатом состоянии). Когда я иду для проверки dmesg файла журнала, я не могу найти подозрительную запись перед замораживанием, в прошлый раз, когда это произошло, последняя запись была crontab выполнение автоматического задания, но другие времена, это делало что-то еще, как блокирование ufw. Экран никогда не деактивируется так, я вижу последнюю вещь, прежде чем заморозится; я никогда не видел сообщений об ошибках никакого вида, единственная нечетная вещь, которую я заметил, состояла в том, что одно время, экран был совершенно сер, и я не оставил его тем путем.
  • Для решения этой проблемы, я думал, что, возможно, если бы я сделал ее автоматически, перезагрузка один раз в день с помощью crontab решила бы проблему, но именно здесь я встретился со второй проблемой, о которой я хочу сказать Вам. Вторая проблема состоит в том, что большинство времен crontab перезагружает ПК, он завершил бы работу его успешно, но он приведет последовательную начальную загрузку к сбою, оставляя систему, зависающую в неопределенности между концом личинки и запуском загрузки из жесткого диска для трамбовки. Это просто остается там с фиолетовым экраном, не показывая сообщений, даже если я использую "текстовую" опцию (или удаляющий тихий всплеск) в личинке (да, делая личинку обновления после изменений в файле). Забавная часть - то, что от того состояния я должен завершить работу твердого пути, и когда я включаю его снова, последовательность начальной загрузки работает просто великолепно, личинка подходит, входит, выбранная опция после 10 secs (запускайте человечность обычно), и начальные загрузки системы со всем ядром, переданным, показывая правильно и быстро. Я попробовал инструмент начальной загрузки восстановления автоматическая опция фиксации, он работал на 4-5 автоматических перезагрузок, но по некоторым причинам он не будет больше работать, даже если я выполню его снова.

вот является восстановление начальной загрузки начальным анализом http://paste.ubuntu.com/12589606/

вот является dmesg файл журнала http://paste.ubuntu.com/12632375/

  • строка 1192: системное замораживание вызвало перезагрузку-> никакие зарегистрированные ошибки
  • строка 2399: сбой автоматической перезагрузки, зависания системы между личинкой и загружающимися файлами в поршень-> никакие зарегистрированные ошибки
  • строка 5423: ручная перезагрузка для установки обновлений, зависаний системы между личинкой и загружающимися файлами в поршень-> никакие зарегистрированные ошибки

галерея моих настроек BIOS: работа над ним

видео поведения ПК, когда в состоянии замораживания: работа над ним

видео ПК, приводя автоматическую перезагрузку к сбою: работа над ним

сообщите мне, нужна ли Вам дополнительная информация.Спасибо за помощь.

1
задан 1 October 2015 в 19:49

1 ответ

Это не полный ответ. Так как у Вас есть сделанная в домашних условиях система, я прочитал эти dmesg дамп с набором Паранойи к Высокому, и набором фильтра Беспорядка к Низкому (Очень параноидальный, Легко перепутанный в виртуальном меня), и нашел несколько объектов интересным:

Это могло быть проблематичным, необходимо заняться расследованиями.

623 Sep 30 07:43:26 ubuntu-server kernel: [    0.907105] hpet: number irqs doesn't agree with number of timers

Рассматривают установку thermald.

672 Sep 30 07:43:26 ubuntu-server kernel: [    0.998865] Consider also installing thermald for improved thermal control.

Это - то, которое я действительно подозреваю. Какие процессы Вы выполняете в "Реальное время"? Если Оперативный процесс теряет его ум, это может использовать ВЕСЬ ЦП и похожим на Вашу проблему, о которой сообщают. (так был бы внезапный H/W spaz). Вы могли работать некоторое время без rtkit?

1086 Sep 30 07:43:41 ubuntu-server rtkit-daemon[2012]: Successfully called chroot.
1087 Sep 30 07:43:41 ubuntu-server rtkit-daemon[2012]: Successfully dropped privileges.
1088 Sep 30 07:43:41 ubuntu-server rtkit-daemon[2012]: Successfully limited resources.
1089 Sep 30 07:43:41 ubuntu-server rtkit-daemon[2012]: Running.
1090 Sep 30 07:43:41 ubuntu-server rtkit-daemon[2012]: Watchdog thread running.
1091 Sep 30 07:43:41 ubuntu-server rtkit-daemon[2012]: Canary thread running.

1093 Sep 30 07:43:41 ubuntu-server rtkit-daemon[2012]: Successfully made thread 2010 of process 2010 (n/a) owned by '1000' high priority at nice level -11.
1094 Sep 30 07:43:41 ubuntu-server rtkit-daemon[2012]: Supervising 1 threads of 1 processes of 1 users.

1097 Sep 30 07:43:42 ubuntu-server rtkit-daemon[2012]: Successfully made thread 2083 of process 2010 (n/a) owned by '1000' RT at priority 5.
1098 Sep 30 07:43:42 ubuntu-server rtkit-daemon[2012]: Supervising 2 threads of 1 processes of 1 users.
1099 Sep 30 07:43:42 ubuntu-server rtkit-daemon[2012]: Successfully made thread 2084 of process 2010 (n/a) owned by '1000' RT at priority 5.
1100 Sep 30 07:43:42 ubuntu-server rtkit-daemon[2012]: Supervising 3 threads of 1 processes of 1 users.

проблема в системе регистрации? Закрепите это на общих принципах.

3293 Oct  1 08:02:11 ubuntu-server rsyslogd-2039: Could no open output pipe '/dev/xconsole': No such file or directory [try http://www.rsyslog.com/e/2039 ]

И это - нормальное завершение работы:

3935 Oct  1 08:10:42 ubuntu-server rsyslogd: [origin software="rsyslogd" swVersion="7.4.4" x-pid="967" x-info="http://www.rsyslog.com"] exiting on signal 15.

Для получения ближе к наблюдению последней записи перед крешлогом запустите это в оболочке (таким образом, это автоматически не перезапустит):

# set nap to sleep time (GNU sleep takes floating point values)
nap=2.5
# forever, or until the world ends
while [[ : ]] ; do
    dmesg -T >logfile
    sleep $nap
done

После катастрофического отказа, проверьте дату модификации и содержание logfile. Увеличьте значение $nap, чтобы уменьшить нагрузку на систему этим, уменьшить значение для хранения dmesg ближе ко времени катастрофического отказа (за счет большего количества загрузки). Но это - временная отладка, таким образом, Вы не заботитесь очень о загрузке. Будьте изделием что между dmesg -T >logfile и данные, сохраняемые на диске, существуют издержки, буферизация, и т.д. Если система отказывает, прежде чем данные добираются полностью до диска, это будет потеряно, но отладка аппаратных средств и/или Реальное время трудна.

0
ответ дан 1 October 2019 в 00:48

Другие вопросы по тегам:

Похожие вопросы: