- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Подскажите в чем проблема?
Покажите /var/log/mariadb/mariadb.log
что именно там показать . он очень длинный
Ну корень забит под завязку.
Конкретно задание start-pre не может из-за этого выполниться.
start-pre - одна из команд в файле сервиса systemctl, начинаются с
И, конечно, команды, которые там, могут использовать спейс на корне.
Чистите корень.
Чистите корень.
спасибо за ответ
подскажите как это сделать?
---------- Добавлено 02.06.2020 в 10:41 ----------
[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
Какая операционная система?
Что показывает следующая команда?
вот что показывает
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 /
У вас 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
После этого ребут в обычный режим
для тех кто сталкнется с похожей проблемой и знаний будет как у меня не много
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 ) можно разглядеть аномалии.
Откусите оттуда гигов десять и перекиньте на vg-root
у меня на сервере 2тб.. откусывать не надо. просто надо как-то перенстроить правильно. как показал я выше можно сделать?
---------- Добавлено 02.06.2020 в 11:39 ----------
Хорошо, что разобрались, но лучше выявить причину по которой сыпятся подобные "журналы", точнее, вероятно всего это были coredump-файлы для отладки приложений после сегфолтов, они всегда крупные. Если не разобраться, будет рецидив.
буду рад если подскажете с чего начать?
Скорее всего какое-то приложение крашится и оставляет дамп. В журналах (обычно /var/log/messages or /var/log/syslog ) можно разглядеть аномалии.
оки. а на что обращать внимание?
---------- Добавлено 02.06.2020 в 11:42 ----------
что за креш почти2 гб? есть полезная информация в нем?
буду рад если подскажете с чего начать?
оки. а на что обращать внимание?
что за креш почти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
Дебажить дампы это довольно специфичное занятие, лучше посмотрите системный журнал.