WARNING: at kernel/exit.c:889 do_exit+0x69e/0x730()
Modules linked in: eeprom i2c_i801 i2c_core pcspkr thermal rtc processor button nfs lockd sunrpc scsi_transport_fc sx8 scsi_wait_scan
Pid: 17444, comm: mysqld Tainted: G      D  2.6.25-gentoo-r9 #2
 [<c012483f>] warn_on_slowpath+0x5f/0x90
 [<c013bd17>] atomic_notifier_call_chain+0x17/0x20
 [<c02d0a8d>] notify_update+0x1d/0x30
 [<c02d0d03>] vt_console_print+0x1f3/0x2d0
 [<c02d0b10>] vt_console_print+0x0/0x2d0
 [<c0124c5e>] __call_console_drivers+0x5e/0x70
 [<c0125201>] release_console_sem+0x1b1/0x1d0
 [<c013b3b7>] hrtimer_interrupt+0x157/0x190
 [<c0129bac>] irq_exit+0x3c/0x80
 [<c012831e>] do_exit+0x69e/0x730
 [<c0104640>] apic_timer_interrupt+0x28/0x30
 [<c012573b>] printk+0x1b/0x20
 [<c0105104>] die+0x164/0x170
 [<c0116d6f>] do_page_fault+0x27f/0x630
 [<c0116af0>] do_page_fault+0x0/0x630
 [<c03f3e82>] error_code+0x72/0x78
 [<c01c9512>] reiserfs_get_block+0x812/0x13a0
 [<c019e987>] ll_rw_block+0x77/0x110
 [<c019ee93>] __block_prepare_write+0x1f3/0x3d0
 [<c015a3d3>] add_to_page_cache+0x93/0xa0
 [<c019f105>] block_write_begin+0x55/0xf0
 [<c01c8d00>] reiserfs_get_block+0x0/0x13a0
 [<c01cb4e2>] reiserfs_write_begin+0x122/0x200
 [<c01c8d00>] reiserfs_get_block+0x0/0x13a0
 [<c015b115>] generic_file_buffered_write+0x115/0x640
 [<c0184415>] do_lookup+0x65/0x1a0
 [<c018403e>] permission+0x7e/0x160
 [<c018e02c>] dput+0x1c/0xd0
 [<c015b8bb>] __generic_file_aio_write_nolock+0x27b/0x540
 [<c0186948>] path_walk+0x88/0xa0
 [<c015bbd9>] generic_file_aio_write+0x59/0xd0
 [<c017c9f7>] do_sync_write+0xc7/0x110
 [<c0137b00>] autoremove_wake_function+0x0/0x50
 [<c01691e1>] handle_mm_fault+0x2b1/0x5b0
 [<c029562c>] security_file_permission+0xc/0x10
 [<c017cbb6>] rw_verify_area+0x66/0xd0
 [<c017d2e6>] vfs_write+0xa6/0x160
 [<c01cc2e0>] reiserfs_file_write+0x0/0xc0
 [<c017da21>] sys_write+0x41/0x70
 [<c0103b96>] sysenter_past_esp+0x5f/0x85
 [<c03f0000>] setup_local_APIC+0x120/0x2a0
 =======================
---[ end trace ffed7ba048a5f356 ]---
php-cgi[9887]: segfault at 1 ip 00000001 sp bf8ace9c error 4 in php-cgi[8048000+603000]

Попытка создать новый файл в /etc - завис.

Попытка перемонтировать / в ro - завис.

Либо что-то очень мощно заглючило в ядре, либо проблема с железом (возможно - с оперативной памятью).

Работа с другими разделами идёт, вроде, без проблем. В dmesg новых ошибок нет.

...

Чёрт, как бы починить активный корневой раздел? :) Говорила мне мама, раскидывай все компоненты системы по разным разделам... Домашнюю бы машину в таком состоянии раз плюнуть починил бы удалённо :-/

Попробуй запустить что-то типа cat /dev/sdX > /dev/null. Если и так зависнет, то думаю что-либо сделать будет не реально.

Мне кажется с железом проблема...

В общем все плохо=)

>Либо что-то очень мощно заглючило в ядре, либо проблема с железом (возможно - с оперативной памятью).

Мне кажется, что это в FS сбой. Всё же, машина уже больше четырёх лет с непрерывным 24x365 io-wait работает. И в dmesg там куски reiserfs функций видны.

...

Хотя, конечно, мог и винт сдохнуть. Работающие разделы на другом лежат. А родной брат этого (IBM IC35L036UCD210-0) высыпал бэдблоками года два назад. Но, правда, не сдох, до сих пор там же размонтированный крутится и работоспособен.

>Попробуй запустить что-то типа cat /dev/sdX > /dev/null

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

...

Кстати, странно тогда, что mc при запуске виснет. Он же пишет только в ~, но /home у меня на другом разделе и работает отлично.

Процессы то висят в состоянии D (uninterruptible sleep)? Другие разделы тоже с райзером?

Попытался глянуть, в каком состоянии зависший mc (хотя сессию с ним уже закрыл):

