Июн 282013
 

Сегодня ночью внезапно упали apache и mysql на сервере. Конечно, не совсем внезапно, но я не ожидал. Падение произошло из-за переполнения диска, на котором лежат файлы, необходимые для работы этих сервисов. После падения нормально поднялся только Apache.

А вот Mysql стартовать отказывался.
Много гуглил, но ни чего не нашел.
Симптомы были такие: в лог файл ничего не пишет, при попытке запуска через /etc/init.d/mysqld start зависает.

Запустил в режиме отладки /etc/init.d/mysqld start -d и посмотрел, что происходит.
Затык оказался вот тут:

+ ewaitfile 900 /var/run/mysqld/mysqld.sock

Проверка на наличие сокета в течение 900 секунд. Выходит и не подвисал он при запуске, а просто ждал появления файла.
Уменьшил в инициализационном скрипте время до 10 секунд. И увидел, что, не дождавшись появления файла, сервис отказывается стартовать.

Запустил от имени рута. Все ОК.
Внимание. Тут надо быть аккуратным — при запуске от рута создаются файлы в директории /var/lib/mysql вида mysqld-bin.000008
К новому файлу будут права выставлены от имени рута. И если mysql был запущен от рута, то потом надо выставить корректные права на файлы, иначе он не стартанет.

Если от имени root стартует, значит проблема в правах. Сначала я думал, что проблема в доступе к директории /var/run/mysqld,
Потому как он тормозится на проверке наличия сокета mysqld.sock в указной директории. Хотя права доступа были выставлены верно. (более того в инициализационном скрипте прописана правка прав если они не верны)
Даже после создания сокета вручную, сервис стартовал, но сразу крэшился.

/etc/init.d/mysql status
 * status: crashed

Тут появился прогресс — начали писаться логи.

130628 13:03:53 [ERROR] /usr/sbin/mysqld: Can't find file: './mysql/host.frm' (errno: 13)
130628 13:03:53 [ERROR] Fatal error: Can't open and lock privilege tables: Can't find file: './mysql/host.frm' (errno: 13)

Отсюда уже стало понятнее.
Оказалось, что файлы системной БД имели права для рута. Видимо раньше прокатывало и какое-то очередное обновление изменило это, но до ребута сервиса все работало.
файлы лежат тут: /var/lib/mysql/mysql
Как только я задал правильные права для всех файлов в директории сервис прекрасно запустился.

find /var/lib/mysql/mysql -type f |xargs chown mysql:mysql
Май 192013
 

Собирался уже пойти спать примерно 3,5-часа назад, но вдруг что-то случилось с электричеством. Сначала заморгала лампа, потом ребутнулось все, что могло ребутнутся, в том числе и сервак.
Но вот после перезагрузки из ребута он не вышел и выкинул такую ошибку:

 * Udev uses a devtmpfs mounted on /dev to manage devices.
 * This means that CONFIG_DEVTMPFS=y is required
 * in the kernel configuration.


 * ERROR: cannot start udev as udev-mount would not start
 * Mounting /dev/shm ...

Тут и началась веселуха.
Скачал с mirror.yandex.ru новый образ install-amd64-minimal-20130516. Залил его на флешку. Перепробовал все что мог, но запуститься так и не удалось.
Решил, что проблема может быть в образе и не ошибся — скачанная версия, которая вышла неделей раньше, загрузилась без проблем.
Пересобрал ядро с параметрами CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y. Не взлетело. Закрешилось на монтировании файловой системы. Значит не подтянулся файл конфигурации от предыдущего ядра.
Подсунул старый конфиг ядра и добавил в него два новых параметра.
После этого ребут прошел удачно, все сервисы поднялись и благополучно работают.
Но вот спать теперь совсем мало осталось.