среда, 18 мая 2011 г.

Новые проблемы с hibernate на моем eeepc.

Я уже упоминал о проблемах в работе hibernate (он же suspend to disk) в одном из своих предыдущих постов. Тогда я откатил ядро и отправил баг, на большее времени не хватило.

Теперь я решил вернуться к проблеме, так как она получила новый виток. Началось с того, что после выхода из hibernate перестали запускаться приложения. В dmesg видно, что падения вызывает segfault. Причем падает не все подряд, а только часть.

May 13 07:16:25 dragoncore kernel: [ 4374.516022] egrep[10517]: segfault at 9eef73d ip 080510fa sp bfcd5a8c error 6 in egrep[8048000+18000]
May 18 07:22:56 dragoncore kernel: [10412.759167] urxvt[22902]: segfault at 42a648c8 ip b70e7020 sp bf95d2a0 error 6 in libperl.so.5.10.1[b70a9000+14a000]
По причине того, что проблема не всегда воспроизводится а также хронической нехватки времени я просто перезагружал нетбук и продолжал работу. Сегодня мое терпение лопнуло и я решил разобраться в проблеме. Т.к. у меня стоит debsums, то я первым делом запустил проверку целостности пакетов

sudo debsums | grep -v OK$
Таким образом ищутся файлы, контрольная сумма которых не совпадает с эталоном. Нашло несколько несовпадений
/usr/bin/dbus-daemon                      FAILED
/lib/libdbus-1.so.3.4.0                        FAILED
/usr/lib/libgobject-2.0.so.0.2400.2            FAILED
/bin/zsh4                                      FAILED
После перезарузки проверка была уже без ошибок.

Для чистоты эксперимента система была обновлена до актуального squeeze + ядро до 2.6.32-31. После как и полагается нетбук был перезагружен. Далее для выяснения причины попробовал запустить бесконечный цикл из связки hibernate и debsums. Чтобы не приходилось каждый раз включать ноутбук, я заменил в /etc/uswsusp.conf

shutdown method = platform
на
shutdown method = reboot
Теперь после засыпания на диск происходит перезагрузка, а не отключение питания. Для большей автоматизации был написан скрипт
#!/bin/bash

PREFIX=/var/log
COUNT=0

while true
do
dmesg -c > /dev/null
sync
pm-hibernate
let COUNT=${COUNT}+1
echo -e "DMESG\n\n*****\n\n" | tee ${PREFIX}/hibernate.${COUNT}.log
dmesg | tee -a ${PREFIX}/hibernate.${COUNT}.log
echo -e "\n\nDEBSUMS\n\n*****\n\n" | tee -a ${PREFIX}/hibernate.${COUNT}.log
debsums | tee -a ${PREFIX}/hibernate.${COUNT}.log | grep -v OK$
if [ $? == 0 ]; then
echo -e "\n\nDetected corruption!\n\n" | tee -a ${PREFIX}/hibernate.${COUNT}.log
dmesg | tee -a ${PREFIX}/hibernate.${COUNT}.log
sync
exit 1
fi
done
Скрипт выполнялся до тех пор, пока debsums не находил "поврежденные" файлы. Из двух прогонов за сегодня первая ошибка была на 14-й итерации, а второй раз нашло на 2-ой.
Пока я выкрутился через suspend-hybrid (благо новая батарея это позволяет). Завтра попробую тоже самое, но без использования KMS.

пятница, 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
Осталось вытащить его из сервера и сдать по гарантии =)

среда, 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"

Сломался 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
- все в порядке, включение прошло без проблем, осталось отписаться о проблеме разработчикам.

среда, 13 октября 2010 г.

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

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

понедельник, 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)

понедельник, 4 октября 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 для любого сисадмина.