LINUX.ORG.RU

[баг][запуск процессов][мистика]

 ,


1

3

С системой происходят странные вещи.

Как выглядит:

Не могу запустить большинство иксовых приложений, (вообще говоря все кроме gmrun) в том числе xterm, однако другие приложения, которые были запущены до этого работают нормально (в firefox создаются вкладки, открывается ютуб с плеером). Также, если до происшествия был запущен терминал, то консольные приложения в нем запускаются и работают, все кроме su ! При попытке запуска su терминал блокируется и C-c не помогает. dmesg не показывает никаких сообщений, кроме тех, что были при загрузке ядра. При переключении на другую консоль (C-M-F1) и попытке залогиниться под пользователем или под рутом консоль перестает отвечать так и не показав мне приглашение оболочки, при переключении обратно на иксовую консоль наблюдаем черный экран вместо иксов. Если подождать (время не замерял но это в пределах нескольких минут), то все что вы до этого делали (пытались запустить терминалы, другие приложения и прочее) начинает происходить, то-есть начинают запускаться терминалы и прочее.

Я бы мог предположить, что на время блокируется какая-то очередь сообщений и дело тут в оконном менеджере, в драйверах или в самих иксах, но почему тогда я не могу залогиниться в другой консоли под рутом ?!

Косвенные причины возникновения:

Нагрузка на процессор. Сначала это происходило во время обновления (gentoo) но вот прямо сейчас это произошло когда tracker пересчитывал индексы, при этом процессор был нагружен на 100%

Нужны советы по диагностике причины. Даже предположить не могу в чем дело.

ЗЫ: это происходит прямо сейчас ! что делать ??!!!

Ответ на: комментарий от Kroz

пффф

CFLAGS="-O2 -march=core2 -mtune=generic -mfpmath=sse -msse4.1 -fomit-frame-pointer -pipe"
CXXFLAGS="${CFLAGS}"
ICCCFLAGS="-O3 -fomit-frame-pointer -xSSE4.1 -g0 -w -gcc"
ICCCXXFLAGS="${ICCCFLAGS}"
CHOST="i686-pc-linux-gnu"
MAKEOPTS="-j3"
EMERGE_DEFAULT_OPTS="-j3"
4.5.2
[ megabaks@desktop ] ~ $  ls -l /etc/make.profile
lrwxrwxrwx 1 root 0 46 Май 15 21:27 /etc/make.profile -> ../usr/portage/profiles/default/linux/x86/10.0
[ megabaks@desktop ] ~ $ 
УМВР

megabaks ★★★★
()
Ответ на: комментарий от Kroz

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

s9gf4ult ★★
() автор топика
Ответ на: комментарий от s9gf4ult

Вот что-то похожее нашел, но пока не тестил. Если будет время - потести, тут люди воспроизводят проблему с помощью dd и смотрят iowait . Делай на своем reiserfs разделе:
https://bugzilla.kernel.org/show_bug.cgi?id=12309

Я скомпилил 2.6.39.1 ядро с kernel.org . Ща поставлю, потестю.

С ioscheduler - попробую, но что-то меня берут сомнения. В любом случае ни один планировщик не должен проводит к такого рода блокировкам...

Kroz ★★★★★
()
Ответ на: Good news от Kroz

Нет, повисло. Но уже лучше.

Kroz ★★★★★
()
Ответ на: комментарий от Kroz

Да, но если я правильно понял, возникает он ТОЛЬКО если забить память до отказа и тогда начинает «тормозить» да ?

s9gf4ult ★★
() автор топика
Ответ на: комментарий от s9gf4ult

> Да, но если я правильно понял, возникает он ТОЛЬКО если забить память до отказа и тогда начинает «тормозить» да ?
Ты про 12309 ?

Во-первых, как многие говорят, это не один баг, а комплекс багов, поэтому, проявления немного разное (хотя и похожее) у разных людей, и именно поэтому его решение так долго тянется (на kernel.org он до сих пор открыт).

У меня было проявление такое: любое ображение к диску начинает кушать процессор (как будто отключен DMA). Cкорость четния/записи была медленной, создавалось впечатление, что процессор ограничивает скорость чтения/записи. Более того нагружалось почему-то только одно ядро, второе не задействовалось даже когда загрузка первого ядра 100%. Также при запуске приложений они почему-то тоже хотели работать на первом ядре и лишь частично на втором. Небольшим обходом было изменить affinity на второе ядро, таким образом IO операции кушали полностью второе ядро, первое было для приложений. Однако все равно из-за слабого I/O все тормозило.

