Kernel panic при выключении или перезагрузке

[madesta]

М.б. ошибся с разделом в котором необходимо задать данный вопрос.

При длительной (именно длительной) работе (6-8- часов и более) при выключении или перезагрузке системы перестает полностью отрабатываться команда shutdown. В сообщении на экране запись ссылается на libuninstring.so.2 Однако сама библиотека присутствует по пути /usr/lib/x86_64-linux-gnu При не слишком продолжительной работе такого явления не возникает.

Пример вывода:

[ OK ] Reached target Reboot
/shutdown: error while loading shared libraries: libininstring.so.2: cannot open shared object files: No such file or directory
Kernel panic - not syncing: Attempt to kill init! exit code=0x00007f00

inxi -Fxz:

System:
Kernel: 5.4.0-52-generic x86_64 bits: 64 compiler: gcc v: 9.3.0
Desktop: Xfce 4.14.2 Distro: Linux Mint 20 Ulyana base: Ubuntu 20.04 focal
Machine:
Type: Desktop Mobo: ASRock model: J3455B-ITX serial: <filter>
UEFI: American Megatrends v: P1.30 date: 07/14/2017
Battery:
Device-1: hidpp_battery_0 model: Logitech Wireless Keyboard K270
charge: 10% (should be ignored) status: Discharging
CPU:
Topology: Quad Core model: Intel Celeron J3455 bits: 64 type: MCP
arch: Goldmont rev: 9 L2 cache: 1024 KiB
flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 11980
Speed: 2196 MHz min/max: 800/2300 MHz Core speeds (MHz): 1: 2196 2: 2196
3: 2196 4: 2196
Graphics:
Device-1: Intel HD Graphics 500 vendor: ASRock driver: i915 v: kernel
bus ID: 00:02.0
Display: x11 server: X.Org 1.20.8 driver: modesetting unloaded: fbdev,vesa
resolution: 1920x1080~60Hz
OpenGL: renderer: Mesa Intel HD Graphics 500 (APL 2) v: 4.6 Mesa 20.0.8
direct render: Yes
Audio:
Device-1: Intel Celeron N3350/Pentium N4200/Atom E3900 Series Audio Cluster vendor: ASRock driver: snd_hda_intel v: kernel bus ID: 00:0e.0
Sound Server: ALSA v: k5.4.0-52-generic
Network:
Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
vendor: ASRock driver: r8169 v: kernel port: e000 bus ID: 02:00.0
IF: enp2s0 state: up speed: 100 Mbps duplex: full mac: <filter>
Drives:
Local Storage: total: 465.76 GiB used: 283.60 GiB (60.9%)
ID-1: /dev/sda vendor: Toshiba model: MQ01ABD050 size: 465.76 GiB
Partition:
ID-1: / size: 457.42 GiB used: 283.59 GiB (62.0%) fs: ext4 dev: /dev/sda2
Sensors:
System Temperatures: cpu: 58.0 C mobo: N/A
Fan Speeds (RPM): N/A
Info:
Processes: 173 Uptime: 34m Memory: 3.51 GiB used: 1000.7 MiB (27.8%)
Init: systemd runlevel: 5 Compilers: gcc: 9.3.0 Shell: bash v: 5.0.17
inxi: 3.0.38

М.б. кто подскажет куда и как далее копать.

[slant]

Вот это:

При не слишком продолжительной работе такого явления не возникает.

намекает на то, что проблема скорее всего завязана на железо. (Большая часть "плавающих" неисправностей на него завязана). Потому начинать диагностику надо с тестов памяти и диска, IMHO. А далее - можно попробовать замену ядра, может несовместимость с железом присутствует. И неплохо было бы глянуть полный вывод journalctl за всю длинную сессию, которая закончилась проявлением проблемы - возможно там что-то отмечается.

Чтобы получить лог сессии в файл: journalctl -b -1 > session.txt где "-1" - насколько предыдущих сессий отмотать назад. Т.е. просто -b без второго ключа - текущая сессия, -1 - предыдущая, -10 - десять загрузок назад.

[Unborn]

при выключении или перезагрузке системы перестает полностью отрабатываться команда shutdown.

Ты вручную что ли выключаешь, перезагружаешь? Или нарукаблудил, скачал какую-то приспособу?

[madesta]

Ты вручную что ли выключаешь, перезагружаешь?

Раньше было через crontab, теперь вручную.

[madesta]

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

Взял 10 сессий. выложил на шару. По времени проявления, по моему, это была session4.txt, про другие - не помню когда проявлялось, м.б. 6-я и 7-я, врать не буду. По крайней мере, session4.txt с 18:31 до 02:10 Тогда, по моему, задумал перезагрузиться и на выходе, когда практически всё отработалось и экрану оставалось только моргнуть чёрным и показывать новый старт системы, получил затык с выводом дампа. Как раз это было после 02 часов. После этого в тщётном поиске возможной причины ошибки немного порыскал в Интернет и стал писать на форум.
Сначала грешил на железо, но потом вспомнил, что на предыдущей системе LM18 с ядром 4.15 такого безобразия, вроде бы, не наблюдалось. Железо представляет из себя безвентиляторный блок ноутбучной начинки с ноутбучным внешним БП. АКБ не имеется. Хотя, кто его знает, железо имеет свойство ломаться.

