Job for mariadb.service failed because a configured resource limit was exceeded

M
На сайте с 20.08.2004
Offline
351
471

Подскажите в чем проблема?

systemctl start mariadb

Job for mariadb.service failed because a configured resource limit was exceeded. See "systemctl status mariadb.service" and "journalctl -xe" for details.
[root@08 ~]# ^C
[root@08 ~]# systemctl status mariadb.service
● mariadb.service - MariaDB database server
Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
Active: failed (Result: resources)

Jun 02 00:01:10 systemd[1]: mariadb.service failed to run 'start-pre' task: No space left on device
Jun 02 00:01:10 systemd[1]: Failed to start MariaDB database server.
Jun 02 00:01:10 systemd[1]: Unit mariadb.service entered failed state.
Jun 02 00:01:10 systemd[1]: mariadb.service failed.
Jun 02 08:46:17 systemd[1]: mariadb.service failed to run 'start-pre' task: No space left on device
Jun 02 08:46:17 systemd[1]: Failed to start MariaDB database server.
Jun 02 08:46:17 systemd[1]: mariadb.service failed.

[root@08 ~]# df -h

Filesystem Size Used Avail Use% Mounted on
devtmpfs 16G 0 16G 0% /dev
tmpfs 16G 0 16G 0% /dev/shm
tmpfs 16G 49M 16G 1% /run
tmpfs 16G 0 16G 0% /sys/fs/cgroup
/dev/mapper/vg-root 9.8G 9.8G 0 100% /
/dev/md0 496M 364M 107M 78% /boot
/dev/mapper/vg-mysql 50G 9.1G 41G 19% /var/lib/mysql
/dev/mapper/vg-log 50G 751M 50G 2% /var/log
/dev/mapper/vg-www 200G 92G 109G 46% /www
tmpfs 3.2G 0 3.2G 0% /run/user/0
отец сыночка, лапочки дочки и еще одного сыночка
rootenko
На сайте с 21.03.2020
Offline
5
#1

Покажите /var/log/mariadb/mariadb.log

M
На сайте с 20.08.2004
Offline
351
#2

что именно там показать . он очень длинный

lealhost
На сайте с 07.06.2014
Offline
108
#3
/dev/mapper/vg-root 9.8G 9.8G 0 100% /

Ну корень забит под завязку.

Конкретно задание start-pre не может из-за этого выполниться.

mariadb.service failed to run 'start-pre' task: No space left on device

start-pre - одна из команд в файле сервиса systemctl, начинаются с

ExecStartPre=

И, конечно, команды, которые там, могут использовать спейс на корне.

Чистите корень.