Это ушло с каким-то очередным обновлением ядра.

Kroz ★★★★★
()
Ответ на: комментарий от Kroz

Правда до сих пор наблюдаю большую загрузку проца (под 80%-100% на обоих ядрах) при общении с некоторыми флешками (не со всеми почему-то), но на общий перформанс системы это не влияет, просто долго пишется.

Есть и еще странность - не знаю связано это или нет. При записи на некоторые флешки иногда запись завершается с серъезной ошибкой. При этом повреждается фаловая система на флешке и она перемонтируется в read-only. Повреждение файловой сисмемы легко обнаружить с помощью проверки диска, или, если играешь музыкальные файлы, в середине одного трека слушаешь другой, или хотябы тем фактом, что некоторые файлы и каталоги нельзя удалить. Лечится форматирование или проверкой диска.

Наблюдается на флешках с VFAT и с особо тормознутыми. Происходит если переписывать большие объемы данных (200Мб и более) и разными файлами - например при переписи аудиокниг или альбомов песен. Решается тем, что переписываешь небольшими пачками (до 100Мб).

Думаю, это связано, но это у меня на втором приоритете.

Kroz ★★★★★
()
Ответ на: комментарий от s9gf4ult

Вобщем, я вижу 2 пути:
1. Запостить баг на kernel.org .
2. Повозиться с конфигом ядра. Попробовать сконфигурировать дефолтное ядро (насколько это возможно), потом потихоньку добавлять опции пока не выявится баг. Правда это займет уйму времени: компиляция, перегрузки...

Если есть другие варианты - буду рад их услышать.

Kroz ★★★★★
()
Ответ на: комментарий от Kroz

Ну думаю первое по - любому сделать стоит, если разрабы откликнутся, то возможно подскажут методы диагностики для локализации бага.

s9gf4ult ★★
() автор топика
Ответ на: комментарий от Kroz

Правда до сих пор наблюдаю большую загрузку проца (под 80%-100% на обоих ядрах) при общении с некоторыми флешками

У себя никогда не наблюдал проблему с флешками. Но и система у меня одноядерная и ядро no-preemption (server mode) и планировщик CFQ

s9gf4ult ★★
() автор топика
Ответ на: комментарий от Kroz

Вчера случилось опять. У меня это немного иначе. Короче заранее открыл несколько терминалов, и когда обнаружил что приложения опять не запускаются, то попробовал

ls ~
ls /
Дак вот команды не повисли и отработали, но приложения запускаться не стали, потом я сделал
touch 1 
И, о чудо, на экран полезли окна xterm и пара наутилусов. Возможно это было только совпадение и выполнение последней команды не было на самом деле причиной, но strace я так и не сделал, потому что система вдруг отвисла.

Заметил что флеш плеер довольно сильно влияет на вероятность зависания в положительную сторону. В следующий раз как повиснет сразу буду делать strace xterm так как он точно не может запустится когда это случается.

Отпишу тоже самое на kernel.org

s9gf4ult ★★
() автор топика
Ответ на: комментарий от Kroz

БЛЯ !! у меня прямо щас это происходит нах ! И не могу отвиснуть. Могу сказать только то, что это не из-за блокировки раздела !

find по хомяку и по корню не повисли. Приложения не запускаются ко каким-то иным причинам. У меня это произошло после монтирования флешки (повис pmount), кстати вотеще темка, у тебя такого нет ?Жду пока отвиснет. как отвиснет - будет strace для xterm !!!

s9gf4ult ★★
() автор топика
Ответ на: комментарий от s9gf4ult

s9gf4ult, привет!

Я сморю ты все добавляешь инфу в https://bugzilla.kernel.org . Может пусть они уже ответят хоть что-то? А то мы там сами с собой общаемся. Не добавляй пока ничего туда, пускай ответят.

У нас, кстати, симптомы немного разные. У тебя было такое что размораживается, у меня - нет.

Кстати, вот еще одна тема с похожими симптомами:
http://www.linux.org.ru/forum/desktop/6515054

Я направил ТС в эту ветку. Может сообщество соберем ;) . А если серъезно - статистику.

Kroz ★★★★★
()
Ответ на: комментарий от Kroz

Kroz> У нас, кстати, симптомы немного разные

Есть способ проверить действительно ли разная причина или одна и та-же. Надо в ядре включить отладку зависаний (Kernel Haking -> Detect Hung Tasks) чтобы в дмесг выбрасывало стектрейсы (у тебя ведь не виснет рутовая консоль и ты можешь это сделать когда хомяк встает колом). Либо использовать сочетание SysRq Alt-PrScr-w чтобы в дмеск вышла инфа о процессах в состоянии D (blocked) с ядерным трейсом в какой функции повис процесс.

У меня очевидно причина в reiserfs, трейсы выглядят так:

Jul 16 19:27:45 localhost kernel: [ 7503.437080] Call Trace:
Jul 16 19:27:45 localhost kernel: [ 7503.437084]  [<ffffffff81126b4a>] queue_log_writer+0x6b/0x9b
Jul 16 19:27:45 localhost kernel: [ 7503.437088]  [<ffffffff8102bfe4>] ? default_wake_function+0x0/0xf
Jul 16 19:27:45 localhost kernel: [ 7503.437092]  [<ffffffff8112a6f6>] do_journal_begin_r+0x1ee/0x2d5
Jul 16 19:27:45 localhost kernel: [ 7503.437098]  [<ffffffff810c7ed9>] ? __pollwait+0x0/0xc6
Jul 16 19:27:45 localhost kernel: [ 7503.437102]  [<ffffffff8112a89e>] journal_begin+0xc1/0x101
Jul 16 19:27:45 localhost kernel: [ 7503.437106]  [<ffffffff8111c34d>] reiserfs_dirty_inode+0x5f/0xa0
Jul 16 19:27:45 localhost kernel: [ 7503.437110]  [<ffffffff810c7f9f>] ? pollwake+0x0/0x4f
Jul 16 19:27:45 localhost kernel: [ 7503.437114]  [<ffffffff81032307>] ? current_fs_time+0x22/0x29
Jul 16 19:27:45 localhost kernel: [ 7503.437120]  [<ffffffff810d5240>] __mark_inode_dirty+0x29/0x19f
Jul 16 19:27:45 localhost kernel: [ 7503.437124]  [<ffffffff810cb805>] file_update_time+0xdd/0xfe
Jul 16 19:27:45 localhost kernel: [ 7503.437129]  [<ffffffff8108f763>] __generic_file_aio_write+0x15d/0x279
Jul 16 19:27:45 localhost kernel: [ 7503.437133]  [<ffffffff8108f8d7>] generic_file_aio_write+0x58/0xa4
Jul 16 19:27:45 localhost kernel: [ 7503.437137]  [<ffffffff810baaa9>] do_sync_write+0xc5/0x102
Jul 16 19:27:45 localhost kernel: [ 7503.437144]  [<ffffffff811abd2d>] ? selinux_file_permission+0x56/0xac
Jul 16 19:27:45 localhost kernel: [ 7503.437151]  [<ffffffff811a7ec8>] ? security_file_permission+0x29/0x2e
Jul 16 19:27:45 localhost kernel: [ 7503.437155]  [<ffffffff8111775d>] reiserfs_file_write+0x45/0x47
Jul 16 19:27:45 localhost kernel: [ 7503.437159]  [<ffffffff810bafe1>] vfs_write+0xa8/0x102
Jul 16 19:27:45 localhost kernel: [ 7503.437163]  [<ffffffff810bb0f1>] sys_write+0x45/0x69
Jul 16 19:27:45 localhost kernel: [ 7503.437167]  [<ffffffff81001ee8>] system_call_fastpath+0x16/0x1b

Что - то происходит во время доступа к логу рейзера.

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

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

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

s9gf4ult ★★
() автор топика
4 сентября 2011 г.
Ответ на: комментарий от s9gf4ult

Подставил конфиг от megabaks почти один в один. Первые тесты прошли очень успешно! Кроме того, в логах небыло обычных ошибок от syslog-ng и opera'ы. Но здесь я склоняюсь к мнению что вывод ошибок просто подавлен.

Но - самое главное - закачка файла по torrent и параллельное проигрывание 5 роликов в youtube прошли отлично - без непонятных лагов и каких-либо зависаний!

Дело в каких-то настройках ядра!

Что ж буду теперь по кускам конфиг подставлять. Эх, долгая дорога...

Kroz ★★★★★
()
Ответ на: комментарий от Kroz

А ты пробовал SysRq как я выше написал ? чтобы посмотреть где именно в ядре зависон происходит ? Как я уже говоил у меня это была файловая система от убийцы, кстати ext4 еще и быстрее.

s9gf4ult ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.