    Этот файл содержит описание диагностических сообщений паспорта,
    различных ошибочных ситуаций и возможных путей их разрешения.
    Версия: $Id: TROUBLESHOOT,v 2.9 2004-06-16 05:28:54 tvt Exp $

    1. Диагностические сообщения, попадающие в лог ошибок виртуального хоста 
    апача.
    1.1 Ошибки присылаемые скриптом дайджеста.
    Скрипт дайджеста сконструирован таким образом, что включает в дайджест
    только те строки, в которых встречается подстрока [error], причём те
    строки, в которых встречаются сообщения, что некий файл не найден,
    опускаются.
        1.1.1 Ошибки, помеченные подстрокой [complain issued], выдаются в
        лог паспорта в том случае, когда паспорт по каким-либо причинам не
        может продолжить штатную работу и, как результат, показывает
        пользователю сообщение об ошибке обработки запроса. В коде паспорта
        в переменную $cmpncause заносится текст, описывающий причину отказа.
        Содержимое этой переменной печатается в сообщении об ошибке после
        подстроки [complain issued]. Часть ошибок, выводимых таким образом,
        может быть устранена административным образом. В данном тексте
        описаны только такие ошибки. Остальные ошибки сигналищируют об
        ошибках в коде и должны устраняться программистом.
        Далее идут сообщения об ошибках, описание и методы борьбы с ними:
        
        Fatal body reading error! - означает, что в запросе,
            отправленном методом POST данных оказалось меньше, нежели
            указано в заголовке Content-Length. Как показывает практика,
            такую ошибку вызывают браузеры Internet Explorer пожилых версий.
            Эта ошибка вызвана не нами и исправить её не в наших силах.
        Can't create connection to safeguarddb! : ... - означает, что
            паспорт не может открыть соединение к базе данных safeguarddb. 
            После двоеточия идёт сообщение об ошибке DBI, по которому можно 
            определить конкретную причину отказа.
        Can't create connection to trackdb! : ... - означает, что
            паспорт не может открыть соединение к базе данных trackdb. 
            После двоеточия идёт сообщение об ошибке DBI, по которому можно 
            определить конкретную причину отказа.
        in auth: cant't retrieve authmode choice for uid ... - означает, что
            для пользователя с данным уидом нет записи с sid=8 и она, скорее
            всего, не могла быть создана из-за пересечения имён. Решение:
            вставить запись, использовав вместо имени уид пользователя.
            Например следующая команда приводит к желаемому результату:
                insert into subscription
                (suid, sid, uid, login, passwd, host_id, login_rule, born_date) 
                values (null,8,значение уид,'login','passwd',12, 1, 'born_date');
                Если не указать  born_date, то будут нули.
        in tune: cant't retrieve old choice uid ... 
        in passport: cant't retrieve choice uid ... - тоже самое, что и в
            предыдущем случае.
        cant't retrieve account info uid ...
        cant't retrieve user info uid ... - эти ошибки происходят, когда
            пользователь зарегистрировался на чужой адрес электронной почты,
            а владелец использованного адреса удалил аккаунт (в рассылаемом
            паспортом письме заложена такая возможность). В этом случае
            информация об авторизации сохраняется (запись из таблицы
            sessions не удаляется), а самого аккаунта уже нет. На данное
            сообщение не следует обращать особого внимания. Пользователь не
            сможет больше авторизоваться и в дальнейшем для данного уида
            сообщение не появится.
        in subscribe: cant't subscribe uid ... sid ... name ... - эта ошибки
            обычно возникает, если не работает механизм вызова процедур
            подписки на народ или закладки. Этот механизм вызывает по HTTP
            скрипт на народе или закладках. Ошибка означает, что 1) вызов не
            смог добраться до скрипта (Proxy Error на народе или таймаут)
            или 2) вызванный скрипт вернул статус ошибки. Решение: смотреть
            на проекте соответсвующем указанному сиду.
        in subscribe: can't determine virtual id for uid ... - то же, что и
            выше, но возникает исключительно при попытке подписки к народу
        in remember: cant't send remember mail uid ... - означает, что по
            каким-либо причинам pipe, открытый к sendamil вернул ошибку.
            Смотреть на хосте, что пишет sendmail в логи.

        1.1.2 Ошибки, не помеченные подстрокой [complain issued], 
        генерируются апачем. Из этого класса стоит выделить следующие
        ошибки, которые могут вызывать вопросы:

        Invalid method in request G и другие буквы - по всей видимости, это
            - ошибки клиента, неправильно формирующего запрос HTTP. Можно
              игнорировать.
        Client sent malformed Host header - дословно. Игнорировать.

    1.2 Часть ошибок, появляющихся в логе, не попадает в дайджест. Ошибки,
    сопровождаемые сообщением от DBI обычно понятны. Вопросы, как показала
    практика, могут вызывать ошибки :
    Undefined subroutine &DBD::mysql::db::_login called ... - ошибка
        возникает, если недоступны клиентские библиотеки mysql (они не 
        указаны в ld.so.conf) или mysql dbd был собран с неправильной 
        версией библиотек.
        Такое часто случается после сборки новой версии mysql, так как
        после этого нужно сказать chmod -R g-r /usr/local/mysql.23.
        Необходимо убедиться, что доступна правильная библиотека:
            ldconfig -r | grep mysql
        Если библиотека недоступна, убедитесь, что на дирректории, в которой
        находится библиотека, установлены требуемые права доступа и добавьте
        библиотеку командой
            ldconfig -m /путь/к/библиотеке
    DB connection failed:Lost connection to MySQL server during query - 
        ошибка возникает, если DBI не смог подтеврдить соединение (в
        терминах persistent connection в Apache:DBI метод ping вернул ложь).
        Это означает, что база либо перегружена, либо не работает.
        Проверьте, работает ли база данных. Проверьте, какова её загрузка.
        Оценить загрузку базы можно командой:
            /.../mysqladmin -uroot -p processlist
        Также может быть полезным просмотреть последние записи в
        имябазы-slow.log, если ведётся лог медленных запросов.
    execute failed: Duplicate entry ... - если эта ошибка, возникает для
        неуникальных ключей, это означает, что таблица испорчена. Необходимо
        обеспечить отсутствие доступа к этой таблицы, вплоть до останова
        сервера базы данных. Проверить и, при необходимости, исправить
        таблицу:
            cd /путь/где/лежат/файлы/таблиц
            /.../myisamchk -c имятаблицы
        и если предыдущая комманда выдала сообщение об ошибках
            /.../myisamchk -o имятаблицы
    
    2. Восстановление таблиц истории пользовательских операций:
    В случае, если по каким либо причинам нужно восстановить таблицы базы
    historydb, нужно:
        2.1 Определить с какой даты нужно восстанавливать таблицы.
	    Обычно это делается так: смотрим когда был ребут - этот день плохой, а
            предыдущий хороший. Для примера, ребут был 9 июня, значит  за 8 июня у нас
            хорошие данные, а за 9 плохие. 
            Далее, идем на horovod и коннектимся к mysql.
            /usr/local/mysql.back/bin/mysql -uroot --password=xxxxxx historydb
            После этого говорим:
            repair table  authtrack200206;
            Ждем окночания.
            repair table changes200206;
            Ждем окночания.
            repair table operations200206;
            Ждем окночания.

        2.2 На время выполнения этих операций выполнение парcеров на текущие
            логи должно быть остановлено. 
            Для этого, на всякий случай, закомментируем в /etc/crontab следующие строки:
            5       0       *       *       *       root    /usr/local/www/newpassp/scripts/ParseAdmin change stop auth stop
	    30      0       *       *       *       root    /usr/local/www/newpassp/scripts/ParseAdmin change start auth start
            После чего говорим :
            /usr/local/www/newpassp/scripts/ParseAdmin change status auth status, можно наблюдать 3 
            варианта:
            1 вариант (pid, естественно, может быть другим):
            Running PID 42155
	    Running PID 42155
	    Running PID 42155
	    Running PID 42155
            Это значит, что парсер работает, надо сказать: 
            /usr/local/www/newpassp/scripts/ParseAdmin change term auth term
            2 вариант:
            Record 2002-06-10:PID:16764 appeared to be stale -
            no corresponding process running
            Record 2002-06-10:PID:16764 appeared to be stale -
            no corresponding process running
            Record 2002-06-10:PID:16764 appeared to be stale -
            no corresponding process running
            Это значит, что парсеры не работают, но и в этом случе им можно на всякий случай сказать: 
            /usr/local/www/newpassp/scripts/ParseAdmin change term auth term
            хуже от этого точно не будет.
            3 вариант может быть смесь предыдущих варантов, тогда тоже надо будет сказать:
            /usr/local/www/newpassp/scripts/ParseAdmin change term auth term
            Однако, предварительно надо проверить, что никто не начал уже лечиить базу.

        2.3 Если замучили крики от мониторинга, то надо на webadmine выключить в кроне скрипт:
            5,35   *       *       *       *       tvt     /usr/local/monitor/scripts/whatsup_mysql_horovod.pl

        2.4 Начиная с июня 2004 года парсеры логов умеют определять, на какой
        строке лог файла процесс парсинга оборвался. Надо запустить парсер на
        ту дату, которая считается плохой.
        Формат вызова парсера:
            XXXLogParse YYYYMMDD source, где
            YYYYMMDD - дата в формате 4-ёх цифр для года, двух для месяца и
                        двух для дня месяца
            source - файл, который нужно разбирать, или -, если лог надо читать 
                    из стандартного входа (например, если лог подаётся из 
                    сжатого файла через пайп)
        Парсер найдёт последнюю запись для данного хоста за указанную дату 
        и пропустит необходимое количество записей, начав закладывать в таблицу
        записи, которых там ещё нет.
        Для определения номера хоста, с которого происходила запись данных
        в базу, используется параметр в файле PASSROOT/scripts/Pathes.pm под
        названием LogHostID. Значение параметра - число в шестнадцатеричной
        записи (всегда две позиции) от 01 до 7F. таким образом можно
        перенумеровать 127 машин.
        При установке паспорта на очередную машину необходимо прописать и этот
        параметр тоже.

        2.4.1 Одновременный парсинг.
        В предыдущей версии парсеров параллельная работа двух и более парсеров,
        пишущих данные в одну таблицу, была невозможна. В новом формате
        принципиальных запретов на работу нескольких скриптов нет. Однако при
        работе парсер логов авторизации выедает довольно много ресурсов. По
        Этой причине блокировка на параллельный запуск нескольких парсеров
        сохранена.
        
        2.4.2 Ключевое поле в таблицах логов.
        Эта информация может понадобиться в случае нештатной работы скрипта.
        Разбиение на блоки данных в таблице основанно на номере хоста, с
        которого производилась запись данных (на котором парсился лог файл) и
        даты. На каждую комбинацию хост-дата выделяется блок значений ключевого
        индекса таблицы, в котором хранятся номера строк в исходном файле, из
        которого получались данные в данной строке таблицы.
        Формат ключа таблиц выглядит следующим образом:
        HNYYYMDDLLLLLLLL, 8-ми байтное целое без знака, записанное в
        шестнадцатиричном виде, где:
        HN - две шестнадцатиричных цифры для нумерации хоста (см пункт 2.4)
        YYY - три шестнадцатеричных цифры для записи года
        M - одна шестнадцатиричная цифра для записи месяца
        DD - две шестнадцатиричных цифры для записи дня месяца
        LLLLLLLL - восемь шестнадцатиричных цифр для записи номера строки
        При поиске номера строки последней записи парсер ищет максимальное
        значение ключа для данного хоста за указанную дату. Из ключа 
        вырезается номер строки. Файл проматывается до строки с номером на 1
        большим полученного на предыдущем шаге. Парсинг возобновляется.

        2.5 Восстановление репликации базы historydb.
            Делать в случае поломки реплики, статус определяется командой show slave 
            на сервере qu.yqndex.ru. 
            2.5.1 Останавливаем mysql на horovod и qu.
                  horovod:
                  /usr/local/mysql.back/bin/mysqladmin -uroot --password=xxxxx shutdown 
                  qu:
                  mysqladmin -uroot --password=xxxxx --socket=/tmp/mysql.3309.sock shutdown
            2.5.2  На qu:
                   rm /opt/mysql.3309/base/master.info
                   cd /opt
                   chown -R свой_логин mysql.3309
                   Последнее нужно для rcp, следовательно, предварительно в своем 
                   .rhosts нужно вписать:
                   horovod.yandex.ru root 
           2.5.3 На horovod:
                   cd /opt/mysql.back/
                   rm horovod-bin.*
                   cd /opt/mysql.back/historydb
                   rcp *200406.* свой_логин@qu.yandex.ru:/opt/mysql.3309/base/historydb/   
                   Ждем окончания этой команды и запускаем mysql:
                   /usr/local/etc/rc.d/mysql.back.sh
           2.5.4 На qu:
                   cd /opt
                   chown -R root mysql.3309
                   Запускаем mysql:
                   /usr/local/etc/rc.d/mysql3.sh 
            На этом синхронизацию заканчиваем.
  
	2.6 Восстановление логов авторизации старым способом.
            Скорее всего он уже не нужен, но пока новая система не 
            прошла стресс-тестов, то я оставила тут его описание.
            Последовательно, для каждого файла, начиная с даты
            восстановления выполняем команду:
            cd /usr/local/www/newpassp/log/arc
            zcat auth.log.20020609.gz | ../../scripts/AuthLogParse - &
            /usr/local/www/newpassp/scripts/ParseAdmin auth stop
            ждём, пока команда не завершится (выполняется долго).
            zcat change.log.20020609.gz | ../../scripts/ChangeLogParse - &
            /usr/local/www/newpassp/scripts/ParseAdmin change stop
            ждём, пока команда не завершится (выполняется быстро).
            Далее делаем то же самое, для следующей даты, например:
            zcat auth.log.20020610.gz | ../../scripts/AuthLogParse - &
            /usr/local/www/newpassp/scripts/ParseAdmin auth stop
            zcat change.log.20020610.gz | ../../scripts/ChangeLogParse - &
            /usr/local/www/newpassp/scripts/ParseAdmin change stop
            Если дата = текущему дню, то достаточно просто сказать:
            /usr/local/www/newpassp/scripts/ParseAdmin auth start change start
            Парсер начнет есть текущие логи и на этом восстановление можно считать законченным.
     
        2.7 Расскомментировать все, что было закомментировано в кронтабах - на horovod
            и на webadmin.

        2.8 Не забыть проверить наличие файла dosya:/vol0/alg/del_users/stop, который туда кладется 
            моим скриптом /usr/local/www/newpassp/scripts/test_parser.sh.  После восстановления 
            базы нужно его удалить, это позволит в автоматическом режиме удалять пользователей
            с почты. Если он есть, то пользователи не удаляются.
	    Как и когда это лучше делать:
            Нужно подождать какое-то время после запуска парсеров - они обычно парсят логи за
            текущий день.
            После чего сказать:
            cat auth.log | head -n 3
            Найти первую запись и , с которой начался день.
            Зайти в базу historydb и посчитать количество записей за текущий день:
            select count(*) from authtrack200206 where authtime >='дата первой записи в логе';
            Посчитать количество записей в логе:
            cat auth.log | wc -l
            Когда эти цифры будут одного порядка, можно стирать файл stop и считать восстановление базы
            законченным.
            


