21 января 2011

Отключение сбойного жесткого диска без остановки сервера

Придя сегодня на работу, обнаружил, что девелоперский сервер в глубокой "задумчивости". При попытке пинговать его выявилась значительная потеря пакетов. Через минуту смог залогиниться через SSH - сказывались потери пакетов. Первый делом на проблемной машинке глянул
# dmesg | tail
SCSI device sdb: 490350672 512-byte hdwr sectors (251060 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd b0/da:00:00:4f:c2/00:00:00:00:00/00 tag 0
         res 40/00:00:5f:00:00/00:00:00:00:00/e0 Emask 0x4 (timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata3.00: configured for UDMA/33
ata3: EH complete
SCSI device sdb: 490350672 512-byte hdwr sectors (251060 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata3.00: cmd b0/da:00:00:4f:c2/00:00:00:00:00/00 tag 0
         res 40/00:00:5f:00:00/00:00:00:00:00/e0 Emask 0x4 (timeout)
ata3.00: status: { DRDY }
ata3: soft resetting link
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata3.00: configured for UDMA/33
ata3: EH complete
Видимо один из 4-х дисков приказал долго жить и его срочно нужно отключить от RAID. Самое интересное, что за полтора часа, пока сервер загибался, сбойный винт не пометило как сбойный.
Чтобы извлечь нужный диск и потом отключить его физически нужно знать его S/N (у нас стоят 4 одинаковых WDC WD2502ABYS - поэтому просто по производителю глянуть не получится).
Пробую найти сбойный диск перебирая все винты на сервере
for hdd in sda sdb sdc sdd; do smartctl -d ata -a /dev/$hdd | grep ^194; done
Скрипт залипает на /dev/sdb, исключаю его из перебора и пробую вновь. На этот раз отрабатывает без ошибок.
Теперь остается выяснить его серийный номер (S/N):
# ls -l /dev/disk/by-id/scsi-SATA_WDC_WD2502ABYS-_WD-WCAT1E8* |grep sdb$
lrwxrwxrwx 1 root root  9 Окт 25 10:39 /dev/disk/by-id/scsi-SATA_WDC_WD2502ABYS-_WD-WCAT1E882772 -> ../../sdb
Получается что его S/N WCAT1E882772. Теперь извлекаем его из raid:
mdadm --manage /dev/md0 --fail /dev/sdb1 --remove /dev/sdb1
mdadm --manage /dev/md1 --fail /dev/sdb2 --remove /dev/sdb2
Остается остановить диск, чтобы система не пыталась его переинициализировать:
# ls -ld /sys/class/scsi_device/*/device/block:sdb
lrwxrwxrwx 1 root root 0 Янв 21 10:03 /sys/class/scsi_device/2:0:0:0/device/block:sdb -> ../../../../../../block/sdb

# echo 1 > /sys/class/scsi_device/2:0:0:0/device/delete
Проверяем, остановлен ли диск
# dmesg |tail

SCSI device sdb: 490350672 512-byte hdwr sectors (251060 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: drive cache: write back
ata3.00: disabled
Осталось вытащить его из сервера и сдать по гарантии =)

Вы можете следить за обновлениями блога с помощью Atom/RSS и Telegram.

19 января 2011

Синхронизация времени в Windows

Сетаплю винду на компе для нового сотрудника, решил разобраться в синхронизации времени в винде. Раньше обходился NetTime и отключал встроенную службу "Windows Time".
Поискал в инете - получилось что-то вроде:
\> net time /setsntp:172.16.0.1
\> net time /querysntp
The current SNTP value is: 172.16.0.1

\> net stop w32time
\> net start w32time
Теперь время синхронизируется через службу "Windows Time"

Вы можете следить за обновлениями блога с помощью Atom/RSS и Telegram.

Сломался hibernate на моей eeepc'шке

Началось все со странной перезагрузки при попытке разбудить ноутбук из hibernation. Вроде процесс восстановления прошел, но вместо скринсейвера я увидел логотип асуса и последующую загрузку и проверку разделов на винте. Время было позднее и я не придал этому никакого значения - рещил, что был аппаратный сбой.
На следующий день история повторилась на работе. Времени разбираться не было и оставил как есть. Ближе к вечеру появилось свободное время - решил разобраться, что сломалось. Прикинул что дня три назад все еще работало, а значит нужно искать проблему в изменениях за последние двое суток. Вспомнилось, что делал обновления до текущего Debian Squeeze и обновилось что-то в районе ядра и прошивки для беспроводной карточки. Дома, где впервые заметил проблему, ноут засыпает с включенным wi-fi - и сразу напрашивалось, что сбоит включенная карточка в момент выхода ноута из спячки.
Попробовал сделать hibernate и снова включить ноут, но уже с отключенным wi-fi - результатом была та же перезагрузка. Начал искать причину среди недавних апдейтов ядра и системы засыпания. На тот момент стояло linux-image-2.6.32-5-686, uswsusp и pm-utils (работает поверх uswsusp). Поискал последние изменения в пакетной базе
$ grep 'status installed' /var/log/dpkg.log

2011-01-17 16:30:35 status installed linux-base 2.6.32-30
2011-01-17 16:31:09 status installed linux-image-2.6.32-5-686 2.6.32-30
2011-01-17 16:31:11 status installed firmware-linux-free 2.6.32-30
2011-01-17 16:31:11 status installed linux-libc-dev 2.6.32-30
Ядро обновилось с версии 2.6.32-29 на 2.6.32-30 - пошел читать changelog. Вроде ничего подозрительного не видно, решил глянуть upstream changelog, вот в нем и нашлось изменение в районе подсистемы PM / Hibernate
commit 012f9fdfd2965f573171f848d1aa46531cab7062
Author: Takashi Iwai 
Date:   Fri Dec 10 00:16:39 2010 +0100

    PM / Hibernate: Fix PM_POST_* notification with user-space suspend
    
    commit 1497dd1d29c6a53fcd3c80f7ac8d0e0239e7389e upstream.
    
    The user-space hibernation sends a wrong notification after the image
    restoration because of thinko for the file flag check.  RDONLY
    corresponds to hibernation and WRONLY to restoration, confusingly.
    
    Signed-off-by: Takashi Iwai 
    Signed-off-by: Rafael J. Wysocki 
    Signed-off-by: Greg Kroah-Hartman 

Полное описание комита
Решил откатиться на версию 2.6.32-29 и зафиксировать версию ядра, пока проблема не будет решена. Старую версию взял со snapshot.debian.org
Установка
$ wget http://snapshot.debian.org/archive/debian/20101211T031516Z/pool/main/l/linux-2.6/linux-image-2.6.32-5-686_2.6.32-29_i386.deb \
http://snapshot.debian.org/archive/debian/20101211T031516Z/pool/main/l/linux-2.6/linux-libc-dev_2.6.32-29_i386.deb \
http://snapshot.debian.org/archive/debian/20101210T205106Z/pool/main/l/linux-2.6/linux-base_2.6.32-29_all.deb \
http://snapshot.debian.org/archive/debian/20101210T205106Z/pool/main/l/linux-2.6/firmware-linux-free_2.6.32-29_all.deb
$ sudo dpkg -i *2.6.32*.deb
Фиксация версии в пакетной базе
$ sudo aptitude hold linux-image-2.6.32-5-686 firmware-linux-free linux-base linux-libc-dev
Перезагрузка и пробую засыпать на диск:
pm-hibernate
- все в порядке, включение прошло без проблем, осталось отписаться о проблеме разработчикам.

Вы можете следить за обновлениями блога с помощью Atom/RSS и Telegram.

13 октября 2010

О необходимости тестирования памяти

До недавнего времени верил, что для проверки планки памяти на живучесть достаточно один раз прогнать memtest86+ и можно ставить. Вот только после установки двух планок памяти (по гигу каждая) в комп, он начал спонтанно перезагружаться с завидной частотой.
Вернул старые планки (по 512MB) и все заработало как раньше. Две новые поставил на стенд и запустил memtest на бесконечное тестирование. После одного прогона нашло одну ошибку при битовых операциях. Решил поменять планки местами. До ухода домой успело проверить два раза и не нашло ни одной ошибки - оставил на ночь. Утром из девяти повторений теста нашло две ошибки в процессе выполнения третьего.
Вот сейчас сижу и думаю, что может быть причиной "плавающей" ошибки при работе с памятью. На перегрев не похоже - стенд стоит без корпуса и прекрасно охлаждается. Возможно память глючит на максимальной частоте, но в компе, где она приводила к ребутам, планки работали на пониженной частоте (планки A-Data DDR400, работали как DDR333).

Вы можете следить за обновлениями блога с помощью Atom/RSS и Telegram.

11 октября 2010

Восстановление битого раздела

Начало истории тут
В субботу вечером остановил все, что использует битый раздел. Потом создал образ с тома LVM и загрузил на отдельную машинку.
root@server # dd if=/dev/vg/badlv of=/mnt/tmp/badlv.bin bs=8M
root@server # smbclient -N //rescue/share
> lcd /mnt/tmp
> put badlv.bin
Там раздел монтировался через loop в read-only режиме.
root@rescue # mount -o ro,acl,loop /mnt/share/badlv.bin /mnt/tmp
На сервере создал раздел с XFS того же размера и запустил rsync с примонтированного образа на сервер.
root@server # lvcreate -n newlv -L50G vg
root@server # mkfs.xfs /dev/vg/newlv
root@server # mount /dev/vg/newlv /mnt/repaired
root@rescue # rsync -aAz /mnt/tmp/ server:/mnt/repaired
Утром в воскресенье меня ждала пачка сообщений о том, что на новом разделе XFS закончилось место и копирование накрылось медным тазом. Перед повторным запуском добавил 20GB к емкости раздела и расширил том и снова запустил rsync.
root@server # lvresize -L+20G /dev/vg/newlv
root@server # xfs_growfs /mnt/repaired
На этот раз копирование заняло все воскресенье и часть ночи понедельника, но данные успешно перенеслись, за исключением пары битых атрибутов ACL (скорее всего попытка их чтения на сервере и приводила к kernel panic)

Вы можете следить за обновлениями блога с помощью Atom/RSS и Telegram.

04 октября 2010

Kernel panic debug

На днях отлаженный скрипт бэкапа начал рапортовать об обрыве связи в процессе создания бэкапа. Происходило это в произвольный момент времени ночью.
Очевидно, что сбой вызывал процесс бэкапа, ведь нагрузка на дисковую подсистему создается много большая, чем при штатной работе сервера днём. В пользу сбоев дисковой системы говорил и тот факт, что не было сообщения об ошибке в системных журналах. Т.е. вероятнее всего имею дело с kernel panic. На сервере стоит опция panic=30 - при панике ядра через 30 секунд произойдет автоматическая перезагрузка сервера.
После некоторых раздумий выработал несколько решений:

  • Отключить опцию panic=30 и утром посмотреть что за сообщение будет на экране. У этого подхода есть минус, если сообщение окажется больше одного экрана, то не получится его посмотреть целиком.
  • Собрать null-модемный кабель и загрузить систему с перенаправлением системной консоли в последовательный порт, а для отлова сообщения об ошибке использовать отдельную машину, подключенную к null-модемному кабелю.
  • Случайно нагуглил еще один подход. Он состоит в загрузке дополнительного модуля netconsole, который выполняет роль null-модемного кабеля через IP сеть. Сообщение передается в UDP пакетах и чтобы его смотреть достаточно использовать netcat.

Выбрал последний подход. Загрузил модуль с параметрами:
modprobe netconsole netconsole="src-port@src-ip/src-iface,dst-port@dst-ip/dst-mac"

У себя на компьютере запустил netcat nc -l -u -p dst-port, где заменил src-/dst- константы на соответствующие параметры. Утром меня ждало сообщение о сбое в модуле reiserfs. Проверка радздела на 70GB заняла более полутора часов, причем мое терпение лопнуло, после начала проверки семантики FS, после проверки BTREE структуры. Впереди еще предстоит починка FS и спасение данных, но мое отношение к reiserfs здорово переменилось, теперь подумываю о миграции на XFS/JFS.
Для себя сделал вывод, что иметь нуль-модемный кабель + свободный COM-порт на соседней машинке - это must-have для любого сисадмина.

Вы можете следить за обновлениями блога с помощью Atom/RSS и Telegram.

26 июля 2010

Сокрытие версии апача и php в ответе сервера.

Понадобилось скрыть версии апача и php в ответе сервера. С ходу нагуглил решение для апача и php. Себе помечу как памятку.

Apache
ServerTokens ProductOnly
ServerSignature Off

PHP
expose_php = Off

Вы можете следить за обновлениями блога с помощью Atom/RSS и Telegram.