Дешевый хостинг на SSD дисках, SSL-сертификаты (https://lealhost.com) | Домены RU/РФ - 160 рублей (https://lealhost.com/domains/)
M
На сайте с 20.08.2004
Offline
351
#4
lealhost:
Чистите корень.

спасибо за ответ

подскажите как это сделать?

---------- Добавлено 02.06.2020 в 10:41 ----------

[root@08 mapper]# cd /dev/mapper/
[root@08 mapper]# ls -la
total 0
drwxr-xr-x 2 root root 160 Jun 2 00:00 .
drwxr-xr-x 20 root root 3360 Jun 2 00:01 ..
crw------- 1 root root 10, 236 Jun 2 00:00 control
lrwxrwxrwx 1 root root 7 Jun 2 09:02 vg-log -> ../dm-2
lrwxrwxrwx 1 root root 7 Jun 2 09:02 vg-mysql -> ../dm-3
lrwxrwxrwx 1 root root 7 Jun 2 09:02 vg-root -> ../dm-0
lrwxrwxrwx 1 root root 7 Jun 2 09:02 vg-swap -> ../dm-1
lrwxrwxrwx 1 root root 7 Jun 2 09:02 vg-www -> ../dm-4

перейти никуда не могу что бы найти что нужно почтистить.

---------- Добавлено 02.06.2020 в 10:51 ----------

для тех кто сталкнется с похожей проблемой и знаний будет как у меня не много

1.df -h

2. find / -type f -size +500M

3. в моем случае были логи такого типа /var/crash/127.0.0.1-2020-06-02-00:00:03/

4. удалить лишнее

5. перезапустил

systemctl start mariadb

systemctl start nginx

systemctl start php-fpm

lealhost
На сайте с 07.06.2014
Offline
108
#5

Какая операционная система?

Что показывает следующая команда?

du -xha -d1 /
M
На сайте с 20.08.2004
Offline
351
#6

вот что показывает

du -xha -d1 /
4.0K /media
77M /opt
0 /.autorelabel
0 /lib
44K /home
4.0K /installimage.conf
47M /etc
376K /root
4.0K /mnt
0 /lib64
2.2G /var
4.0K /srv
0 /bin
64K /tmp
84K /.readahead
16K /lost+found
1.7M /installimage.debug
0 /sbin
1.9G /usr
4.1G /
Andreyka
На сайте с 19.02.2005
Offline
819
#7

У вас LVM

На vg-www куча места

Откусите оттуда гигов десять и перекиньте на vg-root

Делать это надо в rescuie mode, загрузившись с образа/cd/usb

Команды примерно такие:

umount /dev/mapper/vg-root

umount /dev/mapper/vg-www

lvreduce -L 10G /dev/mapper/vg-www

lvextend -t -r -l+100%FREE /dev/mapper/vg-root

После этого ребут в обычный режим

Не стоит плодить сущности без необходимости
lealhost
На сайте с 07.06.2014
Offline
108
#8
Miracle:

для тех кто сталкнется с похожей проблемой и знаний будет как у меня не много

1.df -h
2. find / -type f -size +500M
3. в моем случае были логи такого типа /var/crash/127.0.0.1-2020-06-02-00:00:03/
4. удалить лишнее
5. перезапустил
systemctl start mariadb
systemctl start nginx
systemctl start php-fpm

Хорошо, что разобрались, но лучше выявить причину по которой сыпятся подобные "журналы", точнее, вероятно всего это были coredump-файлы для отладки приложений после сегфолтов, они всегда крупные. :) Если не разобраться, будет рецидив.

Скорее всего какое-то приложение крашится и оставляет дамп. В журналах (обычно /var/log/messages or /var/log/syslog ) можно разглядеть аномалии.

M
На сайте с 20.08.2004
Offline
351
#9
Andreyka:
Откусите оттуда гигов десять и перекиньте на vg-root

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

---------- Добавлено 02.06.2020 в 11:39 ----------

lealhost:
Хорошо, что разобрались, но лучше выявить причину по которой сыпятся подобные "журналы", точнее, вероятно всего это были coredump-файлы для отладки приложений после сегфолтов, они всегда крупные. Если не разобраться, будет рецидив.

буду рад если подскажете с чего начать?

lealhost:
Скорее всего какое-то приложение крашится и оставляет дамп. В журналах (обычно /var/log/messages or /var/log/syslog ) можно разглядеть аномалии.

оки. а на что обращать внимание?

---------- Добавлено 02.06.2020 в 11:42 ----------


[root@08 127.0.0.1-2020-04-22-05:58:04]# ls -la /var/crash/127.0.0.1-2020-06-02-00:00:03/
total 1772552
drwxr-xr-x 2 root root 4096 Jun 2 00:00 .
drwxr-xr-x 3 root root 4096 Jun 2 09:49 ..
-rw-r--r-- 1 root root 116822 Jun 2 00:00 vmcore-dmesg.txt
-rw------- 1 root root 1825959936 Jun 2 00:00 vmcore-incomplete

что за креш почти2 гб? есть полезная информация в нем?

lealhost
На сайте с 07.06.2014
Offline
108
#10
Miracle:

буду рад если подскажете с чего начать?

оки. а на что обращать внимание?

что за креш почти2 гб? есть полезная информация в нем?

Обращать внимание нужно на время.

У вас файл дампа создался сегодня в 00:00:03, соответственно можно глянуть /var/log/messages, +-10 секунд от этого времени и в это время.

Сервер случайно не перезагружался ночью? Покажет команда "uptime" или "last".

Как получить информацию из дампа описано здесь:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/s1-kdump-crash

Дебажить дампы это довольно специфичное занятие, лучше посмотрите системный журнал.

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий