Сломались отчёты sysstat: Invalid system activity file: /var/log/sysstat//sa24

Если вам на почту пришло письмо вроде этого

/etc/cron.daily/sysstat:
Invalid system activity file: /var/log/sysstat//sa24

то скорее всего у вас изменилась конфигурация железа (в моём случае проапгрейдили сервер и ядер процессора стало больше). Баг известный и исправить его можно так:

# rm /var/log/sysstat/sa`date +'%d'`
# service sysstat start

Для уверенности через минут 10 проверьте результат, выполнив

# sar -A

Три почивших диска за последних три месяца

Я не питаю иллюзий по поводу надёжности SATA дисков, но такое на моей памяти впервые. В течении трёх месяцев, один за другим умерло три диска Seagate NS серии (один 2TB и два 750GB).

Сейчас как раз переношу данные с последнего мертвеца. Прошлые ограничивались парой Offline Uncorrectable в S.M.A.R.T., но сегодняшний покойничек дал дуба эффектно

ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: BMDMA stat 0x64
ata1.00: cmd 25/00:08:c3:74:25/00:00:52:00:00/e0 tag 0 dma 4096 in
         res 51/40:00:ca:74:25/40:00:52:00:00/00 Emask 0x9 (media error)
ata1.00: status: { DRDY ERR }
ata1.00: error: { UNC }
ata1.00: configured for UDMA/133
ata1.01: configured for UDMA/133
sd 0:0:0:0: Unhandled sense code
sd 0:0:0:0: SCSI error: return code = 0x08000002
Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
sda: Current [descriptor]: sense key: Medium Error
    Add. Sense: Unrecovered read error - auto reallocate failed

Descriptor sense data with sense descriptors (in hex):
        72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
        52 25 74 ca
EXT3-fs error (device sda3): ext3_get_inode_loc: <6>ata1: EH complete
unable to read inode block - inode=171738553, block=171737135

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

The following warning/error was logged by the smartd daemon:

Device: /dev/sda, FAILED SMART self-check. BACK UP DATA NOW!

For details see host's SYSLOG.

Дальше по уже накатанной дорожке.

Dell OpenManage installation on CentOS

Complete guide can be found here. If you want to skip reading you can execute following commands:

# wget -q -O - http://linux.dell.com/repo/hardware/latest/bootstrap.cgi | bash
# yum install srvadmin-all

After packages installation you should start OMSA services and add them to autostart

# /opt/dell/srvadmin/sbin/srvadmin-services.sh start
# /opt/dell/srvadmin/sbin/srvadmin-services.sh enable

To enter OMSA you should navigate to https://your-server-ip:1311/ in your browser (login as user root and use related password). You may need to enable incoming connections to 1311/TCP port in your firewall.

# /sbin/iptables -A INPUT -p tcp --dport 1311 -j ACCEPT

Привел в порядок репозиторий

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

Сейчас бинарные пакеты для Mignight Commander (release и nightly) собираются для Debian Squeeze/Wheezy/Jessie/Sid и Ubuntu Lucid/Precise/Quantal/Raring/Saucy (i386 и amd64).

Из репозитория окончательно удалены ветки для Debian Lenny и Ubuntu Natty/Maverick/Oneiric. Заодно удалены устаревшие версии wine-unstable и стабильного midnight commander.

Расчет критических значений Load Average для системы мониторинга сервера

Сегодня подкручивал настройки Nagios и решил добавить статью по расчету значений лимитов load average для различных конфигураций серверов. Чтобы понимать суть load average я советую прочесть эту статью.

Поскольку лимиты load average зависят от количества доступных ядер процессора, то у различных серверов будут значения будут различаться. Наиболее распространенные варианты конфигурации процессоров:

• 1 физическое ядро
• 2 физических ядра
• 2 физических ядра + hyperthreading (4 виртуальных ядра)
• 4 физических ядра
• 4 физических ядра + hyperthreading (8 виртуальных ядер)

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

State/Load Average	1 min	5 min	15 min
Warning	CPU cores * 2	CPU cores * 1.5	CPU cores * 1.25
Critical	CPU cores * 4	CPU cores * 2	CPU cores * 1.5

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

#!/bin/bash
if [ `grep -c processor /proc/cpuinfo` != 1 ]; then
    grep 'core id' /proc/cpuinfo | sort | uniq | wc -l
else
    echo 1
fi

Готовые значения лимитов для плагина check_load из состава Nagios.

• Single core: check_load -w 2,1.5,1.25 -c 4,2,1.5
• Dual core: check_load -w 4,3,2.5 -c 8,4,3
• Quad core: check_load -w 8,6,5 -c 16,8,6

Преобразование имен файлов при распаковке архива tar

Если вам попался архив tar вида

$ tar -tf /tmp/backup_2013-07-31.tar.gz
backups/servers/server.example.org/var/www/example.org/file1
backups/servers/server.example.org/var/www/example.org/file2
backups/servers/server.example.org/var/www/example.org/file3
...
backups/servers/server.example.org/var/www/example.org/fileN

и распаковать его нужно в /var/www/example.org желательно не применяя mv, то сделать это можно так:

$ tar --strip-components=6 --show-transformed -xvf /tmp/backup_2013-07-31.tar.gz -C /var/www/example.org
file1
file2
file3
...
fileN

У tar еще есть опция --transform, которая позволяет сделать произвольную замену имени в отличии от --strip-components, которая только отбрасывает нужное количество уровней вложенности.

$ tar --transform 's,backups/servers/server.example.org/var/www/example.org,example.com,g' --show-transformed -xvf /tmp/backup_2013-07-31.tar.gz -C /var/www
example.com/file1
example.com/file2
example.com/file3
...
example.com/fileN

История спасения данных с "умирающего" жесткого диска

Очередное утро началось с чтения письма от smartd. Один из дисков сервера, который используется для резервного копирования всех остальных серверов, начал свой путь в лучший мир. В письме говорилось о появлении одного pending sector, но пока я ехал в офис от smartd пришло второе письмо, в котором говорилось, что этот сектор уже перешел в разряд offline uncorrectable. А вот это уже плохо, значит с большой долей вероятности считать данные из этого сектора уже не удастся.