Мало места на диске возможны сбои в работе астра линукс

Обновлено: 04.07.2024

18 янв 2017, 08:23

если "Мало свободного места на диске "Корень файловой системы"
первым делом очистить корзину и в терминале у
sudo apt-get clean
sudo apt-get autoremove
sudo apt-get autoclean

По разбухшим логам - ТЫЦ

По /var - если и выносить , то не в хомяк, а на отдельный раздел

"Не ты выбираешь Linux, а Linux выбирает тебя"
(с)Себастьян Перейра, торговец чёрным деревом

Мало свободного места на диске "Корень файловой системы""

18 янв 2017, 08:41

Корзина практически пуста . С точки зрения моего пользователя. Может root увидит больше?
И где живет корзина?
trash:/// это что значит?
Как настраивается предельный размер корзины?

Мало свободного места на диске "Корень файловой системы""

18 янв 2017, 09:25

Похоже проблема в огромном размере файла /var/logsyslog - 22 Гб Jan 18 07:39:43 Magnit-Server nmbd[22260]: Error = Невозможно назначить запрошенный адрес
Jan 18 07:39:43 Magnit-Server nmbd[22260]: [2017/01/18 07:39:43.292136, 0] ../source3/nmbd/nmbd_subnetdb.c:127(make_subnet)
Jan 18 07:39:43 Magnit-Server nmbd[22260]: nmbd_subnetdb:make_subnet()
Jan 18 07:39:43 Magnit-Server nmbd[22260]: Failed to open nmb bcast socket on interface 10.0.4.255 for port 137. Error was Невозможно назначить запрошенный адрес
Jan 18 07:39:43 Magnit-Server nmbd[22260]: [2017/01/18 07:39:43.292368, 0] ../source3/lib/util_sock.c:396(open_socket_in)
Jan 18 07:39:43 Magnit-Server nmbd[22260]: bind failed on port 137 socket_addr = 10.0.4.255.
Jan 18 07:39:43 Magnit-Server nmbd[22260]: Error = Невозможно назначить запрошенный адрес
Jan 18 07:39:43 Magnit-Server nmbd[22260]: [2017/01/18 07:39:43.292416, 0] ../source3/nmbd/nmbd_subnetdb.c:127(make_subnet)
Jan 18 07:39:43 Magnit-Server nmbd[22260]: nmbd_subnetdb:make_subnet()
Jan 18 07:39:43 Magnit-Server nmbd[22260]: Failed to open nmb bcast socket on interface 10.0.4.255 for port 137. Error was Невозможно назначить запрошенный адрес
Jan 18 07:39:43 Magnit-Server nmbd[22260]: [2017/01/18 07:39:43.292639, 0] ../source3/lib/util_sock.c:396(open_socket_in)
Jan 18 07:39:43 Magnit-Server nmbd[22260]: bind failed on port 137 socket_addr = 10.0.4.255.
Jan 18 07:39:43 Magnit-Server nmbd[22260]: Error = Невозможно назначить запрошенный адрес
Jan 18 07:39:43 Magnit-Server nmbd[22260]: [2017/01/18 07:39:43.292686, 0] ../source3/nmbd/nmbd_subnetdb.c:127(make_subnet)
Jan 18 07:39:43 Magnit-Server nmbd[22260]: nmbd_subnetdb:make_subnet()
Jan 18 07:39:43 Magnit-Server nmbd[22260]: Failed to open nmb bcast socket on interface 10.0.4.255 for port 137. Error was Невозможно назначить запрошенный адрес
Jan 18 07:39:43 Magnit-Server nmbd[22260]: [2017/01/18 07:39:43.292909, 0] ../source3/lib/util_sock.c:396(open_socket_in)
Jan 18 07:39:43 Magnit-Server nmbd[22260]: bind failed on port 137 socket_addr = 10.0.4.255.
Jan 18 07:39:43 Magnit-Server nmbd[22260]: Error = Невозможно назначить запрошенный адрес
Jan 18 07:39:43 Magnit-Server nmbd[22260]: [2017/01/18 07:39:43.292957, 0] ../source3/nmbd/nmbd_subnetdb.c:127(make_subnet)
Jan 18 07:39:43 Magnit-Server nmbd[22260]: nmbd_subnetdb:make_subnet()
Jan 18 07:39:43 Magnit-Server nmbd[22260]: Failed to open nmb bcast socket on interface 10.0.4.255 for port 137. Error was Невозможно назначить запрошенный адрес