[slant]

Два момента в логах настораживают. Первый:

Код: Выделить всё

окт 23 18:42:35 H-4 systemd-coredump[2705]: Process 1407 (pcloud) of user 1000 dumped core.

Stack trace of thread 1635:
#0 0x00007fad6a55018b __GI_raise (libc.so.6 + 0x4618b)
#1 0x00007fad6a52f859 __GI_abort (libc.so.6 + 0x25859)
#2 0x0000000001ab33f9 n/a (/pcloud + 0x18b33f9)
#3 0x000000000306c200 n/a (/pcloud + 0x2e6c200)
#4 0x0000000004aee3f5 n/a (/pcloud + 0x48ee3f5)
#5 0x0000000000000000 n/a (n/a + 0x0)
окт 23 18:42:35 H-4 systemd[1]: systemd-coredump@0-2704-0.service: Succeeded.

Вроде бы не только в 4-ой сессии встречается, но если дело доходит до дампа - значит явный косяк. Влияет или нет - тут только проверочным отключением проверять. Клиент для вот этого https://www.pcloud.com/ru/eu чудит, я так понял...

Второй момент: Universe@Home отключить попробуйте тоже. Хоть оно ошибок не сыпет - зато может грузить машину по самые уши "в свободное время" провоцируя проявление косяка. Если после отключения симптомы пропадут - значит большая нагрузка железке/системе не дается.

[madesta]

Загрузился с livecd, через gparted сделал check раздела.
По выводу обнаружилась 41 запись вида:
inode ... extent tree (at level 1) could be narrower. Optimize? yes
Как пишут в англоязычных источниках, вроде бы, не смертельно. А в действительности что бы это значило?
По "Настройка - Диски - Тесты и данные SMART" выводит, что "Обновлено 2 минуты назад. Последняя самодиагностика завершена без ошибок". Перераспределённых секторов = 0. Но смущает 191 - кол-во ошибок в результате нагрузок при ударе или падении = 26. Это что, типа головки на пластины упали?

[madesta]

Клиент для вот этого https://www.pcloud.com/ru/eu чудит, я так понял...

Попробую вырубить вообще, тем более, что погоды не делает, так как имеется альтернатива в виде rclone.

Universe@Home отключить попробуйте тоже.

Попробую. Использование было связано с тем, что никакими способами: ни /etc/hdparm.conf, ни службой tlp не удалось победить периодическую парковку винчестера каждые 10-12 минут - "щёлк, щёлк" особенно слышно ночью (растёт 193 параметр SMART). А так, думал, пусть математические вычисления в интересах науки периодически дёргают винчестер, ежеминутно записывая на него промежуточные результаты и не давая ему парковаться.
Потестирую, отпишусь. Хотя, в связи со случайностью проявления, быстрого ответа не обещаю.

[slant]

Это что, типа головки на пластины упали?

Если бы упали - был бы запил, и кранты диску. Нет, это только фиксация от сенсора удара/движения - оно таки было, и превосходило допустимое для диска во время работы. Это не значит, что ему совсем плохо, это значит - что ему МОЖЕТ быть плохо по этой причине, т.к. производитель на такое не рассчитывал.

Использование было связано с тем, что никакими способами: ни /etc/hdparm.conf, ни службой tlp не удалось победить периодическую парковку винчестера каждые 10-12 минут - "щёлк, щёлк" особенно слышно ночью

А покажите-ка вывод smartctl -x целиком. С одной стороны - винт ноутбучный, ему положено. А с другой, странный период парковки - раз в 10-12 минут? (Ключ именно -x а не -a).

[madesta]

С одной стороны - винт ноутбучный, ему положено. А с другой, странный период парковки - раз в 10-12 минут?

Да такая же картина и на втором аналогичном, но более продвинутом девайсе. Там системным SSD, а с такой же периодичностью паркуется второй HDD. Поэтому спасение используется в виде виртуальной Windows, которая крутится на HDD. К сожалению, на эти веники Toshiba фирменной утилиты не выпускалось, а использовать Windows уже религия не позволяет.

А покажите-ка вывод smartctl -x целиком.

Ничего себе простыня, 390 строк. Наверное, такой объём встраивать как то будет не совсем прилично, поэтому вывод там же - smartctl-x.txt

[slant]

Насколько я вижу - у железа проблемы с общением по data каналу. Редкие, но присутствуют. Система вынуждена периодически reset состояния делать для интерфейса винта, а это не слишком хороший признак, даже если ничего другого не проявляется. Но тут фиг поймешь где именно баг засел - это может быть как винт, так и кабель, и контроллер на материнке.

Тест же он у вас проходил только короткий. Попробуйте прогнать полный:
smartctl --test=long

[madesta]

