{toc:maxLevel=3}
h1. Почему так получилось и как починить
Ошибка возникает если на одном из разделов занято более 85% пространства.
h4. Общая методика поиска причины и решения
# Проверям какой раздел заполнен:
{code:title=Команда}df -h | grep -wE '/|/mnt'{code}
{code:title=Вывод}
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 3,7G 1,9G 1,6G 55% /
/dev/sda2 14G 6,7G 6,3G 52% /app
/dev/sda3 13G 1,4G 11G 12% /mnt/backup
/dev/sda4 1,9G 36M 1,7G 3% /mnt/etc
/dev/sda5 53G 47,2G 5.8G 89% /mnt/var
/dev/sda6 8,2G 4,3G 3,6G 55% /mnt/log
/dev/sdb1 394G 140G 234G 38% /mnt/stat
/dev/sdb1 394G 140G 234G 38% /app/collector/mnt/var/stat
{code}
Видно, что заполнен раздел /dev/sda5 с логами.
{panel}
/dev/sda5...................53G...47,2G.....5.8G....{color:red}*89%*{color}..{color:red}*/mnt/var*{color}
{panel}
# Теперь нужно узнать какие именно данные занимают раздел. Запускаем комманду подсчёта объёма и двигаемся вглубь файловой системы:
{code:title=Команда подсчета места на разделе log}du -sch /mnt/log/app/* | sort -h{code}
{code:title=Вывод}
7,4M /mnt/log/app/monitoring
15M /mnt/log/app/auth
70M /mnt/log/app/xge
81M /mnt/log/app/asr_cabinet
91M /mnt/log/app/base
129M /mnt/log/app/asr_fiscal
130M /mnt/log/app/collector
2,0G /mnt/log/app/asr_billing
2,5G total
{code}
Видно что больше всего места занято в папке *asr_billing*, продолжаем углубляться:
# Двигаемся вглубь файловой системы, ищем что конкретно съедает место:
{code:title=Команда подсчета места папки asr_billing на разделе log}du -sch /mnt/log/app/asr_billing | sort -h{code}
И так далее...
# После того как найдены данные, которые занимают диск, их необходимо перенести на другой носитель. Или подключить дополнительный диск для их хранения. Для раздела с логами это можно сделать по статье [CarbonBilling:Добавление диска под логи].
{info}
В данном примере рассмотрено переполнение раздела с логами (журналами работы служб)
{info}
h2. На каких разделах что хранится, что можно удалять, а что лучше оставить
h3. /mnt/var, /mnt/stat
Наиболее частой проблемой является заполнение раздела */mnt/var* (либо */mnt/stat*), а именно каталога */mnt/var/app/collector/var/stat/binstat/*. Решение описано в [следующей статье|CarbonBilling:Добавление диска под статистику].
h3. /mnt/log
При заполнении раздела */mnt/log*, наиболее верным решением будет выполнить команды head и tail на проблемный файл и приложить полученный вывод в новую, либо автоматический созданную по данной проблеме заявку на портале [HelpDesk|http://helpdesk.carbonsoft.ru/login.php] и сообщить о проблеме в техподдержку по телефону.
Если явно больших файлов лога не обнаружено, вероятно у Вас просто слишком маленький раздел под логи. [Добавьте места|CarbonBilling:Добавление диска под логи].
h3. /mnt/backup
Если забит раздел /mnt/backup - просто очистите старые бэкапы, исследовав структуру каталогов программой *du*. В случае если проблема с разделом восникает часто, вероятно Вам следует [добавить места под логи|CarbonBilling:Добавление диска под бэкапы]
h3. /mnt/etc
В случае заполнения раздела */mnt/etc* обратитесь в техподдержку.
h3. /mnt/db
Если Ваша аппаратная платформа соответствует нашим [системным требованиям|Системные требования], вероятност заполнения раздела в обозримом будущем крайне мала, так как под раздел выделяется не менее 100Гб места (при диске 1Тб и более).
Возможно место занято содержимым этих папок:
- */mnt/db/app/asr_billing/db/notstopped*
В папке сохраняются базы, поврежденные в результатате некорректного завершения работы сервера. Вы можете попробовать достать из них потерянные данные или восстановить целиком воспользовавшись услугами специалистов занимающихся восстановлением баз данных или информацией доступной в документации Firebird.
- */mnt/db/app/asr_billing/db/safemode*
В папке сохраняются базы, работа которых была завершена корректно, их можно восстановить в работу. В последствии содержимое папки можно очистить.
h3. / (корневой раздел ОС)
Проверьте что место не занято в результате установки стороннего ПО или выполнения каких-либо скриптов, например при выполнении заданий добавленных в cron, либо в процессе работы на сервере в пользовательской директории (/root, /home).
h3. /var/log (логи в корневом разделе ОС)
Место занимает каталог с логами в корневой файловой системы
Во время работы системы могут расти файлы логов. Периодически они ротируются, но бывают ситуации, когда они растут довольно быстро. Например при попытке несанкционированного доступа растут логи *secure* и *btmp* в каталоге log. Пример:
{code}
# ll -h /var/log/secure
-rw------- 1 root root 156M Апр 17 18:51 /var/log/secure
# ll -h /var/log/btmp
-rw------- 1 root utmp 435M Апр 17 18:51 /var/log/btmp
{code}
Просмотреть кто пытался подключится можно командами:
{code}
# last -f /var/log/btmp | head
root ssh:notty 10.0.0.1 Fri Apr 17 18:57 gone - no logout
root ssh:notty 10.0.0.1 Fri Apr 17 18:56 - 18:57 (00:00)
git ssh:notty 10.0.0.1 Fri Apr 17 18:56 - 18:56 (00:00)
vm ssh:notty 10.0.0.1 Fri Apr 17 18:56 - 18:56 (00:00)
test123 ssh:notty 10.0.0.1 Fri Apr 17 18:56 - 18:56 (00:00)
{code}
{code}
# tail /var/log/secure
Apr 17 18:58:25 localhost sshd[29481]: Failed password for invalid user ln from 193.70.88.213 port 34570 ssh2
Apr 17 18:58:25 localhost sshd[29484]: Received disconnect from 193.70.88.213: 11: Bye Bye
Apr 17 18:58:25 localhost sshd[29488]: Failed password for root from 183.82.121.34 port 47762 ssh2
Apr 17 18:58:25 localhost sshd[29489]: Received disconnect from 183.82.121.34: 11: Bye Bye
Apr 17 18:58:27 localhost sshd[29515]: reverse mapping checking getaddrinfo for 45.63.104.211.vultr.com [45.63.104.211] failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 17 18:58:27 localhost sshd[29515]: Invalid user ftpuser from 45.63.104.211
{code}
Для решения проблемы нужно ограничить доступ до сервера по [статье|Обзор безопасности].
h1. Примеры решения проблем
h2. Переполнен разделы с логами /mnt/log или папка /var/log
h3. Корневой раздел переполнен журналом авторизации
Проблема встречается на Softrouter и XGE при интеграции с Carbon Reductor: фильтр выгружает списки заблокированных IP-адресов по ssh и каждая авторизация фиксируется в логе /var/log/secure, от этого он достаточно быстро разрастается.
Проверьте файлы /var/log/secure:
{code}du -sch /var/log/secure*{code}
Если файлы достаточно объёмны (сотни мегабайт и более), значит это Ваша ситуация.
Её можно решить добавив компрессию при ротации логов, для этого измените файл */etc/logrotate.d/syslog*, добавив туда строки *nodelaycompress* и *compress*:
{code}/var/log/cron
/var/log/maillog
/var/log/messages
/var/log/secure
/var/log/spooler
{
sharedscripts
#==Компрессия логов==#
#==
nodelaycompress
compress
#==
postrotate
/bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
endscript
}{code}
h3. Слишком много файлов на диске с логами
При работе биллинг отправляет команды на оборудование. При этом лог команд ведётся для каждого абонента в отдельности. При большом количестве абонентов это может привести к заполнению раздела /mnt/log . Так же при диагностике сервера может выводиться сообщение:
{code}
Мало свободных inode
{code}
# Просмотрите размер раздела /mnt/log
{code}
df -h | grep log
/dev/sda7 14G 5,8G 7,0G 46% /mnt/log
{code}
# Оцените сколько места занято логами учётных записий
{code}
du -sh /app/asr_billing/var/log/abonents
272M /app/asr_billing/var/log/abonents
{code}
# Удалите логи старше 30 дней
{warning:title=Используйте команду в точности как написано ниже!}
Настоятельно не рекомендуем вносить изменение в команду удаления логов, так как это может привести к неработоспособности системы в целом.
{code}
find /app/asr_billing/var/log/abonents/ -atime +30 -type f -delete
{code}
{warning}
h1. Почему так получилось и как починить
Ошибка возникает если на одном из разделов занято более 85% пространства.
h4. Общая методика поиска причины и решения
# Проверям какой раздел заполнен:
{code:title=Команда}df -h | grep -wE '/|/mnt'{code}
{code:title=Вывод}
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 3,7G 1,9G 1,6G 55% /
/dev/sda2 14G 6,7G 6,3G 52% /app
/dev/sda3 13G 1,4G 11G 12% /mnt/backup
/dev/sda4 1,9G 36M 1,7G 3% /mnt/etc
/dev/sda5 53G 47,2G 5.8G 89% /mnt/var
/dev/sda6 8,2G 4,3G 3,6G 55% /mnt/log
/dev/sdb1 394G 140G 234G 38% /mnt/stat
/dev/sdb1 394G 140G 234G 38% /app/collector/mnt/var/stat
{code}
Видно, что заполнен раздел /dev/sda5 с логами.
{panel}
/dev/sda5...................53G...47,2G.....5.8G....{color:red}*89%*{color}..{color:red}*/mnt/var*{color}
{panel}
# Теперь нужно узнать какие именно данные занимают раздел. Запускаем комманду подсчёта объёма и двигаемся вглубь файловой системы:
{code:title=Команда подсчета места на разделе log}du -sch /mnt/log/app/* | sort -h{code}
{code:title=Вывод}
7,4M /mnt/log/app/monitoring
15M /mnt/log/app/auth
70M /mnt/log/app/xge
81M /mnt/log/app/asr_cabinet
91M /mnt/log/app/base
129M /mnt/log/app/asr_fiscal
130M /mnt/log/app/collector
2,0G /mnt/log/app/asr_billing
2,5G total
{code}
Видно что больше всего места занято в папке *asr_billing*, продолжаем углубляться:
# Двигаемся вглубь файловой системы, ищем что конкретно съедает место:
{code:title=Команда подсчета места папки asr_billing на разделе log}du -sch /mnt/log/app/asr_billing | sort -h{code}
И так далее...
# После того как найдены данные, которые занимают диск, их необходимо перенести на другой носитель. Или подключить дополнительный диск для их хранения. Для раздела с логами это можно сделать по статье [CarbonBilling:Добавление диска под логи].
{info}
В данном примере рассмотрено переполнение раздела с логами (журналами работы служб)
{info}
h2. На каких разделах что хранится, что можно удалять, а что лучше оставить
h3. /mnt/var, /mnt/stat
Наиболее частой проблемой является заполнение раздела */mnt/var* (либо */mnt/stat*), а именно каталога */mnt/var/app/collector/var/stat/binstat/*. Решение описано в [следующей статье|CarbonBilling:Добавление диска под статистику].
h3. /mnt/log
При заполнении раздела */mnt/log*, наиболее верным решением будет выполнить команды head и tail на проблемный файл и приложить полученный вывод в новую, либо автоматический созданную по данной проблеме заявку на портале [HelpDesk|http://helpdesk.carbonsoft.ru/login.php] и сообщить о проблеме в техподдержку по телефону.
Если явно больших файлов лога не обнаружено, вероятно у Вас просто слишком маленький раздел под логи. [Добавьте места|CarbonBilling:Добавление диска под логи].
h3. /mnt/backup
Если забит раздел /mnt/backup - просто очистите старые бэкапы, исследовав структуру каталогов программой *du*. В случае если проблема с разделом восникает часто, вероятно Вам следует [добавить места под логи|CarbonBilling:Добавление диска под бэкапы]
h3. /mnt/etc
В случае заполнения раздела */mnt/etc* обратитесь в техподдержку.
h3. /mnt/db
Если Ваша аппаратная платформа соответствует нашим [системным требованиям|Системные требования], вероятност заполнения раздела в обозримом будущем крайне мала, так как под раздел выделяется не менее 100Гб места (при диске 1Тб и более).
Возможно место занято содержимым этих папок:
- */mnt/db/app/asr_billing/db/notstopped*
В папке сохраняются базы, поврежденные в результатате некорректного завершения работы сервера. Вы можете попробовать достать из них потерянные данные или восстановить целиком воспользовавшись услугами специалистов занимающихся восстановлением баз данных или информацией доступной в документации Firebird.
- */mnt/db/app/asr_billing/db/safemode*
В папке сохраняются базы, работа которых была завершена корректно, их можно восстановить в работу. В последствии содержимое папки можно очистить.
h3. / (корневой раздел ОС)
Проверьте что место не занято в результате установки стороннего ПО или выполнения каких-либо скриптов, например при выполнении заданий добавленных в cron, либо в процессе работы на сервере в пользовательской директории (/root, /home).
h3. /var/log (логи в корневом разделе ОС)
Место занимает каталог с логами в корневой файловой системы
Во время работы системы могут расти файлы логов. Периодически они ротируются, но бывают ситуации, когда они растут довольно быстро. Например при попытке несанкционированного доступа растут логи *secure* и *btmp* в каталоге log. Пример:
{code}
# ll -h /var/log/secure
-rw------- 1 root root 156M Апр 17 18:51 /var/log/secure
# ll -h /var/log/btmp
-rw------- 1 root utmp 435M Апр 17 18:51 /var/log/btmp
{code}
Просмотреть кто пытался подключится можно командами:
{code}
# last -f /var/log/btmp | head
root ssh:notty 10.0.0.1 Fri Apr 17 18:57 gone - no logout
root ssh:notty 10.0.0.1 Fri Apr 17 18:56 - 18:57 (00:00)
git ssh:notty 10.0.0.1 Fri Apr 17 18:56 - 18:56 (00:00)
vm ssh:notty 10.0.0.1 Fri Apr 17 18:56 - 18:56 (00:00)
test123 ssh:notty 10.0.0.1 Fri Apr 17 18:56 - 18:56 (00:00)
{code}
{code}
# tail /var/log/secure
Apr 17 18:58:25 localhost sshd[29481]: Failed password for invalid user ln from 193.70.88.213 port 34570 ssh2
Apr 17 18:58:25 localhost sshd[29484]: Received disconnect from 193.70.88.213: 11: Bye Bye
Apr 17 18:58:25 localhost sshd[29488]: Failed password for root from 183.82.121.34 port 47762 ssh2
Apr 17 18:58:25 localhost sshd[29489]: Received disconnect from 183.82.121.34: 11: Bye Bye
Apr 17 18:58:27 localhost sshd[29515]: reverse mapping checking getaddrinfo for 45.63.104.211.vultr.com [45.63.104.211] failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 17 18:58:27 localhost sshd[29515]: Invalid user ftpuser from 45.63.104.211
{code}
Для решения проблемы нужно ограничить доступ до сервера по [статье|Обзор безопасности].
h1. Примеры решения проблем
h2. Переполнен разделы с логами /mnt/log или папка /var/log
h3. Корневой раздел переполнен журналом авторизации
Проблема встречается на Softrouter и XGE при интеграции с Carbon Reductor: фильтр выгружает списки заблокированных IP-адресов по ssh и каждая авторизация фиксируется в логе /var/log/secure, от этого он достаточно быстро разрастается.
Проверьте файлы /var/log/secure:
{code}du -sch /var/log/secure*{code}
Если файлы достаточно объёмны (сотни мегабайт и более), значит это Ваша ситуация.
Её можно решить добавив компрессию при ротации логов, для этого измените файл */etc/logrotate.d/syslog*, добавив туда строки *nodelaycompress* и *compress*:
{code}/var/log/cron
/var/log/maillog
/var/log/messages
/var/log/secure
/var/log/spooler
{
sharedscripts
#==Компрессия логов==#
#==
nodelaycompress
compress
#==
postrotate
/bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
endscript
}{code}
h3. Слишком много файлов на диске с логами
При работе биллинг отправляет команды на оборудование. При этом лог команд ведётся для каждого абонента в отдельности. При большом количестве абонентов это может привести к заполнению раздела /mnt/log . Так же при диагностике сервера может выводиться сообщение:
{code}
Мало свободных inode
{code}
# Просмотрите размер раздела /mnt/log
{code}
df -h | grep log
/dev/sda7 14G 5,8G 7,0G 46% /mnt/log
{code}
# Оцените сколько места занято логами учётных записий
{code}
du -sh /app/asr_billing/var/log/abonents
272M /app/asr_billing/var/log/abonents
{code}
# Удалите логи старше 30 дней
{warning:title=Используйте команду в точности как написано ниже!}
Настоятельно не рекомендуем вносить изменение в команду удаления логов, так как это может привести к неработоспособности системы в целом.
{code}
find /app/asr_billing/var/log/abonents/ -atime +30 -type f -delete
{code}
{warning}