Мало свободного места на диске "Корень файловой системы""

18 янв 2017, 09:28

/.locale/share , и да , не забудте почистить логи, живут в - /var/log

Мало свободного места на диске "Корень файловой системы""

18 янв 2017, 09:31

NMBD(8) System Administration tools NMBD(8)

NAME
nmbd - NetBIOS name server to provide NetBIOS over IP naming services
to clients

DESCRIPTION
This program is part of the samba (7) suite.

Мало свободного места на диске "Корень файловой системы""

18 янв 2017, 11:15

И чего вас куда-то тянет для очистки корзины ? имеющихся средств мало? что в мате, что в цмоне , что в большинстве графических сред или открыв каталог корзины клацаньем по ярлыку или апплету нажать кноповку "Очистить корзиину"
для линуксятника считается недостаточым или недостойным? "Не ты выбираешь Linux, а Linux выбирает тебя"
(с)Себастьян Перейра, торговец чёрным деревом

Мало свободного места на диске "Корень файловой системы""

18 янв 2017, 13:05

colonel писал(а): И чего вас куда-то тянет для очистки корзины ? имеющихся средств мало? Я новичок и еще плохо ориентируюсь в файловой системе. Просто хочу знать что где лежит, в каком разделе.
В Винде было понятно, что A B C D E и на каждом диске своё дерево каталогов.
Плюс если у каждого пользователя свой Home, то и корзина должна быть индивидуальная?
Пользователей как минимум два всегда - я и root. У Рута есть корзина?
А ярлыки и оболочки мне пока больше командной строки нравятся("хоть они и мышами воняют" )

Мало свободного места на диске "Корень файловой системы""

18 янв 2017, 13:15

spd38 писал(а): Плюс если у каждого пользователя свой Home, то и корзина должна быть индивидуальная?

/.local/share/Trash/ или /home/ИМЯ_ПОЛЬЗОВАТЕЛЯ/.local/share/Trash

Настоящая водка — это не пьянство, а ключ к своей совести, с нее-то и начинается настоящая мудрость. (c)

Мало свободного места на диске "Корень файловой системы""

18 янв 2017, 13:17

spd38, Представь себе, и у рута своя корзина есть ( не скажу где живёт ), более того, если есть рядом винда (тьфу на неё ), и линуксом там что то удалишь, то он поставит там свою корзину, поскольку виндовой брезгует пользоваться.

Мало свободного места на диске "Корень файловой системы""

18 янв 2017, 13:38

Мало свободного места на диске "Корень файловой системы""

18 янв 2017, 14:02

spd38 , BleachBit установи и пользуйся периодически.

Мало свободного места на диске "Корень файловой системы""

18 янв 2017, 15:32

spd38 писал(а): А ярлыки и оболочки мне пока больше командной строки нравятся("хоть они и мышами воняют" ) вот те раз. вот те и новый потенциальный красноглазик ..
не то что . "Linux Mint отстой а Windows 10 рулит" , .. Feren OS - . . кастомизация. стиль Windows 10 . Windows 7. MacOS.
папочки и ярлыки как в винде . то хочу чтоб было как в винде , то как сделать чтобы было как в винде. .. .умереть не встать
spd38 писал(а): Я новичок и еще плохо ориентируюсь в файловой системе. Просто хочу знать что где лежит, в каком разделе.
В Винде было понятно. Всё приходит со временем. когда-то было непонятно и в винде
апотому - ТЫЦ-ДЫДЫЦ>>> Не знаю. наверное можно . поковыряйте инет , можете и к разрабам обратиться о внесении такого рода изменений в систему оповещения об угрозе переполнения ФС .
вообще-то, насколько помнится, винда при переполнении чаще всего вообще не запускается, хотя может в последних виндах и поправили
" ФС в Linux (ext) имеет 5% резервирование в каждом разделе для нужд root. Это резервированное место не может писать кто-то с UID отличным от root. " (с) отседова
"Однако, не все знают что по умолчанию ext3 (ext2 кстати, тоже) (прим . моё и ext4 тожево) резервирует под свои нужды целых 5% от всего дискового пространства.
Эти 5% используются для работы приложений, выполняемых от root и только при нехватке пространства на жестком диске. " (с) оттудысяво
Ну и для ознакомления . "Не ты выбираешь Linux, а Linux выбирает тебя"
(с)Себастьян Перейра, торговец чёрным деревом

Мало свободного места на диске "Корень файловой системы""

18 янв 2017, 16:23

