2

Я использую GNU/Linux Mint 18.3 с версией ядра 4.10.0-42. В течение последних нескольких недель, время от времени моя система зависает, без каких-либо признаков возможной проблемы (которую я заметил).

Я пробовал переключать версии ядра (раньше были 4.4.0 и 4.8.0), но безрезультатно.

Что я могу сделать, чтобы решить или обойти эту проблему?

Дополнительная информация

  • BIOS моей системы - «ASUS UEFI BIOS 3016.»
  • Мой рут находится на SSD, который не видел много действий записи
  • Зависания не начались (сразу) после некоторой перебои оборудования.
  • Кажется, никогда не бывает, когда я за компьютером, всегда или почти всегда, когда я далеко / сплю. Но, опять же, не всегда, то есть в большинстве дней этого не происходит.
  • Я запускаю XFCE со встроенной графикой, но у меня также есть nVIDIA GTX 650 Ti, не используемая для графики (которая простаивает, когда происходят такие зависания). Версия драйвера nVIDIA сейчас 387,26.
  • Когда происходит зависание, монитор продолжает отображать последнее изображение, но ничего не реагирует. Ctrl+Alt+Fn не работает, и компьютер не реагирует на сетевой трафик.

Моя машина

(Я добавлю любую дополнительную информацию ниже по запросу.)

/var/log/syslog до и после последнего зависания:

Jan  7 23:09:55 my_pc smartd[966]: Device: /dev/sda [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 70 to 69
Jan  7 23:39:55 my_pc smartd[966]: Device: /dev/sda [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 69 to 68
Jan  8 00:03:48 my_pc rsyslogd: [origin software="rsyslogd" swVersion="8.16.0" x-pid="947" x-info="http://www.rsyslog.com"] start
Jan  8 00:03:48 my_pc rsyslogd: rsyslogd's groupid changed to 108
Jan  8 00:03:48 my_pc rsyslogd: rsyslogd's userid changed to 104

/var/log/syslog до и после предпоследнего зависания:

Jan  7 16:07:49 my_pc smartd[933]: Device: /dev/sdd [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 111 to 112
Jan  7 16:37:49 my_pc smartd[933]: Device: /dev/sdc [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 58 to 59
Jan  7 16:37:49 my_pc smartd[933]: Device: /dev/sdc [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 42 to 41
Jan  7 16:37:49 my_pc smartd[933]: Device: /dev/sdd [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 112 to 111
Jan  7 17:07:49 my_pc smartd[933]: Device: /dev/sdb [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 69 to 70
Jan  7 17:07:49 my_pc smartd[933]: Device: /dev/sdd [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 111 to 112
Jan  7 17:37:49 my_pc smartd[933]: Device: /dev/sdd [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 112 to 111
Jan  7 17:56:58 my_pc systemd[1]: Starting Daily apt download activities...
Jan  7 17:57:04 my_pc systemd[1]: Started Daily apt download activities.
Jan  7 17:58:05 my_pc inadyn[1376]: .
Jan  7 17:58:05 my_pc inadyn[1376]: Checking for IP# change, connecting to ip1.dynupdate.no-ip.com(34.196.162.199)
Jan  7 17:58:05 my_pc inadyn[1376]: No IP# change detected, still at 11.22.33.44
Jan  7 18:07:49 my_pc smartd[933]: Device: /dev/sdb [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 70 to 69
Jan  7 19:09:55 my_pc rsyslogd: [origin software="rsyslogd" swVersion="8.16.0" x-pid="967" x-info="http://www.rsyslog.com"] start
Jan  7 19:09:55 my_pc rsyslogd: rsyslogd's groupid changed to 108
Jan  7 19:09:55 my_pc rsyslogd: rsyslogd's userid changed to 104

Записи в журнале температуры /dev/sdd странные. Видите ли, у меня нет sdd То есть sda - это мой SSD, sdb и sdc - магнитные жесткие диски, а /dev/sr0 - DVD-плеер. /dev/sdd даже не существует как специальный файл в /dev .

Строки из других журналов:

auth.log показывает некоторые китайские IP-адреса, пытающиеся подключить SSH к моей машине от имени пользователя root, например:

Jan  7 23:39:53 my_pc sshd[19697]: message repeated 3 times: [ Failed password for root from 218.65.30.53 port 51732 ssh2]
Jan  7 23:39:56 my_pc sshd[19697]: Failed password for root from 218.65.30.53 port 51732 ssh2
Jan  7 23:39:59 my_pc sshd[19697]: Failed password for root from 218.65.30.53 port 51732 ssh2
Jan  7 23:39:59 my_pc sshd[19697]: error: maximum authentication attempts exceeded for root from 218.65.30.53 port 51732 ssh2 [preauth]
Jan  7 23:39:59 my_pc sshd[19697]: Disconnecting: Too many authentication failures [preauth]
Jan  7 23:39:59 my_pc sshd[19697]: PAM 5 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=218.65.30.53  user=root

но я не думаю, что это связано, так как это происходит и после зависания. Никаких других строк в любых других журналах между сообщением, связанным с диском, о котором я упоминал выше, и зависанием.

|источник

2 ответа2

3

Возможно, один из ваших дисков был отключен, а затем снова подключен, но обнаружен как новое устройство. В моем опыте работы с серверами Linux это иногда случается, если старое устройство не отключилось должным образом, а ядро все еще держит свою букву, и при повторном подключении оно выдаст ему новую букву. Возможно, один из ваших дисков неисправен или кабели не закреплены. Это действительно зависит от контроллера и от того, как он работает с устройствами.

Поскольку вы говорите, что обнаружили, что машина уже зависла, и вы не можете по-настоящему осмотреть ее, чтобы посмотреть, что произошло, я бы предложил написать небольшой скрипт bash, постоянно извлекающий информацию обо всех дисках и записывающий ее в файл, предпочтительно на один из дисков. Вы уверены, что работаете, иначе он может не записаться, если вы попытаетесь записать его на неисправный диск. Сценарий может быть что-то вроде:

#!/bin/bash 


date
echo "Starting device data dump" 
for drive in sda sdb sdc sdd
do
    echo "Dumping data for drive ${drive}"
    fdisk -l
    smartctl -a /dev/${drive}
    dmesg -T | tail -n50
done
echo "Ended device data dump"

Поместите это в cron, работающий каждую минуту и записывающий вывод в файл с

crontab -e

Crontab строка для добавления:

* * * * * /usr/local/bin/logcommand.sh >> /var/log/disk-problem.log

После руки проверьте, что в файле. Вы сможете увидеть смарт-данные sdd, такие как модель, марка, серийный номер и сравнить их с другими вашими дисками. Если при отключении одного из них будет совпадение, если нет, вы все равно сможете получить информацию об этом загадочном жестком диске и о том, что это может быть.

Также проверьте, записан ли ваш dmesg в какой-либо файл в /var /log. dmesg должен распечатать устройство отключений и обнаружений.

PS: Кроме того, поскольку ваша машина зависает, когда вы ее находите, вероятно, это ваше корневое устройство, которое избавляет вас от проблем, поскольку, если у вас есть базовая система, и без нее машина не сможет функционировать.

|источник
1

Я не знаю, помогает ли это, но у меня похожая ситуация. Система представляет собой Intel NUC под управлением Linux Mint 18.3 (XFCE) с 8 ГБ ОЗУ и твердотельным накопителем M2, очень похожим на OP.

Мои проблемы показывает только при запуске Thunderbird. Я перенаправляю все свои данные Thunderbird на другой компьютер Linux Mint, который я использую в качестве сервера. Небольшие учетные записи Thunderbird работают (просто), но большие заставляют систему работать нестабильно, а Thunderbird на самом деле не работает вообще

Linux Mint 18.3 (XFCE) поставляется с Linux Kernel 4.10.0-38, и это прекрасно работает в моей системе - Thunderbird работает так же, как и в других системах. Однако, если я обновлю ядро Linux до 4.10.0-42 с помощью встроенного пакета обновления Mint, Thunderbird вызовет проблемы, упомянутые выше.

Я должен подчеркнуть, что эта проблема (с использованием более нового Ядра - 4.10.0-42) происходит только на моем компьютере NUC - другие системы работают нормально с обновленным Ядром.

Мое временное решение - придерживаться ядра 4.10.0-38 и полностью протестировать любые обновления перед использованием.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .