Жесткий диск на сервере перешел в read only?

Question

[Vii]

Здравствуйте

Сразу предупрежу, что я не очень продвинутый user в плане linux.

Произошла следующая ситуация:
встала БД на сервере

service mysqld status
Redirecting to /bin/systemctl status mysqld.service
● mariadb.service - MariaDB database server
   Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/mariadb.service.d
           └─custom.conf, nofile.conf
   Active: failed (Result: exit-code) since Wed 2018-11-21 07:39:04 MSK; 2min 46s ago
  Process: 4004 ExecStop=/etc/init.d/mysql stop (code=exited, status=0/SUCCESS)
  Process: 1370 ExecStart=/etc/init.d/mysql start (code=exited, status=0/SUCCESS)
 Main PID: 1384 (code=exited, status=1/FAILURE)

Nov 21 04:26:32 ****.ru systemd[1]: Starting MariaDB database server...
Nov 21 04:26:33 ****.ru mysql[1370]: Starting MySQL.181121 04:26:33 mysqld_safe Logging to '/var/lib/mysql/******.err'.
Nov 21 04:26:33 ****.ru mysql[1370]: 181121 04:26:33 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
Nov 21 04:26:36 ****.ru systemd[1]: Started MariaDB database server.
Nov 21 07:39:04 ****.ru systemd[1]: mariadb.service: main process exited, code=exited, status=1/FAILURE
Nov 21 07:39:04 ****.ru systemd[1]: Unit mariadb.service entered failed state.
Nov 21 07:39:04 ****.ru systemd[1]: mariadb.service failed.

service mysqld restart

Redirecting to /bin/systemctl restart mysqld.service
Job for mariadb.service failed because a configured resource limit was exceeded. See "systemctl status mariadb.service" and "journalctl -xe" for details.

df -h
говорит что свободное место есть

дальше, при попытке создать или удалить файл по ftp, winscp возвращал ошибку.

touch ~/test
touch: cannot touch ‘/root/test’: Read-only file system

mount
/dev/mapper/disk-1 on / type ext4 (ro,relatime,data=ordered)


mount -o remount,rw /dev/mapper/disk-1 /
mount: cannot remount /dev/mapper/disk-1 read-write, is write-protected

как дальше понять в чем дело?
может быть, что эта аппаратная проблема?

подскажите, пожалуйста, алгоритм последующих действий

Comments

[Roman Sokolov]

физический сервер или vps?
smartmontools установлена?
если проблема аппаратная, то в dmesg смотри вывод на наличие i/o errors, если нет, то fsck в помощь.

Answer 1

[sash999]

1.Посмотреть логи. (/var/log/messages или около того в зависимости от дистрибутива)
2.Загрузиться с любого resque cd/usb и запустить fsck на сбойные разделы (тут могут быть тонкости если у вас raid, lvm или еще что-то отличающееся от обычного раздела на диске)

Comments

[Vii]

спасибо.
после ребута файловая система выходила из RO, но потом, минут через 15-20 все повторялось.
помогло e2fsck -f (возм. этому предшествовали еще какие-то команды (делал более опытный специалист)

Answer 2

[CityCat4]

Начать надо с того, что обычно аппаратная ошибка не переводит диски в read-only.

Сначала посмотреть логи. /var/log/messages в частности. Поскольку у Вас Богомерзкий systemd - сначала придется маны почитать, как это делается :) Если в логах есть сообщения о сбоях - готовиться к замене диска - в принципе, поскольку там LVM, особых проблем не будет, хотя потрахатьсямучиться придется.

Если сообщений о сбоях нет - бутиться с любого LiveCD и запускать fsck на диск

Comments

[rPman]

Если проблема с контроллером диска или на материнской плате, то файловая система уходит в readonly, я ощутил это на практике.
Почти наверняка, если причиной будут проблемы с процессором/оперативной памятью, тоже все возможно.

файловая система уходит в ro по любому чиху и неоднозначности, которую удалось обнаружить.

[CityCat4]

rPman, ну, в любом случае без логов тут ничего не сказать...

[ТыжСисАдмин]

сначала придется маны почитать, как это делается

Зачем маны, он и так всё уже написал :)

Job for mariadb.service failed because a configured resource limit was exceeded. See "systemctl status mariadb.service" and "journalctl -xe" for details.

[Vii]

спасибо.
после ребута файловая система выходила из RO, но потом, минут через 15-20 все повторялось.
помогло e2fsck -f (возм. этому предшествовали еще какие-то команды (делал более опытный специалист)