colonel писал(а): вот те раз. вот те и новый потенциальный красноглазик ..
не то что . "Linux Mint отстой а Windows 10 рулит" , .. Feren OS - . . кастомизация. стиль Windows 10 . Windows 7. MacOS.
папочки и ярлыки как в винде . то хочу чтоб было как в винде , то как сделать чтобы было как в винде. .. .умереть не встать Я за дуализм GUI и командной строки. Запомнить десятки команд с сотнями ключей сходу сложноватенько . Проще освоить дюжину оболочек и программ(буду их звать для краткости оболочки). А вот когда потребуется что-то сложное реализовать, очень хорошо что есть команды, конвейер, фильты и командные языки(осталось только изучить ). Понятно, что Линуксе, в отличии от Вин, сначала появляются команды, а потом оболочки. Иногда их даже много, и у каждой свои достоинства и недостатки. Пользователь попадает в ситуацию "Разборчивой невесты", долго ковыряется, а когда время поджимает, хватает первого попавшегося урода-жениха, проклиная всех мужиков.

Мало свободного места на диске "Корень файловой системы""

18 янв 2017, 16:33

colonel писал(а): можете и к разрабам обратиться о внесении такого рода изменений

Это куда?
Дайте жалобную книгу, пожалуйста!

Файловая система ext4 немного расстроила. Лимит на длину русских имён файлов меньше, чем в NTFS. В спецификациях длина имени 512 байт, но кодировка-то UTF16 по 4 байта.

Мало свободного места на диске "Корень файловой системы""

20 янв 2017, 12:14

поставьте другую,
жизнь в никсах не заканчивается на ext,2,3,4 , есть и другие fs (и не виндовые fat , нтфс или exfat )
подбирай что вам лучше подходит. большинство устраивает дефолтные ext , как оптимальный для большинства юзеров и ими решаемых задач. "Не ты выбираешь Linux, а Linux выбирает тебя"
(с)Себастьян Перейра, торговец чёрным деревом

Мало свободного места на диске "Корень файловой системы""

20 янв 2017, 18:55

1 - logrotate настраиваем чтобы логи старые или удалял или архивировал и переносил.
2 - раздел /var монтируем отдельно. при распухании логов в /var просто перестанет работать то что его использует
3 - настройте ту прогу которая срет в логи так адски чтобы она больше так не делала.
4 - задайте лимиты использования разделов. например чтобы конкретный пользователь не мог насрать больше N гигов в раздел или лимит на размер файла итд.

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

Для каждого сервера разбивка индивидуальна, но в целом неплохая идея для начала сделать /, /var, /tmp, /home, /usr. и для каждого раздела правильно настроить все приблуды типа параметров, квот, лимитов итд итп,

такая проблема , армы выпали из домена пишет что вход не удачен , сверил время все окай , перезапустил сервер черный экран с надписью "мало места на диске возможен сбой системы " посоветуйте что сделать ,?

Montfer

New member

вывод команды df
Если диск реально забит на 100%, смотреть, какой именно каталог много весит. Но подозреваю, что у вас kernel.log (или kern.log) быстро растет в размерах

Антон Радионов

New member

А как вообще бороться с этим моментом, очистку логов в редакторе крон ставил каждые две минуты или есть другие варианты

Montfer

New member

Для начала убедитесь, точно логи виноваты или нет. Если дело в логах, можно убрать некоторые галочки в аудите (если ваши инструкции по ЗИ разрешают это делать).

Rayman

New member

самое просто сделать ротацию логов на kernlog. logrotate

Антон Радионов

New member

самое просто сделать ротацию логов на kernlog. logrotate

Rayman

New member

Далее, создаем конф.файл в /etc/logrotate.d/parsec

Перезапустить крон и по идее все автоматом будет отрабатывать раз в сутки. Соответственно в /var/log/parsec/ будут создаваться ротированые лог файлы. По истечении 7 ротаций будет перезапись. Писал по памяти, если что не так поправьте. А так почитайте за logrotate, от debian уйма примеров что и как сделать

Я не профессионал в Linux системах поэтому сильно ногами не бить. С недавнего времени корень диска забился на 100% до сих пор не могу найти где собака зарыта. Может Вы мне покажете где искать?

ну где эти 194 гига ума не приложу ?

так же делал поиск файлов больше 100 мб . поиск дал пару гиговых файлов, и несколько 300, 500 и 700 мб. Но это капля в море.

Что в /var/log/?
ФС какая?
lost+found удали.

