Помогите начинающему админу: время от времени диск уходит в ro. нужно узнать причину

странных строчек о апдейте мускла

вот и они

Mar 19 12:10:20 ubuntu /etc/mysql/debian-start[1030]: Upgrading MySQL tables if necessary.
Mar 19 12:10:20 ubuntu /etc/mysql/debian-start[1033]: /usr/bin/mysql_upgrade: the '--basedir' option is always ignored
Mar 19 12:10:20 ubuntu /etc/mysql/debian-start[1033]: Looking for 'mysql' as: /usr/bin/mysql
Mar 19 12:10:20 ubuntu /etc/mysql/debian-start[1033]: Looking for 'mysqlcheck' as: /usr/bin/mysqlcheck
Mar 19 12:10:20 ubuntu /etc/mysql/debian-start[1033]: This installation of MySQL is already upgraded to 5.5.34, use --force if you still need to run mysql_upgrade
Mar 19 12:10:20 ubuntu /etc/mysql/debian-start[1044]: Checking for insecure root accounts.
Mar 19 12:10:20 ubuntu /etc/mysql/debian-start[1049]: Triggering myisam-recover for all MyISAM tables

Вроде как диск шалит, но почему такой большой интервал?

Ну и вопросы у вас. В логах всё видно - включайте, смотрите.

man e2fsck

а крон капсом это норм?

root       815     1 TS   19 Mar19 ?        00:00:00   cron
root      7243   815 TS   19 06:25 ?        00:00:00     CRON
root      7509  7243 TS   19 06:32 ?        00:00:00       /usr/sbin/sendmail -i -FCronDaemon -oem root
root      7510  7509 TS   19 06:32 ?        00:00:00         /usr/sbin/postdrop -r

1. не бывает чтобы сервер внезапно тух/перезагружался? 2. прогони хоть badblock'ом диск его 3. А зачем графика на сервере?

в логах всё видно - включайте, смотрите.

не понял?

1. обновить ядро (в гугле говорят, где-то была ошибка с похожей диагностикой) 2. починить фс.

1. не бывает чтобы сервер внезапно тух/перезагружался?

все что есть

root@ubuntu:/var/log# downtimes 
crash 2014-01-05 02:35:13 -> up 2014-01-05 02:35:41 =    00:00:28 (28 s)
crash 2014-01-05 02:35:57 -> up 2014-01-05 02:37:18 =    00:01:21 (81 s)
crash 2014-01-13 06:02:28 -> up 2014-01-13 10:23:21 =    04:20:53 (15653 s)
down  2014-01-14 17:27:30 -> up 2014-01-15 09:46:56 =    16:19:26 (58766 s)
down  2014-01-15 16:34:50 -> up 2014-01-16 10:13:11 =    17:38:21 (63501 s)
down  2014-01-16 19:43:23 -> up 2014-01-17 10:01:21 =    14:17:58 (51478 s)
crash 2014-01-30 11:15:23 -> up 2014-01-30 11:54:55 =    00:39:32 (2372 s)
down  2014-01-31 14:03:46 -> up 2014-01-31 14:05:29 =    00:01:43 (103 s)
crash 2014-02-02 02:55:21 -> up 2014-02-02 02:55:49 =    00:00:28 (28 s)
crash 2014-02-19 00:17:31 -> up 2014-02-19 11:11:39 =    10:54:08 (39248 s)
crash 2014-03-14 04:10:16 -> up 2014-03-14 13:31:30 =    09:21:14 (33674 s)
crash 2014-03-19 12:07:47 -> up 2014-03-19 12:10:01 =    00:02:14 (134 s)
root@ubuntu:/var/log# 

спросить пока не у кого ибо клиент ушел по делах

2. прогони хоть badblock'ом диск его

читаю что с ним можна сделать сейчас

3. А зачем графика на сервере?

низачем. это старый комп а не сертифицированный сервер. а видяха вот для таких случаев как сейчас.

не нравятся мне записu crash.

2. прогони хоть badblock'ом диск его

читаю что с ним можна сделать сейчас

нужна дежурная флеха. от я лох. в resque`щики не гожусб :)

да есть такое. придет клиент, будем говорить

Мое мнение что беды там. И УПСа нет, а так же могут быть дутые кондеры и плохие розетки. Вот он и тухнет/перезапускается давая пощечины винту, которые накладываются в памяти винта неизгладимыми царапинами а в ФС некрасивым журналом

очень похоже на то. есть хорошее (и доступное) решение как от них защититься?

Опыт получил. В след раз уже сделаешь важный вид перед клиентом), все учатся пробуя. Такчто все ок.

Сделай себе resue-флешку или хотяб запиши какойнить реаниматор на болванку

https://bugzilla.kernel.org/show_bug.cgi?id=42723

Нормальный винт + УПС хотябы

[66099.127079] EXT4-fs error (device sda1): ext4_mb_generate_buddy:739: group 129, 21360 clusters in bitmap, 21359 in gd
[66099.127129] Aborting journal on device sda1-8.
[66099.127326] EXT4-fs (sda1): Remounting filesystem read-only

это оно?

При обращении к сбойному сектору так бывает.

в ОП добавлен выхлоп smartctl. если здесь есть умеющие гадать по нему — welcome

оказалось что там иногда ночью вырубается свет.

Убери errors=remount-ro и он не будет уходить в ro.

Проведи проверку диска на ошибки.

Судя по симптомам - сервер периодически перегружается по питанию, либо свет моргает, либо с БП проблемы, или ещё с каким-нибудь железом.

ФС из-за проблем с диском перемонтируется read-only, после чего mysql обламывается с записью на read-only диск и начинает пытаться починиться, но у него, понятно, не получается.

Судя по выводу smartcrl, винт близок к уходу в страну вечной охоты. Покажи ещё smartctl -H /dev/sda

Винт - менять, БП - тестировать, ИБП - покупать.

БП - тестировать,

мы его поменяли на новый в начале

винт близок к уходу в страну вечной охоты

по какому параметру выхлопа вы это узнали

Покажи ещё smartctl -H /dev/sda

root@ubuntu:~# smartctl -H /dev/sda
smartctl 5.41 2011-06-09 r3365 [i686-linux-3.2.0-60-generic-pae] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

root@ubuntu:~# 

Deathstalker, погадай пожалуйста по выхлопу смарта

по какому параметру выхлопа вы это узнали

Извиняюсь, был не прав. Оказалось, что вывод smartctl нужно читать по-хитрому

hddtemp /dev/sda

Могу ошибаться, но у Вас вижу проблемы с питанием диска, и, возможно, с дата-кабелем.

Во первых - количество запротоколированных запусков намного больше, чем отключений, а так-же количество стартов шпинделя меньше, чем количество запусков диска (внезапное пропадание питания?):

Start_Stop_Count 3735
Power_Cycle_Count 2328
Spin_Up_Time 3264

Во вторых - диск проработал 8018 часов и при этом 3735 раз подавалось питание. Почти кажды два часа выключали/включали его?

В третьих - есть недавние ошибки (около суток назад), связанные с передачей данных:

c8 00 20 00 be 09 e0 00 1d+02:50:54.125 READ DMA
c8 00 08 58 11 41 e4 00 1d+02:38:05.250 READ DMA
c8 00 08 18 09 c5 e1 00 1d+02:35:40.313 READ DMA