Проблема со свободным местом

[gOsToFf]

Такая проблема. df -h показывает что свободного места нету. Что раздел / занят на 100%.

Код: Выделить всё

# df -h
Файловая система      Разм  Исп  Дост  Исп% смонтирована на
/dev/mapper/VolGroup00-LogVol00
                       23G   23G     0 100% /
/dev/sda1              99M   20M   74M  21% /boot
tmpfs                 502M     0  502M   0% /dev/shm

При этом

Код: Выделить всё

# du -sh /*
8,1M    bin
15M     boot
68K     dev
64M     etc
48K     home
244M    lib
26M     lib64
16K     lost+found
8,0K    media
0       misc
8,0K    mnt
0       net
8,0K    opt
0       proc
1,2G    root
37M     sbin
8,0K    selinux
8,0K    srv
0       sys
24K     tmp
1,5G    usr
145M    var
3,3G    vhosts

Как так?
_______________________________

Код: Выделить всё

# cat /etc/redhat-release
CentOS release 5.8 (Final)

Код: Выделить всё

# uname -a
Linux local.web 2.6.18-308.4.1.el5 #1 SMP Tue Apr 17 17:08:00 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux

Код: Выделить всё

# fdisk -l

Диск /dev/sda: 26.8 ГБ, 26843545600 байт
255 heads, 63 sectors/track, 3263 cylinders
Единицы = цилиндры по 16065 * 512 = 8225280 байт

Устр-во Загр     Начало       Конец       Блоки   Id  Система
/dev/sda1   *           1          13      104391   83  Linux
/dev/sda2              14        3263    26105625   8e  Linux LVM

[SLEDopit]

du -sh /*

Не затрагивает скрытые файлы/директории в / . Возможно, они есть и занимают много места.
Скрытые == имя начинается с точки.
Можно проверить их наличие командой ls -a /

[gOsToFf]

Ну это я тоже знаю.

Код: Выделить всё

# ls -la
итого 182
drwxr-xr-x  25 root root  4096 Май 31 17:54 .
drwxr-xr-x  25 root root  4096 Май 31 17:54 ..
-rw-r--r--   1 root root     0 Май 31 17:24 .autofsck
-rw-r--r--   1 root root     0 Июл  5  2012 .autorelabel
drwxr-xr-x   2 root root  4096 Ноя 27  2012 bin
drwxr-xr-x   4 root root  1024 Май 25  2012 boot
drwxr-xr-x  11 root root  3880 Май 31 17:24 dev
drwxr-xr-x  93 root root 12288 Май 31 17:24 etc
drwxr-xr-x   4 root root  4096 Дек 21 17:46 home
drwxr-xr-x  11 root root  4096 Ноя 26  2012 lib
drwxr-xr-x   9 root root  4096 Ноя 27  2012 lib64
drwx------   2 root root 16384 Май 25  2012 lost+found
drwxr-xr-x   2 root root  4096 Май 11  2011 media
drwxr-xr-x   2 root root     0 Май 31 17:24 misc
drwxr-xr-x   2 root root  4096 Май 11  2011 mnt
drwxr-xr-x   2 root root     0 Май 31 17:24 net
drwxr-xr-x   2 root root  4096 Май 11  2011 opt
dr-xr-xr-x 111 root root     0 Май 31 17:23 proc
-rw-------   1 root root  1024 Май 31 17:54 .rnd
drwxr-x---   5 root root  4096 Июн  3 15:59 root
drwxr-xr-x   2 root root 12288 Янв 10 15:39 sbin
drwxr-xr-x   2 root root  4096 Май 25  2012 selinux
drwxr-xr-x   2 root root  4096 Май 11  2011 srv
drwxr-xr-x  11 root root     0 Май 31 17:23 sys
drwxrwxrwt   5 root root  4096 Июн  3 04:02 tmp
drwxr-xr-x  15 root root  4096 Май 25  2012 usr
drwxr-xr-x  23 root root  4096 Сен 26  2012 var
drwxr-xr-x   6 root root  4096 Июн  3 15:55 vhosts

А все что в папках скрытые du уже учитывает вроде.

[Bizdelnick]

Ну так и что говорит du -sh /.*?

[gOsToFf]

вот что.

Код: Выделить всё

# du -sh /.*
6,5G    /.
6,4G    /..
0       /.autofsck
0       /.autorelabel
4,0K    /.rnd

[anonymous.ru]

Перезагружаться пробовали?

[SLEDopit]

Перезагрузитесь. С очень большой вероятностью это решит проблему (:

Если чуть подоробнее: вероятнее всего, вы не так давно обнаружили, что места нет и решили удалить какой-нибудь тяжёлый файл. Нашли лог какого-нибудь демона (а-ля апач) и грохнули его командой rm, а сам демон не перезапустили. Естественно, rm радостно завершился и du больше не считает этот файл, однако с диска он таки не удалился, потому что демон все ещё использует именно его.
Так что в принципе, достаточно просто перезапустить демон/процесс, который использовал этот файл, чтобы всё же освободить место.

upd.

Перезагружаться пробовали?

почти синхронно (:

[gOsToFf]

Перезагрузка помогает, но это не решение. А вот насчет того что процесс держит все в памяти это верно оказалось. Спасибо.

[pelmen]

Таки да, файл удалили, а процесс им еще пользуется. Смотрите в /proc/$PID/ Когда найдёте там большой файл, смотрите, что за процесс с этим PIDом висит. Если что-то не принципиальное - перезапустите этот процесс. В противном случае придётся перезагружать систему, но это вряд ли понадобится