Как вариант, что-то удалил, оно используется, на диске не видно, но место еще занимает, попробуй перегрузится.

Если ФС журналируемая, то какая именно и сколько уже находится в эксплуатации?

/dev/sda6 148G 87G 62G 59% /home
/dev/sda5 130G 763M 129G 1% /var

Как вариант, отмонтируй эти разделы (скорее всего не захотят, поэтому удали с fstab, перезагрузись, (за последствия не отвечаю, но Х-ы не загрузятся ) , или грузнись с лайв-диска) и посмотри что в sda2/home sda2/var? Может раньше все было на sda2 или, например, часть файлов пишется в sda2/var/. вместо sda5/.

Кстати, наиболее вероятный вариант. У тебя скорее всего старый /home остался на /dev/sda2 и при загрузке системы перекрывается примонтированным разделом, но место на диске все равно ведь занимает.

А я то тут причем?? о_О

Возможно какой-то лог пишется в /var/log/, который на sda2 (до того, как sda5 монтируется), у меня dmesg (ЕМНИП) на дебиане за месяца 2 набег

1.5 гб (правда весь / был на одном разделе, кроме хоума.)

Вы тут не при чем :-)

Лог не может писаться в корень, потому что все разделы монтируются одновременно, а / до этого момента в readonly. Вроде даже в rw / перемонтируется уже после монтирования других ФС, но идея здравая. Что-то в /home или /var на sda2 может лежать (от предыдущей системы, например) и портить всю картину.

А как мне распознать и вытащить этот старый /home? Я этот сервак не ставил он мне по наследству достался от предыдущего админа. Я с ним никаких манипуляций не совершал, доступ к инету у него нет.

Грузишься с лайв диска, монтируешь корень sda2 (mount /dev/sda2 /mnt/), cd /mnt/ смотришь что там.
Можно просто выйти в терминал, выйти всемя пользователями (кроме рута), прихлопнуть Х-ы, umount /home/
cd /home
ls

Можно просто выйти в терминал, выйти всемя пользователями (кроме рута), прихлопнуть Х-ы, umount /home/ ; cd /home ; ls

Но /var на 'лету' не отмонтируешь просто-так.

Я бы прям сейчас попробовал с лайв сд смонтировать sda2, но сервак рабочий пока :) так что придется после рабочего дня смотреть. Спасибо Всем за ответы.

Пожалуйста, но это не обязательно так будет. Хотя я другой причины не вижу.

Покажи, что и как сейчас смонтировано в системе mount -l

Вот. до сих пор напоминает о себе:

Failure Reason: Unable to connect to connect to 143 on 127.0.0.1: No buffer space available: connect: No buffer space available . propagated at /usr/local/cpanel/Cpanel/TailWatch/ChkServd.pm line 454.

Number of Restart Attempts: 21

Startup Log: /etc/init.d/dovecot: line 15: 23742 Alarm clock /usr/sbin/dovecot > /dev/null 2>&1 /etc/rc.d/init.d/cpfunctions: fork: Cannot allocate memory /etc/init.d/dovecot: line 15: 3345 Alarm clock /usr/sbin/dovecot > /dev/null 2>&1

скорее всего не захотят, поэтому удали с fstab, перезагрузись, (за последствия не отвечаю, но Х-ы не загрузятся ) , или грузнись с лайв-диска)

Эта ситуация выглядит странной и непонятной — что нужно сделать для очистки диска, если место и так есть?

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

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

Что делать, если закончилось место в Linux

Вполне возможно, что на диске действительно закончилось место, тогда вам рекомендуются следующие статьи:

Если же место на самом деле имеется, то продолжайте чтение.

Проверьте с du и df

Перед тем как начать искать проблему, давайте убедимся, что на диске действительно есть свободное место. Хотя инструменты с графическим интерфейсом хорошие, намного лучше использовать программы напрямую из командной строки.

Начнём с du. Укажем ей базовую директорию на диске у которого проблемы. Это руководство подразумевает, что проблемным диском является раздел с рутом.

Для обхода всего дерева директорий потребуется время.

Теперь попробуем с df:

Добавьте корень файловой системы (рут) и файловые системы, смонтированные под ним. Например, если у вас есть «/home» на отдельном диске, добавьте это к показанию для root. Количество занятого и свободного пространства должно получиться близко к тому, что нам показала программа du. Если это не так, это может указывать на то, что удалённые файлы используются процессами.

