LINUX.ORG.RU
Форум — Talks  

Нужно срочно спасать удалённый сервер! :)


0

0
Сегодня утром просыпаюсь - web-сервер выдаёт 500-ю ошибку.

Попытка перезапустить web-сервер привела к завису процесса в момент старта.

Соединяюсь по SSH ещё раз. Запускаю mc - виснет на старте.

В dmesg длинный ряд ошибок (закину потом, а то форум не пущает):

...

Собираюсь отдать команду reboot, но вспоминаю, что в fstab не прописана проверка дисков на каждом перезапуске (они и так-то пару раз в год бывают...) Лезу прописывать. mcedit виснет, а вот nano открывает файл на ура. Сохраняю. nano на сохранении виснет.

Да, зависшие программы не убиваются по Ctrl-C/Ctrl-Z.

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

Соответственно, машину перезапускать нельзя.

И вот теперь в непонятнках, что делать. Сейчас попытаюсь создать новый файл. Но боюсь обломаться.

...

А ехать на колокейшн - история тяжёлая, однако. Там за сутки вперёд пропуск заказывать надо :)
★★★★★
← Подскажите сайт где люди пробуют ОС Linux на XBOX360 поставить
Запрос инфы →
 ← 1 2 
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]
KRoN73 ★★★★★
() автор топика
Попытка создать новый файл в /etc - завис.

Попытка перемонтировать / в ro - завис.
KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73
Либо что-то очень мощно заглючило в ядре, либо проблема с железом (возможно - с оперативной памятью).
Deleted
()
Работа с другими разделами идёт, вроде, без проблем. В dmesg новых ошибок нет.

...

Чёрт, как бы починить активный корневой раздел? :) Говорила мне мама, раскидывай все компоненты системы по разным разделам... Домашнюю бы машину в таком состоянии раз плюнуть починил бы удалённо :-/
KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73
Попробуй запустить что-то типа cat /dev/sdX > /dev/null. Если и так зависнет, то думаю что-либо сделать будет не реально.
Deleted
()
Ответ на: комментарий от KRoN73
Мне кажется с железом проблема...

В общем все плохо=)
delilen ★☆
()
Ответ на: комментарий от Deleted
>Либо что-то очень мощно заглючило в ядре, либо проблема с железом (возможно - с оперативной памятью).

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

...

Хотя, конечно, мог и винт сдохнуть. Работающие разделы на другом лежат. А родной брат этого (IBM IC35L036UCD210-0) высыпал бэдблоками года два назад. Но, правда, не сдох, до сих пор там же размонтированный крутится и работоспособен.
KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от Deleted
>Попробуй запустить что-то типа cat /dev/sdX > /dev/null

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

...

Кстати, странно тогда, что mc при запуске виснет. Он же пишет только в ~, но /home у меня на другом разделе и работает отлично.
KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от mky
Попытался глянуть, в каком состоянии зависший mc (хотя сессию с ним уже закрыл):

ps ax|grep mc

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

Другие разделы с reiserfs работают отлично (/home и /var).
KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от mky
Гы. top виснет после первого цикла обновления. Раньше - не вис.

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

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

mky ★★★★★
()
Jabber-сервер на том сервере работает :)
KRoN73 ★★★★★
() автор топика
>Лезу из очередной ssh-сессии и вижу, что в /etc fstab исчез. Вообще.

Предположение конечно бредовое, но такое возможно, если на разделе кончилось место.
madcore ★★★★★
()
Ответ на: комментарий от madcore
>такое возможно, если на разделе кончилось место

Я на это в первую очередь глянул, когда web-сервер стал 500-ю ошибку возвращать :) 3,7Гб свободно (из 33Гб).
KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от madcore
а что за сервак? удаленно состояние винта посмотреть нельзя?
iLo там, или родные диаг. утилиты...
kott ★★★★★
()
Ответ на: комментарий от KRoN73
Да винт, ИМХО, уже не причём, top и ps виснуть не должны. Они же только /proc читают, значит чего-то прочитать не могут там, mc, возможно, тоже /proc читает.
mky ★★★★★
()
Ответ на: комментарий от kott
>а что за сервак?

