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

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

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.