Неполное зависание системы.

Alex-der

New member
Сообщения
33
#1
Как я уже писАл в других темах, предстоит переход на работе на Астру.

Поставил 1.7.2 на пробную машину, ковыряю, знакомлюсь. Опыт работы с линуксом есть, правда, в серверных вариантах (без Х-ов). А вчера вечером вернулся, ввёл пароль - и система погрузилась в размышления о чём-то, вероятно, о масштабах Вселенной, не иначе. Вначале на движения мышкой, Caps-Num- ещё реагировала, потом время реакции стало достигать несколько десятков секунд. Индикатор работы ЖД раскалился. Мышка по экрану вначале шевелилась, потом тоже перестала отрабатывать. Рабочий стол так и не открылся. На консоль не переключалось. С соседней машины ping шёл, но зайти по ssh не удалось - login(tty?) не запускался. В итоге пришлось перезагружаться. uptime на тот момент был порядка двух недель, на рабочем столе было запущено несколько терминалок, пару fly-file-manager и chromium с ~ двумя десятками вкладок на разных столах.
В messages в это время есть только это
Код:
Dec 13 17:13:54 admin-test kernel: WARNING: chroot access!
Dec 13 17:13:54 admin-test kernel: WARNING: chroot access!
Dec 13 17:14:10 admin-test ru.astralinux.fly-fm.open[22890]: [ALSOFT] (EE) Could not query RTKit: No such file or directory (2)
Dec 13 17:14:12 admin-test ru.astralinux.fly-fm.open[22890]: qt.gui.imageio.jpeg: Corrupt JPEG data: premature end of data segment
Дальше - процесс новой загрузки. Но это уже было около 18-ти часов.
Код:
[    0.000000] Memory: 5903184K/6220740K available (16393K kernel code, 4274K rwdata, 10496K rodata, 2868K init, 4996K bss, 317296K reserved, 0K cma-reserved)
[    0.119774] smpboot: CPU0: AMD Athlon 3000G with Radeon Vega Graphics (family: 0x17, model: 0x18, stepping: 0x1)
[    0.119947] Performance Events: Fam17h+ core perfctr, AMD PMU driver.
Как-то неприятно-странное поведение. С чего бы? Куда ещё можно глянуть, чтобы понять причину? Памяти дофига, своп есть, правда 1 гиг всего, как инсталлятор рекомендовал... Flash не стоит.

Да, сеанс под пользователем без админских прав. Т.е., если бы систему забило пользовательским процессом, его бы отстрелило, или нет?
 

Alex-der

New member
Сообщения
33
#2
Продолжение истории.
Вчера вечером опять произошло погружение (неполное) системы в свои размышления: перед концом рабочего дня система начала дико торомозить, снова индикатор работы диска раскалился, но на мышку реакция была нормальная и на клавиатуру, хоть и с опозданием, но была ответка. Я переключился в первую консоль, ввёл логин-пароль, в систему зашёл. top показал почему-то 60% CPU xfreerdp. Что мог такого делать xfreerdp - для меня загадка. Кроме него болталось около 30 процессов хрома, штуки 4 xterm-а, vlc на паузе, synaptic, fly-fm. uptime - 6 с небольшим дней. Минут с 10-15 попереключавшись с графики на консоль и обратно в попытках найти загрузивший систему процесс, я поймал ошибку что-то типа "session ticket incorrect" и система раздуплилась, вышибив synaptic, все fly-fm-ы, vlc и все xterm-ы. xfreerdp и chromium остались живы (по идее, именно хром должен был из всего этого скушать память и его должны были первым пристрелить). В messages снова тихо. Долго не ковырялся - рабочий день закончился, система вела себя адекватно. Сегодня посмотрел - опять целый день зайка.
Вот что это может быть? Куда посмотреть можно? что показать опытным людям для диагностики?
 

Alex-der