Плохо мне быть тупым
Запустил sudo smartctl --test=long /dev/sda > /home/minter/smartctl-test-long.txt
Содержание файла вижу. Написано, что тест займёт не менее 120 минут, но терминал возвратился в приглашение minter@H-4:~$
Результат упадёт в txt или я сделал неправильно?

[slant]

Ты сделал неправильно. Ничего никуда не упадет, т.к. smartctl ничего сам не тестирует, он только говорит прошивке диска что от него хотят, после чего прошивка сама занимается диском, по своему усмотрению, автономно. Тест будет выполнятся фоном, результат будет только в журнале SMART. По факту - сколько займет, зависит от того, будет ли диск чем-то еще заниматься или нет. Потом, когда закончит, результат можно будет посмотреть через smartctl -a и -x. Вот тогда уже можно в файл вывод отправлять.

[madesta]

Тест д.б. завершиться в 01:23, команды давал после 02 час. По самостоятельному поиску нашёл, что результат можно посмотреть командой smartctl -l selftest /dev/sda (источник).
Пару минут назад выполнил smartctl -a и smartctl -x
Результаты выводов в файлах 2-smartctl-a.txt, 2-smartctl-l-selftest.txt, 2-smartctl-x.txt

Смущают записи:
# 3 Extended offline Aborted by host 90% 19216 -
# 4 Extended offline Aborted by host 90% 19216 -
Глубокий тест не прошёл? Хотя по незнанию 2 раза обрывал тест. Но 3-й глубокий тест должен был пройти.

И до кучи SMART 193 - 2 среза времени, ничем кроме браузера не дёргал с 22:52 :
22:55 - 14574
00:17 - 14585

[slant]

И до кучи SMART 193 - 2 среза времени, ничем кроме браузера не дёргал с 22:52 :
22:55 - 14574
00:17 - 14585

Для ноутбучного диска это нормально. Они так себя защищают от передвижений ноутбука, там парковка выставлена на небольшое время, и диск на это рассчитан. (300000-500000 циклов ресурса у самых дешевых моделей - норма).

А вот гораздо неприятнее вот это:

Код: Выделить всё

0x0009  4        90779  Transition from drive PhyRdy to drive PhyNRdy
0x000a  4            7  Device-to-host register FISes sent due to a COMRESET

Особенно первая строчка. Диск "отваливается" с линии, возвращается (до того как фиксируется ошибка SATA), но через короткое время снова отваливается и так по кругу. Это не нормально. Для диска который более-менее в порядке - это значение обычно не превышает 500-1000, а чаще всего - и пары сотен. Точный смысл параметра производители не особо разглашают, но общий - тот что я описал. У вас он ОЧЕНЬ сильно завышен. Т.е. полностью здоровым диск считать нельзя. К сожалению, тут может еще влиять сам контроллер на материнке, так что на 100% диагноз только на этой основе не поставишь. В идеале - заменить диск, и посмотреть как себя будет вести SMART у замены.

[madesta]

Дело в том, что если сам девайс был новый, то установленный в нём винчестер - б/у (племянник со своей IT работы подогнал после модернизации компов на предприятии). Изначально покупными были только корпус, материнка и проц. Мозги, винчестер и БП в комплекте не поставлялись - это б/у. Если к железу и были подозрения, то к винчестеру в первую очередь.
Сегодня установил cron на выключение в 08:30 Сессия была довольно-таки длинная - навскидку порядка 10-11 часов. Но выключился штатно, без проблем. Ещё попробую с недельку хорошо погонять, если будет проявляться, то попрошу племянника сменить мне жёсткий диск, тем более, по его словам, проблем с этим не имеется. О результатах отпишусь.

[madesta]

Как и обещал, отписываюсь по результатам проверки.
За прошедшую неделю система все сессии отработала в штатном режиме. Причём одна из сессий имела продолжительноть более 17 часов, остальные - не менее 10-12 часов. Главный вывод – проблема комплексная, то есть программно-аппаратная.

1. Клиент pCloud. Имевший место случай являлся единичным. К тому же, клиент постоянно не работает. После старта системы с автозапуском pCloud через 10 минут клиент pCloud выключается через скрипт.

2. Universe@Home. По умолчанию в настройке клиента установлено значение "Использовать не более 100% времени ЦП". Это значение было изменено на 70%. Кроме того указано, чтобы за 3 минуты до выключения компьютера (по расписанию) служба BOINC останавливалась.
Вероятнее всего, при совпадении момента выключения системы и активного обращения Universe@Home к жёсткому диску имело место "отваливание" data канала диска. Как раз об этом и говорил slant: "... зато может грузить машину по самые уши "в свободное время" провоцируя проявление косяка".

3. Сам винчестер, один из параметров которого "... У вас он ОЧЕНЬ сильно завышен. Т.е. полностью здоровым диск считать нельзя".

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

Хотелось бы ещё раз выразить признательность slant за потраченное на меня время при разбирательстве логов сессий и подробные разъяснения. Тему можно считать закрытой.

[rogoznik]

Тему можно считать закрытой.