- Забит корень диска на 100%
- Проблема при подключении винчестера
- При запуске linux пишет что то непонятное
- 1 ответ 1
- 8 советов для решения проблем с диском Linux и Unix
- 1. Ошибка: Нет свободного места на устройстве
- Решение проблемы, когда диск полон:
- 2. Файловая система находится в режиме только для чтения
- 3. Проблема с дескриптором
- 4. Жесткий диск умирает
- 5. Диску или серверу сильно жарко.
- Linux: проверка диска
- Что такое битые блоки и почему они появляются
- Проверка диска Linux
- Badblocks
- GParted
- Smartmontools
- Safecopy
- Что делать, если обнаружена ошибка в системной программе Ubuntu
- Заключение
Забит корень диска на 100%
Я не профессионал в 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
Также попробуй lsof| grep deleted возможен вариант с неудалёнными файлами. Взято отсюда: http://www.cyberciti.biz/tips/freebsd-why-command-df-and-du-reports-different.
Буквально, пару месяцев назад, для сайта http://www.the-x-files.ru/ я арендовал VPS (видео много). Сейчас я на тарифе в 50 Гб. cPanel показывает, использовано 41 Гб, а через root выводиться инфо, что использовано 49 Гб. По началу я думал, что хостинг-провайдер меня обманывает, ну знаете, чтоб я перешел на другой тариф, по дороже. Сейчас по читал тут, вроде успокоился. Но проблему решать надо как-то.
Вот. до сих пор напоминает о себе:
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, перезагрузись, (за последствия не отвечаю, но Х-ы не загрузятся ) , или грузнись с лайв-диска)
Извращенец. Никаких перезагрузок и отмонтирований:
Источник
Проблема при подключении винчестера
Решил подключить старый (ранее рабочий) жесткий диск, но столкнулся с проблемой:
1) На винде: отображаются все разделы, при заходе в них видно все файлы и папки (т. е. диск «рабочий»), но спустя несколько сек. пока я нахожусь в этом жестком, всё зависает (вообще всё), пока не отключу его руками от материнки, но если я буду пользоваться компом и ни коим образом не затрагивая ни единый раздел второго жесткого диска всё будет отлично работать, пока не притронусь к нему (любым способом, например не заходя в него прогнать антивирусом, то сразу весь комп виснет навечно)
2) В линуксе в программе дисков пишет: ВОЗМОЖНО, ДИСК СКОРО СТАНЕТ НЕРАБОТОСПОСОБНЫМ.
Исключая ответы «выбраси сваё старое га*но и купи новый» , может ли кто что-либо посоветовать? Прогнать к примеру какой-либо утилитой или еще что??
Я как-то не до конца понимаю, диск то вроде как рабочий, система его видит, отображает разделы, файлы в них и т. д.
Ах да, последний раз когда я им пользовался, делая большой баннер в ФШ, что видимо сильно нагрузило систему, исходя из того, что даже перемещение мыши по экрану шло с задержкой, комп завис, пришлось руками перезагружать и после перезагрузки он включался с ошибкой загрузчика (непомню точно что там было написано, но суть как я читал в гугле была с загрузчиком). И спустя месяц я решил снова подключить его и столкнулся с проблемами, описанными выше. В день «поломки» при подключении другого диска, «сломанный» диск комп вообще не видел и при подключении питания к нему никак не реагировал (сейчас же жужжит, давая понять что надежда на излечение всё же есть )
Источник
При запуске linux пишет что то непонятное
/dev/sda1 contains a file system with errors, check forced.
/dev/sda1: Inodes that were part of corrupted orphan linked list found.
/dev/sda1: UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY.
(i. e., without -a or -p options)
fsck exited with status code 4
The root filesystem on /dev/sda1 reuires a manual fsck
Не особо шарю так что помогите исправить эту проблему.
1 ответ 1
Давайте построчно разберём, чего же от нас хочет Linux:
/dev/sda1 содержит файловую систему с ошибками; инициирована проверка.
/dev/sda1: были найдены inod-ы, являющиеся частью повреждённого связного списка.
/dev/sda1: НЕОЖИДАННАЯ НЕСОГЛАСОВАННОСТЬ ДАННЫХ: ЗАПУСТИТЕ fsck ВРУЧНУЮ. (т. е. без ключей -a и -p)
fsck завершила работу с кодом возврата 4
Корневая файловая система на /dev/sda1 требует ручного вызова fsck
В первых трёх строках нам сообщают, что на /dev/sda1 имеются повреждения файловой системы. Однако они не настолько страшны (inode — это заголовок файловой записи). Единственное, что потеряется при восстановлении — уникальный номер и, как результат, путь до соответствующего файла; так что он будет помещён в папку lost+found в корне /dev/sda1 . Главное, чтобы это не оказался какой-нибудь системный файл, ожидаемый во время загрузки ОС по конкретному пути.
Самой последней строкой вывода является (busybox) . Это приглашение командной строки минимальной версии консоли, внутрь которой вшит минимальный набор команд. Вариант аварийный, но его будет достаточно для «починки» раздела и перезагрузкив обычный режим.
Для «починки» введите команду:
Первая часть (аналог Windows-ского chkdsk ) выполнит проверку и безусловное (ключ -y ) исправление ошибок; вторая выполнит перезагрузку сразу же по окончании этой операции.
Кстати, вы не обесточивали компьютер прямо во время работы? Не выдёргивали диск, не отмонтировав его? Если нет, значит жёсткий диск начал «сыпаться», и по окончании проверки вам стоит как можно скорее скопировать всё его содержимое в другое место, пока ещё чего-нибудь не повредилось.
Источник
8 советов для решения проблем с диском Linux и Unix
Can’t write to the hard disk — (не могу записать на жесткий диск) на Linux/Unix системах. Получали такое сообщение? Хотите проверить поврежден ли диск или нет? Хотите понять почему получили сообщение «диск переполнен»? Попробуйте эти 8мь советов, что бы решить проблему с диском.
1. Ошибка: Нет свободного места на устройстве
Когда диск полон на Unix-подобной системе вы получите сообщение об ошибке на экране. Вот например
Первым шагом является запуск команды DF, чтобы узнать информацию об общем пространстве и свободном пространстве в файловой системе, включая разделы:
Или попробуйте читаемый формат
Решение проблемы, когда диск полон:
Сжатие журналов и других файлов используя GZIP или bzip2
Удалить ненужные файлы с помощью команды rm на Unix-подобной системе
Перемещение файлов на другой раздел системы или внешний жесткий диск, используя Rsync команду:
Узнайте самые большие каталоги или файлы которые используют дисковое пространство на Unix-подобных systesm:
Обрезать конкретный файл. Это полезно для файла журнала:
truncate -s 0 /ftpusers/ftp.upload.log
Найти и удалить большие файлы, которые открыты, но были удалены на Linux или Unix:
2. Файловая система находится в режиме только для чтения
Вы можете в конечном итоге получить такое сообщение об ошибке следующим образом, когда вы пытаетесь создать файл или сохранить файл:
Запустите команду монтирования, чтобы узнать, файловая система смонтирована в режиме только чтение:
Чтобы устранить эту проблему, просто перемонтировать файловую систему в режиме чтения-записи:
3. Проблема с дескриптором
Иногда, DF команда сообщает, что есть достаточно свободного места, но система утверждает, файловая система заполнена. Вы должны проверить inode, которые идентифицируют файл и его атрибуты на файловых системах с помощью следующей команды:
Если 100% ваших дескрипторов используются, попробуйте следующие варианты:
- Найти ненужных файлов и удалять или перемещать на другой сервер.
- Найти нежелательные большие файлы и удалить или переместить на другой сервер.
4. Жесткий диск умирает
Ошибки ввода / вывода в лог-файл (например, /var/log/messages) указывает, что что-то не так с жестким диском, и это может быть сбой. Вы можете проверить жесткий диск на наличие ошибок, используя команду smartctl. Синтаксис:
Вы также можете использовать «Disk Utility», чтобы получить ту же информацию
5. Диску или серверу сильно жарко.
Высокие температуры могут привести к плохому функционированию. Так что вам нужно поддерживать нужной температуры сервера и диска. Высокие температуры могут привести к завершении работы сервера или повреждения системы и файлов на диске. Только современные жесткие диски имеют датчик температуры. Hddtemp поддерживает чтение SMART информации от SCSI-диски тоже. Hddtemp может работать как простой инструмент командной строки или как демон, чтобы получить информацию от всех серверов:
Источник
Linux: проверка диска
Компьютер представляет собой устройство, работа которого основана на взаимодействии множества компонентов. Со временем они могут вызывать сбои в работе. Одной из частых причин неполноценной работы машины становятся битые сектора на диске, поэтому периодически его нужно тестировать. Linux предоставляет для этого все возможности.
Что такое битые блоки и почему они появляются
Блок (сектор) – это маленькая ячейка диска, на которой в виде битов (0 и 1) хранится информация. Когда системе не удается записать очередной бит в ячейку, говорят о битом секторе. Причин возникновения таких блоков может быть несколько:
- брак при производстве;
- отключение питания в процессе записи информации;
- физический износ диска.
Изначально практически на всех носителях имеются нарушения. Со временем их количество может увеличиваться, что говорит о скором выходе устройства из строя. В Linux тестировать диск на ошибки возможно несколькими способами.
Проверка диска Linux
На ядре Linux работает несколько ОС, среди которых Ubuntu и Debian. Процедура проверки диска универсальная и подходит для каждой из них. О том, что носитель пора тестировать, стоит задуматься, когда на дисковую систему оказывается большая нагрузка, скорость работы с носителем (запись/чтение) значительно уменьшилась, либо эти процедуры и вовсе вызывают ошибки.
Многие знакомы с программой на Windows – Victoria HDD. Разработчики позаботились о написании ее аналогов для Linux.
Badblocks
Badblocks – дисковая утилита, имеющаяся в Ubuntu и других дистрибутивах Linux по умолчанию. Программа позволяет тестировать как жесткий диск, так и внешние накопители.
Перед тем, как тестировать диск в Linux следует проверить, какие накопители подключены к системе, с помощью утилиты fdisk-l. Она также покажет имеющиеся на них разделы.
Теперь можно приступать к непосредственному тестированию на битые сектора. Работа Badblocks организовывается следующим образом:
В записи используются следующие команды и операнды:·
- -v – выводит подробный отчет о проведенной проверке;·
- /dev/sdk 1 – проверяемый раздел;·
- bsector.txt – запись результатов в текстовый файл.
Если при проверке диска нашлись битые блоки, нужно запустить утилиту fsck, либо e2fsck, в зависимости от используемой файловой системы. Они ограничат запись информации в нерабочие сектора. В случае файловых систем ext2, ext3 или ext4 выполняется следующая команда:
В противном случае:
Параметр -l указывает программе, что битые блоки перечислены в файле bsector.txt, и исключать нужно именно их.
GParted
Утилита проверяет файловую систему Linux, не прибегая к текстовому интерфейсу.
Инструмент изначально не содержится в дистрибутивах операционной системы, поэтому ее необходимо установить, выполнив команду:
В главном окне приложения отображаются доступные диски. О том, что носитель пора тестировать, понятно по восклицательному знаку, расположенному рядом с его именем. Запуск проверки производится путем щелчка по пункту «Проверка на ошибки» в подменю «Раздел», расположенном на панели сверху. Предварительно выбирается нужный диск. По завершении сканирования утилита выведет результат.
Проверка HDD и других запоминающих устройств приложением GParted доступна для пользователей ОС Ubuntu, FreeBSD, Centos, Debian и других и других дистрибутивов, работающих на ядре Linux.
Smartmontools
Инструмент позволяет тестировать файловую систему с большей надежностью. В современных жестких дисках имеется встроенный модуль самоконтроля S. M. A. R. T., который анализирует данные накопителя и помогает определить неисправность на первоначальной стадии. Smartmontools предназначен для работы с этим модулем.
Запуск установки производится через терминал:
- apt install smartmontools – для Ubuntu/Debian;
- yum install smartmontools – для CentOS.
Для просмотра информации о состоянии жесткого диска, вводится строка:
Проверка на ошибки занимает различное время, в зависимости от объема диска. По окончании программа выведет результат о наличии битых секторов, либо их отсутствии.
Утилита имеет и другие параметры: -a, —all, -x, —xall. Для получения дополнительной информации вызывается справка:
Safecopy
Когда возникает потребность тестировать винчестер в Linux, стоит быть готовым к любому результату.
Приложение Safecopy копирует данные с поврежденного устройства на рабочее. Источником могут быть как жесткие диски, так и съемные носители. Этот инструмент игнорирует ошибки ввода/вывода, чтения, битые блоки, продолжая беспрерывно работать. Скорость выполнения максимально возможная, которую обеспечивает компьютер.
Для установки Safecopy на Linux в терминал вводится строка:
Сканирование запускается командой:
Здесь первый путь обозначает поврежденный диск, второй – директорию, куда сохранятся файлы.
Программа способна создать образ файловой системы нестабильно работающего запоминающего устройства.
Что делать, если обнаружена ошибка в системной программе Ubuntu
Установка нового программного обеспечения или изменения системных настроек могут вызвать сообщение «Обнаружена ошибка в системной программе». Многие его игнорируют, так как на общей работе оно не отражается.
С проблемой обычно сталкиваются пользователи Ubuntu версии 16.04. Тестировать HDD в этом случае нет необходимости, так как проблема скорее заключается именно в программном сбое. Сообщение оповещает о непредвиденном завершении работы программы и предлагает отправить отчет разработчикам. При согласии откроется окно браузера, где требуется заполнить форму из 4 шагов. Такой вариант вызывает сложности и не гарантирует исчезновения ошибки.
Второй способ поможет избежать появления сообщения лишь в том случае, если оно вызывается одной и той же программой. Для этого при очередном оповещении нужно установить галку на опцию «Не показывать больше для этой программы».
Третий метод – отключить утилиту Apport, которая отвечает в Linux за сбор информации и отправку отчетов. Такой подход полностью исключит всплывание окон с ошибками. Возможно отключение только показа уведомлений, оставляя службу сбора в рабочем состоянии. Для этого необходимо выполнить:
gsettings set com.ubuntu.update-notifier show-apport-crashes false
Данные продолжат собираться в папке /var/crash. Их периодически необходимо чистить, чтобы они не заполняли дисковое пространство:
Для полного отключения служб Apport, в терминал вводится запись:
В появившемся тексте значение поля enable меняется с 1 на 0. В дальнейшем, чтобы снова включить службу, возвращаются настройки по умолчанию.
Заключение
Для предотвращения потери файлов жесткий диск и съемные носители рекомендуется периодически тестировать. Linux предлагает несколько подходов к решению задачи. На выбор предоставляется перечень утилит, которые выявляют поврежденные сектора и обеспечивают перенос информации на нормально функционирующее устройство.
Источник