ps ax|grep mc

Получил вывод двух совпадающий по подстроке процессов (тот де meMCached и сам grep) и завис.

Другие разделы с reiserfs работают отлично (/home и /var).

Гы. top виснет после первого цикла обновления. Раньше - не вис.

Походу, проблема должна быть в ядре.

Блин, дёрнул меня чёрт fstab редактировать... Глядишь, и перегрузилась бы машина. В крайнем случае - техподдержка бы там перегрузила. А теперь - придётся выписывать пропуск и ехать... Возможно только завтра.

Наверное, пора заказывать пропуск, раньше закажешь, раньше получишь доступ :)

Похоже на проблемы с памятью. Ядро покорёжено, ИМХО, скоро все остальное зависнет.

Jabber-сервер на том сервере работает :)

>Лезу из очередной ssh-сессии и вижу, что в /etc fstab исчез. Вообще.

Предположение конечно бредовое, но такое возможно, если на разделе кончилось место.

>такое возможно, если на разделе кончилось место

Я на это в первую очередь глянул, когда web-сервер стал 500-ю ошибку возвращать :) 3,7Гб свободно (из 33Гб).

а что за сервак? удаленно состояние винта посмотреть нельзя?
iLo там, или родные диаг. утилиты...

Да винт, ИМХО, уже не причём, top и ps виснуть не должны. Они же только /proc читают, значит чего-то прочитать не могут там, mc, возможно, тоже /proc читает.

>а что за сервак?

SE7500WV2 SCSI

>удаленно состояние винта посмотреть нельзя?

Х.з. кроме sdparm ничего не было.

Сумел отправить в перезагрузку (reboot без sync, на sync висло). Но, похоже, с концами. А то была надежда, что модификация fstab не записалась :)

Ура!!! fstab, действительно, не засинкался и машина загрузилась!! :)

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

а баг больше не воспроизводится?

И как, работает?

А что за дистрибутив?

>а баг больше не воспроизводится?

Я поправил fstab на тему проверки HDD и отправил в рестарт.

А то четыре года непрерывной работы без проверки - это как-то экстремально, кажется :)

>А что за дистрибутив?

Gentoo.

>Собираюсь отдать команду reboot, но вспоминаю, что в fstab не прописана проверка дисков на каждом перезапуске (они и так-то пару раз в год бывают...)

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

/dev/раздел был столько-то дней без проверки, check forced

Вторая перезагрузка прошла. Вроде, всё работает.

>во многих дистрах при ретких ребутах пишется

Да. Но я эту машину последний раз в глаза два года назад видел :) И перегружалась она последний раз полгода назад.

В /tmp лежит несколько файлов вида /tmp/sess_47b5497ce5~916bf47f5a9a63b нулевой длины и нулевой (1.1.1970) даты. Не удаляются, не открываются :)

А /tmp у вас на какой ФС?

Блин, как бы reiserfsck провести для корневого раздела удалённого сервера? Боюсь, что pass=1 в fstab нифига не помогает :)

>А /tmp у вас на какой ФС?

Там всё на reiserfs

Не считая этих трёх файлов, всё остальное работает отлично. Онлайн сайта уже под сотню.

ССЗБ.

> В /tmp лежит несколько файлов вида /tmp/sess_47b5497ce5~916bf47f5a9a63b нулевой длины и нулевой (1.1.1970) даты. Не удаляются, не открываются :)

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

> Gentoo.

Почему я не удивлен? =))

Увлекательная история.

Очень увлекательная история. С нетерпением жду продолжения. Но всё же, что она делает в Talks?

>ССЗБ.

Только давайте флейм не разводить. ext3 у меня уже дважды умирала. А reiserfs - ещё ни разу. Так что для себя по поводу production давно уже всё решено :)

Ну, наверное, можно перевести корень в ro и делать проверку.

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

Температура винтов сейчас 33-37 градусов.

Сбоев больше нет. Всё работает. Вот файлы нулевые - смущают :)

shutdown -rF

>Но всё же, что она делает в Talks?

Потому что тут уже упомянули reiserfs, gentoo... Скоро тут может быть очень шумно :)

>Ну, наверное, можно перевести корень в ro и делать проверку.

Увы:

# mount /dev/sda3 -o ro,remount
mount: / занят

>shutdown -rF

Ага.
-F Force fsck on reboot.

А оно точно лечить будет, а не просто проверит? :)

> Увы:
>
> # mount /dev/sda3 -o ro,remount
> mount: / занят

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

Не, ну понятно, что нужно отстреливать все процессы. То есть сайт не будет работать во время проверки. На всякий случай запустить ещё одни sshd на другом порту в chroot'e на другом разделе или на tmpfs.

не пробовал :)
но по теории должен лечить

> Блин, как бы reiserfsck провести для корневого раздела удалённого сервера? Боюсь, что pass=1 в fstab нифига не помогает :)

touch /forcefsck ?

Или надо в реальном времени наблюдать по ssh за ходом проверки?

Ладно, пока shutdown -rF запустил. После перезагрузки посмотрим :)