APT во время работы спонтанно начинает гадить

у тебя сам апт косячит. а раз не экономилось место - значит, это хардлинки. такие файлы рождаются при сбоях.

нахрена localepurge запускает apt-cache policy??? у тебя точно debian? или самосбор какой-то, с ручным тюнингом «от Димона»?

При чём тут это вообще?

значит, это хардлинки

На хардлинки не похоже, это раз. И как тогда объяснить, что несколько гигов таки очистилось и файлы все разные?

нахрена localepurge запускает apt-cache policy???

Инфу о локалях оттуда парсит, видать, я-то откуда знаю?

или самосбор какой-то, с ручным тюнингом «от Димона»?

Ну можно и так сказать. Только как это влияет на ПМ?

На хардлинки не похоже, это раз. И как тогда объяснить, что несколько гигов таки очистилось и файлы все разные?

почему не похоже

Инфу о локалях оттуда парсит, видать, я-то откуда знаю?

нет, localepurge не делает так. инфу о локалях он не оттуда парсит. я разбирал localepurge

Ну можно и так сказать. Только как это влияет на ПМ?

влияет так, что он не работает :) всяк, кто считает себя умнее Debian-а - должен страдать. :) это закон. в debian можно пользоваться только стандартными средствами debian, без исключений. иначе лучше слаки, генты и подобное.

Не кури больше этот сбор, поставь настоящий Дебиан.

root@linux:/# rm -rf /var/cache/apt
root@linux:/# ln -s /dev/null /var/cache/apt

Я так делаю, когда место гадится.

(бывало даже до 30 гигов, хотя места на разделе столько не было и при удалении освободилось лишь несколько гигов)

root reserved space.

я не понял, в чём баг?

почему не похоже

Ну я файл от хардлинка не отличаю, что ли?

я разбирал localepurge

Ну а что, aptitude это делает? Зачем?

всяк, кто считает себя умнее Debian-а - должен страдать. :)

А чернокожие должны пахать, потому что они чернокожие, ага.

в debian можно пользоваться только стандартными средствами debian, без исключений

И на фига нужна система без софта?

Настоящий Дебиан - для пуленепробиваемых серверов, нафиг он мне нужен?

Что самое интересное, формально эти файлы занимают дохрена места (бывало даже до 30 гигов, хотя места на разделе столько не было и при удалении освободилось лишь несколько гигов) - разве ext3 умеет в сжатие?

sparse файлы

Далее. Проверь диск smartctl'ом. Если он дохнет, может быть всё что угодно

или самосбор какой-то, с ручным тюнингом «от Димона»?

Ну можно и так сказать. Только как это влияет на ПМ?

Ну так найди Димона и спроси «что за фигня, Димон?»

В debian и ubuntu я такого не видел ни разу.

Ещё после появления проблемы запусти atop и смотри, что происходит.

Ну и не мешало бы загрузиться с livecd/dvd/usb и принудительно проверить ФС

Алё, а кэш пакетов?

И это не решение проблемы, а костыль, который не поможет, когда срачка уже вовсю забила I/O.

root reserved space.

5% от 50 гигов. Не стыкуется.

я не понял, в чём баг?
создании в /var/cache/apt сотен файлов с именем вида pkgcache.bin.<hash>

Что тут непонятного? В норме он так не делает.

sparse

Как оно мне поможет? Это же семантический анализатор содержимого?

Проверь диск smartctl'ом

Да более-менее регулярно проверяю, там ничего серьёзного нет, разве что G-Sense Error Rate большой.

Ну так найди Димона и спроси «что за фигня, Димон?»

Ты не понял, «Димон» - это я :D

atop

Он дисковую активность мониторить умеет? Вообще, когда зависает конкретно, уже ни top, ни тем более htop запустить нереально.

принудительно проверить ФС

Проверял недавно.

sparse

Как оно мне поможет?

Ты спросил - «разве ext3 умеет в сжатие?»

http://ru.wikipedia.org/wiki/Разрежённый_файл

Он дисковую активность мониторить умеет?

Частично. Приложение не покажет, но iowait отобразит, и плюс наиболее загруженные диски. Зато он показывает все основные параметры понемногу, выделяя аномалии и высокую загрузку красным.

Поможет понять, в каком направлении копать дальше

Вообще, когда зависает конкретно, уже ни top, ни тем более htop запустить нереально.

У тебя ведь проблемы с менеджером пакетов? Кто мешает запустить atop перед действиями с менеджером пакетов?

Начинается с небольших тормозов, а минут через десять-пятнадцать даже в tty выполнения команд можно ждать минутами.

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

Кто мешает запустить atop перед действиями с менеджером пакетов?

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

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

Первое исходя из тех редких случаев, когда отмониторить что-то всё же удавалось, отброшено. Индикатор харда же постоянно горит.

А. Ну так они же пустого места не содержат почти, прикол в том, что они очень похожие, но не одинаковые. Одинаковые блоки ext3 сжимать не умеет часом? (ссылаться с нескольких айнодов разных файлов на один)

Индикатор харда же постоянно горит.

Я бы всё же сказал, что проблемы с диском. Либо по каким-то причинам параллельно запускается много процессов, которые хотят писать на диск

В syslog есть ошибки записи на диск?

Попробуй в /var/cache/apt смонтировать tmpfs

Статистику дисковой активности покажет iostat из пакета sysstat

Если ты хочешь информацию о том, какое именно приложение обращалось к диску, то blktrace и blkparse. Но трейс тоже нужно куда-то записать...

А. Ну так они же пустого места не содержат почти,

Сравни вывод du и ls. Если это всё же хардлинки, можно это заметить по одинаковым инодам. ls -i

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

См. lsof | grep deleted

Т.е. может быть ты думал что удалил файлы, а место не освободилось, а на самом деле какое-то открытое приложение «держит» эти файлы

Одинаковые блоки ext3 сжимать не умеет часом?

Насколько я знаю, дедупликации в ext* нет

Ну я файл от хардлинка не отличаю, что ли?

O_o. Вообще-то это одно и то же. Ты перепутал жёсткую ссылку с символической ссылкой

router@rhea:~$ touch test
router@rhea:~$ ls -lih test
39846648 -rw-r--r-- 1 router router 0 май 21 01:05 test
router@rhea:~$ ln test test.1
router@rhea:~$ ln -s test test.2
router@rhea:~$ ls -lih test test.1 test.2
39846648 -rw-r--r-- 2 router router 0 май 21 01:05 test
39846648 -rw-r--r-- 2 router router 0 май 21 01:05 test.1
39846665 lrwxrwxrwx 1 router router 4 май 21 01:05 test.2 -> test

В syslog есть ошибки записи на диск?

У меня ж journald.

Но трейс тоже нужно куда-то записать...

А если на флешку?

Ну и совсем дурацкая мысль. Вдруг ты дотюнил систему до того, что получаешь 12309 на родном ext3. Или какую-то проблему с планировщиком I/O

Поставь elevator=deadline в параметры ядра и посмотри, не исчезнет ли проблема.

У меня ж journald.

Да мне фиолетово. Ищи куда он пишет логи. Или через утилиту dmesg ;)

ls -i

Таки разные.

Т.е. может быть ты думал что удалил файлы, а место не освободилось

Оно и после ребутов не освобождалось. Да и не было его столько.

Вдруг ты дотюнил систему до того, что получаешь 12309 на родном ext3.

Ну при уходе в своп система люто тормозит, так что... Но планировщик же cfq искробки стоял, я не трогал.

Да какая разница, если они бинарные? journalctl|grep disk ошибок не кажет.

И на фига нужна система без софта?

у нас разные понятия «без софта». но debian - это закрытая самодостаточная система. и эксперименты с ней заканчиваются плохо. всегда. :)

поэтому вопрос изначально некорректен, и вводит в заблуждение. должен быть «я сломал что-то в debian. подскажите, что именно» :)

должен быть «я сломал что-то в debian. подскажите, что именно» :)

Это кагбэ из сабжа подразумевается и из

и dpkg, и aptitude, и остальной связанный с ними софт многократно после появления проблем обновлялись, то есть багом в одной версии не пахнет

Чё тебе не нравится-то? И вообще, с таким подходом к проблемам следует валить на винфак.