SE7500WV2 SCSI

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

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

Сумел отправить в перезагрузку (reboot без sync, на sync висло). Но, похоже, с концами. А то была надежда, что модификация fstab не записалась :)
KRoN73 ★★★★★
() автор топика
скорее всего это память глючит. Я с таким уже сталкивался, когда чтение проходит нормально, а любая попытка записи подвешивает процесс. Причем подвешивались только новые процессы, старые, которые уже успели отхапать себе рабочие блоки памяти, работали нормально
JB ★★★★★
()
Ответ на: комментарий от JB
>а баг больше не воспроизводится?

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

А то четыре года непрерывной работы без проверки - это как-то экстремально, кажется :)
KRoN73 ★★★★★
() автор топика
>Собираюсь отдать команду reboot, но вспоминаю, что в fstab не прописана проверка дисков на каждом перезапуске (они и так-то пару раз в год бывают...)

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

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

kott ★★★★★
()
Ответ на: комментарий от KRoN73
Вторая перезагрузка прошла. Вроде, всё работает.
KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от kott
>во многих дистрах при ретких ребутах пишется

Да. Но я эту машину последний раз в глаза два года назад видел :) И перегружалась она последний раз полгода назад.
KRoN73 ★★★★★
() автор топика
В /tmp лежит несколько файлов вида /tmp/sess_47b5497ce5~916bf47f5a9a63b нулевой длины и нулевой (1.1.1970) даты. Не удаляются, не открываются :)
KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73
Блин, как бы reiserfsck провести для корневого раздела удалённого сервера? Боюсь, что pass=1 в fstab нифига не помогает :)
KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73
Не считая этих трёх файлов, всё остальное работает отлично. Онлайн сайта уже под сотню.
KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73
> В /tmp лежит несколько файлов вида /tmp/sess_47b5497ce5~916bf47f5a9a63b нулевой длины и нулевой (1.1.1970) даты. Не удаляются, не открываются :)

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

Darkman ★★★
()

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

Очень увлекательная история. С нетерпением жду продолжения. Но всё же, что она делает в Talks?
Camel ★★★★★
()
Ответ на: комментарий от Ramen
>ССЗБ.

Только давайте флейм не разводить. ext3 у меня уже дважды умирала. А reiserfs - ещё ни разу. Так что для себя по поводу production давно уже всё решено :)
KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от Darkman
>На XFS, к примеру, такие глюки говорят об однозначных проблемах с железом. Или о перегреве.

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

Сбоев больше нет. Всё работает. Вот файлы нулевые - смущают :)
KRoN73 ★★★★★
() автор топика
Ответ на: Увлекательная история. от Camel
>Но всё же, что она делает в Talks?

Потому что тут уже упомянули reiserfs, gentoo... Скоро тут может быть очень шумно :)
KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от mky
>Ну, наверное, можно перевести корень в ro и делать проверку.

Увы:

# mount /dev/sda3 -o ro,remount
mount: / занят
KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73
> Увы:
>
> # mount /dev/sda3 -o ro,remount
> mount: / занят

Думаю для этого надо сначала убить все процессы, у которых могут быть открыты файлы на запись.
Deleted
()
Ответ на: комментарий от KRoN73
Не, ну понятно, что нужно отстреливать все процессы. То есть сайт не будет работать во время проверки. На всякий случай запустить ещё одни sshd на другом порту в chroot'e на другом разделе или на tmpfs.
mky ★★★★★
()
Ответ на: комментарий от KRoN73
не пробовал :)
но по теории должен лечить
kott ★★★★★
()
Ответ на: комментарий от KRoN73
> Блин, как бы reiserfsck провести для корневого раздела удалённого сервера? Боюсь, что pass=1 в fstab нифига не помогает :)

touch /forcefsck ?

Или надо в реальном времени наблюдать по ssh за ходом проверки?
Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2
← Подскажите сайт где люди пробуют ОС Linux на XBOX360 поставить
Talks
Запрос инфы →