Главное, на что следует обратить внимание, чтобы вывод этих команд о занятом пространстве соответствовал друг другу и размеру диска. Если это не так, значит имеется проблема.

Возможные причины

Возможны разные ситуации возникновения ошибки о том, что диск переполнен, когда на самом деле на нём ещё достаточно места. Если вы видите несоответствие между выводом команд du и df, то перейдите к первому варианту решения проблемы. В противном случае начните со второго.

Удаление файлов занятых процессом

Иногда файл будет удалён, но процесс все ещё использует его. Linux не освободит хранилище, связанное с файлом, пока процесс ещё запущен. Вам просто нужно найти процесс и перезапустить его.

Попробуйте найти процесс.

Если результатов нет, то попробуйте команду:

В списке должен присутствовать процесс, вызывающий проблему, затем просто перезапустите его:

Недостаточно Инод (Inode)

Для современных файловых систем Linux есть такое понятие как иноды (“inodes”) - это набор метаданных на файловой системе. Иноды отслеживают информацию о файлах. Многие файловые системы имеют фиксированное количество инод, поэтому очень возможно занять максимальное выделенное количество без заполнения самой файловой системы. Вы можете использовать для проверки команду df:

Сравните количество существующих инод с количеством занятых. Если больше нет свободных, к сожалению, вы не можете получить больше. Выход: удалите ненужные или устаревшие файлы для очистки инод.

В нормальных условиях, даже на системах интенсивно использующих постоянное хранилище, редко происходит потребление всех инод. Как правило, исчерпание inodes сигнализирует о другой проблеме. Обычно причиной является неконтролируемое создание огромного количество файлов из-за бага в системе или в программе.

В первую очередь нужно локализовать папку, в которой возникла проблема.

Следующая команда выведет количество используемых инод каждой папкой, присутствующей в корне файловой системы:

Ещё варианты команд, которые делают это же самое (по умолчанию они настроены проверять текущую папку — это можно изменить, для этого вместо точки впишите желаемую для проверки папку:

Когда найдена папка с наибольшим количеством инод, то проверьте её подпапки — для поиска проблемной. Продолжайте эти действия, пока не найдёте папку с огромным количеством нагенерированных файлов.

Например, использование первой команды для поиска по директории /src/:

Вариант для поиска по директории /var/cache/:

В разных ситуациях для пользователей проблемными папками оказывались:

/var/lib/php/sessions/
/var/cache/fontconfig
/usr/src/
/var/cache/eaccelerator/
/var/log/squid3/

В /usr/src/ накапливалось слишком большое количество файлов, имеющих отношение к предыдущим ядрам. В /var/lib/php/sessions/ - бесконечные сессии phpMyAdmin. В /var/log/squid3/ и вообще в папке /var/log/ может накопиться огромное количество файлов с журналами от неправильно работающей программы или просто за много лет. В папке /var/cache/ может скопиться огромное количество файлов, имеющих отношение к кэшированию.

В моём случае причиной проблемы оказалась папка /var/cache/fontconfig — в этой папке постоянно накапливаются новые файлы (я не знаю, насколько это нормально) и по итогу работы за 4 года из-за этой папки закончились иноды.

Когда проблемная папка найдена, то нужно её очистить. Скорее всего все файлы в ней не нужны (оцените это исходя из вашей ситуации). Также весьма вероятно, что файлов там астрономическое количество и их обработка может затянуться на часы, поэтому самый быстрый вариант — удалить папку целиком, а затем создать её заново. Даже при таком подходе в моём случае удаление папки /var/cache/fontconfig заняло около 10-20 минут.

Это полностью разрешило мою проблему и снизило количество используемых инод со 100% до 13%:

Плохие блоки

Ещё одна распространённая проблема — это плохие блоки в файловой системе. Со временем из-за износа дисков, файловые системы повреждаются. Ваша операционная система, скорее всего, увидит эти блоки пригодными для использования, если они не помечены иным образом. Лучший способ найти и пометить эти блоки — использовать fsck с флагом -cc. Помните, что вы не можете использовать fsck из той же файловой системы, которую тестируете. Вам, вероятно, понадобится использовать Live CD.

Очевидно, замените /dev/sda2 на имя того диска и раздела, который вы хотите проверить. Кроме того, имейте в виду, что это, вероятно, займёт много времени.

Надеюсь, одно из этих решений решило вашу проблему. Эту проблему не всегда легко диагностировать в каждом случае. Однако, если повезёт, вы сможете устранить источник проблемы и продолжить пользоваться системой без её переустановки.

Читайте также: