Срочно выйти из сна - headshot.php

В фильме Inception чтобы досрочно выйти из сна, нужно было умереть. Иногда подобная необходимость бывает и на сервере, когда нужно быстро прибить все запущенные запросы, а админского доступа нет.

Этот скрипт, будучи запущенным из браузера на сервере должен сделать эту работу

$ cat headshot.php
<?php
system('PHP_PPID=`ps -p $$ -o ppid=`; PHP_NAME=`ps -p $PHP_PPID -o comm=`; pkill -u `id -un` $PHP_NAME');

Почему не просто pkill -u `id -un`? Потому что имени пользователя под которым работают скрипты на сервере, может быть запущено много чего другого, которое не стоит убивать.

Протестируйте свою WHM/cPanel после обновления до 11.40

На прошлой неделе вышло обновление WHM/cPanel до версии 11.40. С этим обновлением связаны две проблемы, которые мне пришлось решать в понедельник, возможно сей пост кому-то сэкономит время.

У нас есть самописный плагин для cPanel, который автоматизирует установку и конфигурирование сайтов на основе magento для отдела QA. И после обновления этот плагин прекратил нормально работать.

В процессе дебага нашлась причина - наш плагин запрашивает через API пароль пользователя, который производит установку и в новом релизе этот функционал перестал нормально работать. В документации на этот вызов сказано, что пароль может быть недоступен, но сейчас он просто не резолвится, оставаясь названием переменной.

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

Попробовал пересобрать конфигурацию веб-сервера

# /scripts/rebuildhttpdconf

Но в ответ выдает ругань вида

[Mon Nov 11 10:31:36 2013] [crit] (EAI 9)Address family for hostname not supported: alloc_listener: failed to set up sockaddr for ::

Configuration problem detected on line 170 of file /usr/local/apache/conf/httpd.conf.work.PsABU7IkikfQtoi0:     Listen setup failed

        --- /usr/local/apache/conf/httpd.conf.work.PsABU7IkikfQtoi0 ---

Ругается на ipv6 опцию и конфиг сервера не перезагружается. В новом релизе появилась поддержка IPv6 и следовательно, где-то нужно дать пинка, чтобы заработало. Немного пробежавшись по форумам cpanel нашел, что нужно просто пересобрать текущую конфигурацию в EasyApache.

# /scripts/easyapache

После завершения сборки все начинает работать.

Уменьшение разряда батареи при использовании Suspend-to-RAM

Мне нравится использовать suspend to ram (STR или S3 в терминологии ACPI) на ноутбуке. Помимо быстрого выхода из режима сна это самый надежный способ заблокировать экран и клавиатуру ноутбука от детей. Есть лишь один недостаток - постоянный разряд батареи, связанный с поддержанием работы оперативной памяти. Если батарея разрядится, то все несохраненные данные будут потеряны.

Для защиты от потери данных в режиме STR в linux есть режим гибридного сна (suspend-hybrid) - в этом режиме состояние памяти сохраняется на диск, как при hibernate (suspend to disk или S4 в терминологии ACPI), но вместо отключения питания система переходит в состояние S3 или suspend to ram. В этом случае при достаточном заряде батареи система мгновенно просыпается как из suspend to ram, а если батарея разрядится, то как из suspend to disk. Все хорошо, но одно НО - батарея все равно разряжается, когда ноутбук находится в режиме такого сна. Это может быть критично в поездке или когда ноутбук длительное время не используется. Поскольку сохранность данных и постоянная готовность ноутбука к работе для меня важнее скорости загрузки, то я перешел на использование hibernate и пользовался им в течении нескольких лет.

Пару дней назад я натолкнулся на элегантное решение проблемы - переключение из режима S3 в S4 без участия пользователя. Кажется я такое уже наблюдал в Windows 7, но не придавал этому значения. Оказывается все очень просто. В процессе подготовки к suspend to ram менеждер питания выполняет установку системного таймера (будильника в BIOS), который включит систему через определенное время. Затем система выполняет обычную подготовку и переходит в режим S3. Далее два варианта:

• если пользователь включит систему до срабатывания системного будильника, то система пробуждается из режима S3 и переходит в режим нормальной работы;
• если будильник срабатывает в режиме сна, то система загружается, определяет что пробуждение не было инициировано пользователем (система включилась по событию таймера в BIOS) и сразу же выполняется переход в режим S4 (suspend to disk).

Интервал, после которого система переходит из одного состояния в другое настраивается. Этой схемой я пользуюсь уже несколько дней и проблем пока не замечал.

W: Ошибка GPG: http://www.tataranovich.com wheezy Release

Если при apt-get update у вас произошла подобная ошибка

W: Ошибка GPG: http://www.tataranovich.com wheezy Release: Следующие подписи неверные: KEYEXPIRED 1379680799

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

$ sudo apt-key adv --keyserver pgp.mit.edu --refresh-keys 2EE7EF82

После этого нужно снова запустить apt-get update

Как НЕ нужно делать logrotate

В одном из OpenVZ контейнеров постоянно дох munin-node, причем записи в логе говорили о том, что ему "помогли".

2013/10/26-04:02:02 Server closing!
2013/10/26-04:02:02 HUP'ing server
Can't exec "munin-node": Нет такого файла или каталога at /usr/share/perl5/Net/Server.pm line 1162.
shutdown() on closed socket GEN0 at /usr/lib/perl/5.10/IO/Socket.pm line 294.

В контейнере стоит Debian Squeeze и аналогичные контейнеры в сети еще есть, но постоянно дохнет только один. Судя по дате это что-то из набора cron.daily, который как правило стартует в 4:00, но в контейнере /etc/logrotate.d/munin-node, не шлет HUP после ротирования. Ради интереса стартанул весь logrotate

logrotate -f /etc/logrotate.conf

После завершения проверил munin-node - все в порядке. И тут меня осенило, ведь на сервере, который hardware node у OpenVZ тоже стоит munin-node. Разница лишь в том, что на hardware node установлен ALTLinux, а не Debian.

Иду смотреть /etc/logrotate.d/munin-node на ноде

/var/log/munin/munin-node.log {
        create 640 _munin root
        daily
        postrotate
                killall -q -HUP munin-node
        endscript
}

Редиски! Они шлют HUP всем процессам, а не только тому, который указан в PID-файле. Луч поноса QA команде ALTLinux и создателю этого костыля в частности.

Заменил вызов killall на /etc/init.d/munin-node reload - теперь и лог ротируется и в контейнере не дохнет.

Сломались отчёты 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.

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