{toc}
h1. Описание проблемы
Недавно имела место проблема (подробнее - https://twitter.com/carbon_reductor/status/638653119556096000 ), приводившая к постепенному повисанию сервера, после этого могли возникнуть
Статья актуальна в ситуации, когда при обновлении Carbon Reductor произошёл kernel panic или сбой питания, дисковый кэш не успел записаться на диск и в итоге Carbon Reductor не стартует, либо сервер уходит в панику при старте.
В случае паники при старте - отключите автостарт редуктора по [этой статье|reductor5:Kernel Panic при загрузке].
Одним из основных признаков этой проблемы может служить вес папки:
{code}
du -sh /usr/local/Reductor
{code}
около 600кб, вместо 90мб.
*Внимание! Статья имеет потенциально опасные действия, не выполняйте их не убедившись в том, что проблема имеет место.*
h1. Полуавтоматическое восстановление (экспериментально)
{code}
curl -L http://download5.carbonsoft.ru/reductor/september_hotfix.sh | bash #hotfix
chkconfig --level 345 reductor off #отключаем автостарт редуктора на случай паники при рестарте
sync
service reductor restart #здесь вероятна паника, не пугаемся
chkconfig --level 345 reductor on #в случае, если паники не было
service crond restart #он отключался, чтобы диагностика автоматически не стартанула редуктор до того как это потребуется
{code}
Если после этого сервер запаниковал - попробуйте повторить дважды.
Если паники продолжаются и после этого - переходим к ручному восстановлению ниже в статье, пункт "Проверьте, что сервер не уходит в панику при следующих действиях"
h1. Ручное восстановление:
Все дальнейшие действия лучше согласовывать с технической поддержкой.
h2. Приведите yum в рабочее состояние
{code}
yum info kernel
{code}
{code}
[root@reductor local]# yum info kernel
...
Ошибка: database disk image is malformed
{code}
эту ошибку можно исправить командой:
{code}
[root@reductor local]# yum clean dbcache
...
Сброс источников:base epel extras updates
6 sqlite файлы удалены
{code}
Если не работает или выдаёт ошибки связанные с no such table packages
{code}
rm -f /var/lib/rpm/__*
rpmdb --initdb
rpmdb -v --rebuilddb
sleep $((5*60))
yum info kernel
{code}
Если после этого yum info kernel выдаёт ошибку
{code}
sed -e 's|$releasever|6|g' -i /etc/yum.repos.d/CentOS-Base.repo
yum info kernel
{code}
Если и это не помогло - попробуйте разобраться с ним самостоятельно, либо забэкапьте старые версии Carbon Reductor командой:
{code}
tar cfz /root/reductors.tar.gz /usr/local/old_Reductor*
{code}
и слейте на внешний сервер и переустановите CentOS 6.7 (обязательно 6.7, да).
h2. Обновите ядро до последнего
Если yum в итоге заработал:
{code}
yum -y install kernel
sync
reboot
{code}
На текущий момент 01.09.2015 актуальное ядро - 2.6.32-573
h2. Удалите и установите Carbon Reductor заново
Скорее всего штатными средствами обновиться не удастся, т.к. yum будет считать, что версия - последняя.
Вручную это можно сделать так.
{code}
yum -y erase reductor
yum -y install http://download5.carbonsoft.ru/reductor/reductor.rpm
{code}
h2. Восстановите настройки из одного из бэкапов
h3. Если делали автоматические бэкапы
Если делали автоматический бэкап с помощью service reductor export и забирали на удалённый сервер
Залейте бэкап на сервер Carbon Reductor, например в файл
/root/reductor_backup_2015.08.28.tar.gz
и выполните
{code}
service reductor import /root/reductor_backup_2015.08.28.tar.gz
{code}
h3. Если бэкапы настроек и своих списков не были настроены
Просмотрите какой из бэкапов редуктора имеющийся на сервере имеет не пустой конфиг (число рядом с именем файла - число строк в нём):
{code}
wc -l /usr/local/old_Reductor*/userinfo/config
{code}
Подставьте версию этого редуктора в команду:
{code}
/bin/cp -vap /usr/local/old_Reductor.ВЕРСИЯ_РЕДУКТОРА/userinfo/* /usr/local/Reductor/userinfo/
/bin/cp -vap /usr/local/old_Reductor.ВЕРСИЯ_РЕДУКТОРА/lists/our.* /usr/local/Reductor/lists/
{code}
h2. Проверьте, что сервер не уходит в панику при следующих действиях
Для исключения побочных эффектов на время этого шага лучше выключить зеркало трафика
{code}
cd /usr/local/Reductor/reductor_container/lib/modules/
ls # скопируйте имя этой папки в буфер
ln -s имя_этой_папки $(uname -r)
chroot /usr/local/Reductor/reductor_container/
depmod -a
modprobe xt_reductor
modprobe ipt_FORBIDDEN
exit
rmmod xt_reductor
rmmod ipt_FORBIDDEN
{code}
h2. Попробуйте запустить Carbon Reductor
{code}
service reductor restart
{code}
затем запустите выгрузки
{code}
service reductor update
{code}
после них диагностику
{code}
service reductor check
{code}
если там нет ругани на что-то кроме tcpdump / проверенные пакеты, то включайте зеркало обратно, подождите 2 минуты и снова диагностику.
h2. Верните Carbon Reductor в автозагрузку
{code}
chkconfig --level 345 reductor on
{code}
h1. Описание проблемы
Недавно имела место проблема (подробнее - https://twitter.com/carbon_reductor/status/638653119556096000 ), приводившая к постепенному повисанию сервера, после этого могли возникнуть
Статья актуальна в ситуации, когда при обновлении Carbon Reductor произошёл kernel panic или сбой питания, дисковый кэш не успел записаться на диск и в итоге Carbon Reductor не стартует, либо сервер уходит в панику при старте.
В случае паники при старте - отключите автостарт редуктора по [этой статье|reductor5:Kernel Panic при загрузке].
Одним из основных признаков этой проблемы может служить вес папки:
{code}
du -sh /usr/local/Reductor
{code}
около 600кб, вместо 90мб.
*Внимание! Статья имеет потенциально опасные действия, не выполняйте их не убедившись в том, что проблема имеет место.*
h1. Полуавтоматическое восстановление (экспериментально)
{code}
curl -L http://download5.carbonsoft.ru/reductor/september_hotfix.sh | bash #hotfix
chkconfig --level 345 reductor off #отключаем автостарт редуктора на случай паники при рестарте
sync
service reductor restart #здесь вероятна паника, не пугаемся
chkconfig --level 345 reductor on #в случае, если паники не было
service crond restart #он отключался, чтобы диагностика автоматически не стартанула редуктор до того как это потребуется
{code}
Если после этого сервер запаниковал - попробуйте повторить дважды.
Если паники продолжаются и после этого - переходим к ручному восстановлению ниже в статье, пункт "Проверьте, что сервер не уходит в панику при следующих действиях"
h1. Ручное восстановление:
Все дальнейшие действия лучше согласовывать с технической поддержкой.
h2. Приведите yum в рабочее состояние
{code}
yum info kernel
{code}
{code}
[root@reductor local]# yum info kernel
...
Ошибка: database disk image is malformed
{code}
эту ошибку можно исправить командой:
{code}
[root@reductor local]# yum clean dbcache
...
Сброс источников:base epel extras updates
6 sqlite файлы удалены
{code}
Если не работает или выдаёт ошибки связанные с no such table packages
{code}
rm -f /var/lib/rpm/__*
rpmdb --initdb
rpmdb -v --rebuilddb
sleep $((5*60))
yum info kernel
{code}
Если после этого yum info kernel выдаёт ошибку
{code}
sed -e 's|$releasever|6|g' -i /etc/yum.repos.d/CentOS-Base.repo
yum info kernel
{code}
Если и это не помогло - попробуйте разобраться с ним самостоятельно, либо забэкапьте старые версии Carbon Reductor командой:
{code}
tar cfz /root/reductors.tar.gz /usr/local/old_Reductor*
{code}
и слейте на внешний сервер и переустановите CentOS 6.7 (обязательно 6.7, да).
h2. Обновите ядро до последнего
Если yum в итоге заработал:
{code}
yum -y install kernel
sync
reboot
{code}
На текущий момент 01.09.2015 актуальное ядро - 2.6.32-573
h2. Удалите и установите Carbon Reductor заново
Скорее всего штатными средствами обновиться не удастся, т.к. yum будет считать, что версия - последняя.
Вручную это можно сделать так.
{code}
yum -y erase reductor
yum -y install http://download5.carbonsoft.ru/reductor/reductor.rpm
{code}
h2. Восстановите настройки из одного из бэкапов
h3. Если делали автоматические бэкапы
Если делали автоматический бэкап с помощью service reductor export и забирали на удалённый сервер
Залейте бэкап на сервер Carbon Reductor, например в файл
/root/reductor_backup_2015.08.28.tar.gz
и выполните
{code}
service reductor import /root/reductor_backup_2015.08.28.tar.gz
{code}
h3. Если бэкапы настроек и своих списков не были настроены
Просмотрите какой из бэкапов редуктора имеющийся на сервере имеет не пустой конфиг (число рядом с именем файла - число строк в нём):
{code}
wc -l /usr/local/old_Reductor*/userinfo/config
{code}
Подставьте версию этого редуктора в команду:
{code}
/bin/cp -vap /usr/local/old_Reductor.ВЕРСИЯ_РЕДУКТОРА/userinfo/* /usr/local/Reductor/userinfo/
/bin/cp -vap /usr/local/old_Reductor.ВЕРСИЯ_РЕДУКТОРА/lists/our.* /usr/local/Reductor/lists/
{code}
h2. Проверьте, что сервер не уходит в панику при следующих действиях
Для исключения побочных эффектов на время этого шага лучше выключить зеркало трафика
{code}
cd /usr/local/Reductor/reductor_container/lib/modules/
ls # скопируйте имя этой папки в буфер
ln -s имя_этой_папки $(uname -r)
chroot /usr/local/Reductor/reductor_container/
depmod -a
modprobe xt_reductor
modprobe ipt_FORBIDDEN
exit
rmmod xt_reductor
rmmod ipt_FORBIDDEN
{code}
h2. Попробуйте запустить Carbon Reductor
{code}
service reductor restart
{code}
затем запустите выгрузки
{code}
service reductor update
{code}
после них диагностику
{code}
service reductor check
{code}
если там нет ругани на что-то кроме tcpdump / проверенные пакеты, то включайте зеркало обратно, подождите 2 минуты и снова диагностику.
h2. Верните Carbon Reductor в автозагрузку
{code}
chkconfig --level 345 reductor on
{code}