New member
Сообщения
33
#3
Продолжение эпопеи :(
После всех новогодних праздников система "встретила" меня в полумёртвом состоянии. В этот раз я немного подготовился и оставил открытой текстовую консоль, на которую можно было переключиться и хоть что-то попытаться посмотреть. top показал, что 100% процессора съедено kswapd0. Занята система была настолько, что команда top вводилась секунд 30 - я удивился, что удалось так легко переключиться в консоль - всего каких-то 5-10 секунд. Есть в Астре инструмент, чем посмотреть, кто так выжирает память? Я на соседней машине нашёл только скрипты, но они не двухсотбайтные и ввести на полуживой системе не удалось. :(
Дня три на моих глазах система боролась с (чем?), пару раз, впрочем, оживая минут на пять и опять потом впадая в кому. Перенести на неё скрипт анализа потребления свопа за эти минуты просветления я не успел. :( Все ресурсы по-прежнему занимал kswapd0.
Наконец, система на моих глазах очнулась и пришла в себя. Удалось без проблем зайти в гуях под пользователем и даже всё с виду работало. Просмотр логов показал, что система вдруг посчитала файловую систему основного раздела / повреждённой и перевела её в ro. Запуск fsck исправил пару мелких ошибок файлов и сказал, что ФС чистая. Но перевести / в rw не удавалось - система твердила, что это невозможно на повреждённом разделе. Дальнейшее чтение гугла и яндекса ответа не дало. При этом swap и /home - на отдельном разделе и можно работать с файлами и в интернет. /tmp и /var/tmp практически пустые. В течение двух дней машинка жила весьма бодро, но стала наблюдаться постепенная деградация: вначале потребовала обновления и отвалилась телега, потом - ещё что-то (уже не помню). Логи замерли на моменте перевода раздела в ro. В общем, было принято решение не мучать животное и перезагрузить. Прошёлся раза три викторией по диску - ошибок нет, смарт отличный, перемещённых секторов 0 (диск новый). На сегодня аптайм уже 10 дней - пока полёт нормальный. Скриптик анализа свопа наготове...
 

oko

New member
Сообщения
1 180
#4
to Alex-der
Очень хочется ответить пачкой любимых цитат:
  1. Ты не надписи читай, а педофилов выискивай (с) Т.е. для начала стоит определить хотя бы спектр возможных причин. А для этого: почему именно SE? Какие параметры защиты выставлены? Какие механизмы защиты активированы? Какое ядро используется? Проводилось ли обновление до актуального куммулятива?
  2. Да у вас там явно проблемы с железом - причем тут релиз? (с) Т.е., судя по анамнезу, косячит подсистема накопителей (SATA HDD? SAS HDD? SSD? RAID? что там у вас?), а, возможно, с чем-то еще. Вот и вопрос: на этом железе другие дистрибутивы себя комфортно чувствуют вообще?
 
Сообщения
33
#5
to Alex-der
1. Ты не надписи читай, а педофилов выискивай (с) Т.е. для начала стоит определить хотя бы спектр возможных причин. А для этого: почему именно SE? Какие параметры защиты выставлены? Какие механизмы защиты активированы? Какое ядро используется? Проводилось ли обновление до актуального куммулятива?
SE - политика конторы. :( Пока просто ознакомительный вариант на обычной рабочей станции для ознакомления меня, как предстоящего непосредственного участника процедуры перевода пользователей на новую систему и последующей (тех)поддержки. Чтобы предварительно ознакомиться с граблями, по которым будут ходить пользователи. В этом году обещают закуп лицензий и дадут команду на переезд пользователей. Установка в минимальной базовой настройке, никакая защита не включена. Ядро 5.15, Astra 1.7.2.
2. Да у вас там явно проблемы с железом - причем тут релиз? Т.е., судя по анамнезу, косячит подсистема накопителей (SATA HDD? SAS HDD? SSD? RAID? что там у вас?), а, возможно, с чем-то еще. Вот и вопрос: на этом железе другие дистрибутивы себя комфортно чувствуют вообще?
Не согласен. (С) Железка новая, из свежей поставки конца прошлого года. dmesg. Как я уже выше писал - тройной проход викторией по диску проблем не обнаружил. По смарту количество перемещённых секторов 0. Винда 10 жила на этом железе нормально. Другие системы-дистрибутивы на этом железе я не пробовал, т.к. политика партии предприятия не предусматривает использования других систем. :(
 
Сообщения
1 180
#6
to Alex-der
Primo, обновите ALSE до 1.7.3 через куммулятивный пакет (iso-образ). Весьма вероятна специфическая бага в 1.7.2-релизе...
Secundo, если ставили сразу 1.7.2-сборку (не важно, откуда и как полученную), то не делайте так. Ставьте чистую, а на нее раскатывайте последний куммулятивный пакет обновлений (он в себе все содержит)...
Tertio, из опыта - поднимите в инфраструктуре зеркало репозиториев ALSE. Так будет куда проще и практичнее...
Quatro, базовая настройка ни о чем не говорит. На форуме выкладывал скрипт astra-on-off-szi, пройдитесь им и посмотрите, какой уровень выбран (для ознакомления и вне аттестуемых в дальнейшем объектов информатизации хватит "Орла"). Возможно, затирание все-таки включено, тогда понятно, откуда ноги растут...
Last, попробуйте ради интереса развернуть ту же Мяту 21 на 5.15 ядре. Есть вероятность, что это общий баг ядра, например. Короче, для очистки совести...
 
Сообщения
33
#7
"Никогда такого не было и опять - опять" (С) виктор степанович

Вчерась, уходя, система работала нормально, а утром меня встречает ящик в глубоком свопе. :( Полчаса - на консоль пока переключиться не могу, но хоть экран проснулся. Мыша не двигается, *Lock-и не работают. :(
to Alex-der
Primo, обновите ALSE до 1.7.3 через кумулятивный пакет (iso-образ). Весьма вероятна специфическая бага в 1.7.2-релизе...
Secundo, если ставили сразу 1.7.2-сборку (не важно, откуда и как полученную), то не делайте так. Ставьте чистую, а на нее раскатывайте последний кумулятивный пакет обновлений (он в себе все содержит)...
Как я уже выше писАл - мы ещё не являемся официальными пользователями Астры. :( Лицензия пока только в планах закупки на этот год. Поэтому доступа к закрытому репозиторию у нас нет, как и к ftp с релизами. Ставилось с того, что нам передала головная контора. ISO=образ похож на официальный релиз.
Tertio, из опыта - поднимите в инфраструктуре зеркало репозиториев ALSE. Так будет куда проще и практичнее...
Это когда будет лицензия и пойдёт процесс перевода. Сейчас - ни доступа, ни резона поднимать локальный репозиторий из-за одной тестовой машины...
Quatro, базовая настройка ни о чем не говорит. На форуме выкладывал скрипт astra-on-off-szi, пройдитесь им и посмотрите, какой уровень выбран (для ознакомления и вне аттестуемых в дальнейшем объектов информатизации хватит "Орла"). Возможно, затирание все-таки включено, тогда понятно, откуда ноги растут...
Last, попробуйте ради интереса развернуть ту же Мяту 21 на 5.15 ядре. Есть вероятность, что это общий баг ядра, например. Короче, для очистки совести...
Это уже чуть позже - сейчас попробую проанализировать состояние системы, если таки даст возможность. Но мне кажется, что здесь имеет место ситуация, что kswapd0 на каком-то этапе не справляется с очередным запросом выделения памяти и начинает тасовать блоки в свопе с места на место. (может, оптимизация свопа (страниц) какая-то начинается?) Надо почитать на форумах про работу kswapd. Как-то до этого никаких проблем не возникало и нужды не было - есть в системе, работает - и хорошо...
 
Сообщения
33
#8
Пять суток (ну +- ночь - я точно определить пока не могу, когда она впадает в кому и выходит из неё) система боролась сама с собой. К утру пятницы ей удалось переключиться в консоль, но воспринмать нажатия клавиш она была ещё не готова. К обеду отобразились нажатые буковки. Результатов работы скрипта анализа свопа я до конца рабочего дня так и не дождался. В понедельник табличка была, но я её не сохранил, к сожалению. :( Система была жива и вполне адекватна в консоли, top показывал загрузку процессора 2-3%. Переключиться в гуи удалось легко, но после ввода пароля всё опять умерло. Я немного протупил , возя мышкой по экрану и наблюдая процесс замерзания, и переключение в консоль опять растянулось на два часа. Запуск скрипта и... - вечером скрипт ещё работал, хотя обычно отрабатывал менее, чем за минуту.

Сегодня к утру скрипт показал, что три самых потребляющих своп процесса - asts, okular и Xorg. :( Система бодра и адекватна. В гуях залогинился без проблем. Не досчитался телеги и хрома. В messages и /var/log/astra/events есть записи, что процессы прибиты oom-killer-ом из-за нехватки памяти. Ну, в общем, почти адекватное поведение, если не считать пятисуточной, почти недельной, заморозки для принятия решения о прибитии пользовательских процессов. :( Хром запустился снова без проблем.

На форуме выкладывал скрипт astra-on-off-szi
Увы, поиск встроенным движком форума, ни гуглом по форуму, ни гуглом вообще, результата не дали. :( Не затруднит вас, коллега, выложить этот скрипт ещё раз?

PS: Смущает меня, что первых примерно две недели система работает нормально. А потом начинается... На этапе установки "царапнуло", что при 6ГБ оперативки инсталлер предложил всего 1ГБ свопа. Помнится, раньше рекомендации по размеру свопа были RAM*2. Создалось устойчивое впечатление, что через пару недель после старта системы kswapd начинает оптимизировать использование свопа и вот тут алгоритм работы оказывается... как бы это помягче... "неэффективен".