The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"дисковый объем ползет в минус ;("
Вариант для распечатки  
Пред. тема | След. тема 
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение [Проследить за развитием треда]

"дисковый объем ползет в минус ;(" 
Сообщение от schtazen emailИскать по авторуВ закладки(??) on 23-Июн-05, 15:27  (MSK)
ns[/var]# uname -a
FreeBSD ns.tdntmk.ru 4.7-RELEASE FreeBSD 4.7-RELEASE #0: Tue Sep 30 21:56:16 MSD 2003     noc@ns.company.ru:/usr/src/sys/compile/2003_14_05 i386

ns[/var]# du -s -h /var/
3.8G    /var/
ns[/var]# du -d 1 -h /var/
2.0K    /var/account
6.0K    /var/at
12K    /var/backups
4.0K    /var/crash
8.0K    /var/cron
2.2M    /var/db
2.0K    /var/empty
2.0K    /var/heimdal
73M    /var/log
58K    /var/mail
4.0K    /var/msgs
2.0K    /var/preserve
98K    /var/run
2.0K    /var/rwho
1.0M    /var/spool
40M    /var/tmp
22K    /var/yp
10.0K   /var/games
14M    /var/stuff
1.3G    /var/squid
4.0K    /var/ucd-snmp
131M    /var/wwwspace
2.2M    /var/drweb
2.1G    /var/CommuniGate
18M    /var/CGPparser
2.5M    /var/drweb-4.31.4
4.8M    /var/drweb-4.32.2
3.5M    /var/clamav
20M    /var/spamassassin
3.8G    /var/

squid падает, Communigate - работает нормально.
lsof, sockstat, fstat - ничего плохого не показывают.
что это может быть?

  Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

 Оглавление

Индекс форумов | Темы | Пред. тема | След. тема
Сообщения по теме

1. "дисковый объем ползет в минус ;(" 
Сообщение от allez Искать по авторуВ закладки(ok) on 23-Июн-05, 15:29  (MSK)
Так вы вывод df покажите.
  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

2. "дисковый объем ползет в минус ;(" 
Сообщение от else emailИскать по авторуВ закладки(ok) on 23-Июн-05, 15:32  (MSK)
>Так вы вывод df покажите.


У сквида кэш можно безболезненно перенести куда-нибудь в home. Пусть там и растет сколько надо

  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

3. "дисковый объем ползет в минус ;(" 
Сообщение от schtazen emailИскать по авторуВ закладки(ok) on 23-Июн-05, 15:41  (MSK)
>ns[/var]# uname -a
>FreeBSD ns.tdntmk.ru 4.7-RELEASE FreeBSD 4.7-RELEASE #0: Tue Sep 30 21:56:16 MSD 2003
>    noc@ns.company.ru:/usr/src/sys/compile/2003_14_05 i386
>
>ns[/var]# du -s -h /var/
>3.8G    /var/
>ns[/var]# du -d 1 -h /var/
>2.0K    /var/account
>6.0K    /var/at
> 12K    /var/backups
>4.0K    /var/crash
>8.0K    /var/cron
>2.2M    /var/db
>2.0K    /var/empty
>2.0K    /var/heimdal
> 73M    /var/log
> 58K    /var/mail
>4.0K    /var/msgs
>2.0K    /var/preserve
> 98K    /var/run
>2.0K    /var/rwho
>1.0M    /var/spool
> 40M    /var/tmp
> 22K    /var/yp
>10.0K   /var/games
> 14M    /var/stuff
>1.3G    /var/squid
>4.0K    /var/ucd-snmp
>131M    /var/wwwspace
>2.2M    /var/drweb
>2.1G    /var/CommuniGate
> 18M    /var/CGPparser
>2.5M    /var/drweb-4.31.4
>4.8M    /var/drweb-4.32.2
>3.5M    /var/clamav
> 20M    /var/spamassassin
>3.8G    /var/
>
>squid падает, Communigate - работает нормально.
>lsof, sockstat, fstat - ничего плохого не показывают.
>что это может быть?

до перезагрузки
ns[/var/CommuniGate/SystemLogs]# df -h
Filesystem      Size   Used  Avail Capacity  Mounted on
/dev/amrd0s1a   3.9G   2.1G   1.5G    58%    /
/dev/amrd1s1e    17G   8.5G   6.9G    55%    /bckup
/dev/amrd0s1e    12G    11G -652.7M   106%    /var
procfs          4.0K   4.0K     0B   100%    /proc

Лечиться - перезагрузка... Но это не правильно, т.к. я не могу понять причину.
Filesystem      Size   Used  Avail Capacity  Mounted on
/dev/amrd0s1a   3.9G   2.1G   1.5G    59%    /
/dev/amrd1s1e    17G   7.6G   7.8G    49%    /bckup
/dev/amrd0s1e    12G   3.1G   7.7G    29%    /var
procfs          4.0K   4.0K     0B   100%    /proc
Больше всего удивляет расхождение показаний du и df.

  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

4. "дисковый объем ползет в минус ;(" 
Сообщение от allez Искать по авторуВ закладки(ok) on 23-Июн-05, 15:45  (MSK)
>Лечиться - перезагрузка... Но это не правильно, т.к. я не могу понять
>причину.

Ну да, правильнее будет прогнать fsck на отмонтированных разделах диска.

  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

6. "дисковый объем ползет в минус ;(" 
Сообщение от schtazen emailИскать по авторуВ закладки(ok) on 23-Июн-05, 16:14  (MSK)
>>Лечиться - перезагрузка... Но это не правильно, т.к. я не могу понять
>>причину.
>
>Ну да, правильнее будет прогнать fsck на отмонтированных разделах диска.


Как отнесется система к отмонтированному /var ? можно, конечно ссылку символическую сделать, сменить точку монтирования, переместить информациюю (только ее перемещять некуда - засада), но у меня по времени простоя критично, а перезагрузка 3-4 минуты...
можно пройтись fsck по примонтированному разделу с активной работой? прямого утверждения, что нельзя я в мане не вычитал... но сделать не рискнул.

В том-то и дело, что я просто перезагрузил систему (reboot'ом) а не по питанию - все файловые системы были отмонтированы и помечены как clean.
Может это быть баг в ядре 4.7 в ufs?
случается переодично, раньше раз в неделю, последний раз - 2 месяца держался.
Причем место сжирается с катастрафической скоростью, т.е. примерно за 2-3 часа 8 гигабайт. такого нет ни почтового траффика, ни интернет траффика.

Сдается мне здесь проблемы с UFS :(

  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

17. "дисковый объем ползет в минус ;(" 
Сообщение от lynx Искать по авторуВ закладки(??) on 24-Июн-05, 12:43  (MSK)
>Сдается мне здесь проблемы с UFS :(
вряд ли...

была вчера та же проблема. полностью забился var.
удалил логов мег на 200, но это пространство забилось чем-то буквально за пол минуты. удалил еще - так же моментально забилось. после перезагрузки нормально.

Slack 10, 2.4.31


  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

5. "дисковый объем ползет в минус ;(" 
Сообщение от gr Искать по авторуВ закладки on 23-Июн-05, 15:53  (MSK)
>>ns[/var]# uname -a
>>FreeBSD ns.tdntmk.ru 4.7-RELEASE FreeBSD 4.7-RELEASE #0: Tue Sep 30 21:56:16 MSD 2003
>>    noc@ns.company.ru:/usr/src/sys/compile/2003_14_05 i386
>>
>>ns[/var]# du -s -h /var/
>>3.8G    /var/
>>ns[/var]# du -d 1 -h /var/
>>2.0K    /var/account
>>6.0K    /var/at
>> 12K    /var/backups
>>4.0K    /var/crash
>>8.0K    /var/cron
>>2.2M    /var/db
>>2.0K    /var/empty
>>2.0K    /var/heimdal
>> 73M    /var/log
>> 58K    /var/mail
>>4.0K    /var/msgs
>>2.0K    /var/preserve
>> 98K    /var/run
>>2.0K    /var/rwho
>>1.0M    /var/spool
>> 40M    /var/tmp
>> 22K    /var/yp
>>10.0K   /var/games
>> 14M    /var/stuff
>>1.3G    /var/squid
>>4.0K    /var/ucd-snmp
>>131M    /var/wwwspace
>>2.2M    /var/drweb
>>2.1G    /var/CommuniGate
>> 18M    /var/CGPparser
>>2.5M    /var/drweb-4.31.4
>>4.8M    /var/drweb-4.32.2
>>3.5M    /var/clamav
>> 20M    /var/spamassassin
>>3.8G    /var/
>>
>>squid падает, Communigate - работает нормально.
>>lsof, sockstat, fstat - ничего плохого не показывают.
>>что это может быть?
>
>до перезагрузки
>ns[/var/CommuniGate/SystemLogs]# df -h
>Filesystem      Size   Used  Avail
>Capacity  Mounted on
>/dev/amrd0s1a   3.9G   2.1G   1.5G  
> 58%    /
>/dev/amrd1s1e    17G   8.5G   6.9G  
>  55%    /bckup
>/dev/amrd0s1e    12G    11G -652.7M  
>106%    /var
>procfs          4.0K  
> 4.0K     0B   100%  
>  /proc
>
>Лечиться - перезагрузка... Но это не правильно, т.к. я не могу понять
>причину.
>Filesystem      Size   Used  Avail
>Capacity  Mounted on
>/dev/amrd0s1a   3.9G   2.1G   1.5G  
> 59%    /
>/dev/amrd1s1e    17G   7.6G   7.8G  
>  49%    /bckup
>/dev/amrd0s1e    12G   3.1G   7.7G  
>  29%    /var
>procfs          4.0K  
> 4.0K     0B   100%  
>  /proc
> Больше всего удивляет расхождение показаний du и df.


классика..

У тебя в удаленный файл что-то продолжает писать. Скорее всего ротация логов неправильно настроена.

  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

7. "дисковый объем ползет в минус ;(" 
Сообщение от schtazen emailИскать по авторуВ закладки(ok) on 23-Июн-05, 16:19  (MSK)
>>>ns[/var]# uname -a
>>>FreeBSD ns.tdntmk.ru 4.7-RELEASE FreeBSD 4.7-RELEASE #0: Tue Sep 30 21:56:16 MSD 2003
>>>    noc@ns.company.ru:/usr/src/sys/compile/2003_14_05 i386
>>>
>>>ns[/var]# du -s -h /var/
>>>3.8G    /var/
>>>ns[/var]# du -d 1 -h /var/
>>>2.0K    /var/account
>>>6.0K    /var/at
>>> 12K    /var/backups
>>>4.0K    /var/crash
>>>8.0K    /var/cron
>>>2.2M    /var/db
>>>2.0K    /var/empty
>>>2.0K    /var/heimdal
>>> 73M    /var/log
>>> 58K    /var/mail
>>>4.0K    /var/msgs
>>>2.0K    /var/preserve
>>> 98K    /var/run
>>>2.0K    /var/rwho
>>>1.0M    /var/spool
>>> 40M    /var/tmp
>>> 22K    /var/yp
>>>10.0K   /var/games
>>> 14M    /var/stuff
>>>1.3G    /var/squid
>>>4.0K    /var/ucd-snmp
>>>131M    /var/wwwspace
>>>2.2M    /var/drweb
>>>2.1G    /var/CommuniGate
>>> 18M    /var/CGPparser
>>>2.5M    /var/drweb-4.31.4
>>>4.8M    /var/drweb-4.32.2
>>>3.5M    /var/clamav
>>> 20M    /var/spamassassin
>>>3.8G    /var/
>>>
>>>squid падает, Communigate - работает нормально.
>>>lsof, sockstat, fstat - ничего плохого не показывают.
>>>что это может быть?
>>
>>до перезагрузки
>>ns[/var/CommuniGate/SystemLogs]# df -h
>>Filesystem      Size   Used  Avail
>>Capacity  Mounted on
>>/dev/amrd0s1a   3.9G   2.1G   1.5G  
>> 58%    /
>>/dev/amrd1s1e    17G   8.5G   6.9G  
>>  55%    /bckup
>>/dev/amrd0s1e    12G    11G -652.7M  
>>106%    /var
>>procfs          4.0K  
>> 4.0K     0B   100%  
>>  /proc
>>
>>Лечиться - перезагрузка... Но это не правильно, т.к. я не могу понять
>>причину.
>>Filesystem      Size   Used  Avail
>>Capacity  Mounted on
>>/dev/amrd0s1a   3.9G   2.1G   1.5G  
>> 59%    /
>>/dev/amrd1s1e    17G   7.6G   7.8G  
>>  49%    /bckup
>>/dev/amrd0s1e    12G   3.1G   7.7G  
>>  29%    /var
>>procfs          4.0K  
>> 4.0K     0B   100%  
>>  /proc
>> Больше всего удивляет расхождение показаний du и df.
>
>
>классика..
>
>У тебя в удаленный файл что-то продолжает писать. Скорее всего ротация логов
>неправильно настроена.
Если система позволяет писать в удаленный файл - то это большая дыра в работе файловой системы.
Есть ротация логов newsyslog, настроена на многих подобных (по процессам) серверах - никаких проблем не вызывает.
Проверю еще раз.


  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

8. "дисковый объем ползет в минус ;(" 
Сообщение от anton emailИскать по авторуВ закладки(??) on 23-Июн-05, 16:46  (MSK)
Покажи ls -l /var/log
Да случаем sarg не стоит? Если стоит как часто отчёты делает?
  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

9. "дисковый объем ползет в минус ;(" 
Сообщение от schtazen emailИскать по авторуВ закладки(ok) on 23-Июн-05, 16:54  (MSK)
-rw-r--r--   1 root  wheel         935 Feb 17 10:59 CGP_log_parser.log
-rw-------   1 root  wheel     5207130 Jun 23 16:48 all.log
-rw-------   1 root  wheel      891369 Jun 23 00:00 all.log.0.gz
-rw-------   1 root  wheel     1040358 Jun 22 00:00 all.log.1.gz
-rw-------   1 root  wheel     1881819 Jun 21 00:00 all.log.2.gz
-rw-------   1 root  wheel      674963 Jun 20 00:00 all.log.3.gz
-rw-------   1 root  wheel      608321 Jun 19 00:00 all.log.4.gz
-rw-------   1 root  wheel     1715199 Jun 18 00:00 all.log.5.gz
-rw-------   1 root  wheel     2351226 Jun 17 00:00 all.log.6.gz
-rw-------   1 root  wheel     2509163 Jun 16 00:00 all.log.7.gz
-rw-------   1 root  wheel         317 Feb 24 11:25 ap-process-server.log
-rw-------   1 root  wheel       10448 Jun 23 16:35 auth.log
-rw-------   1 root  wheel       12499 Jun 23 14:00 auth.log.0.gz
-rw-------   1 root  wheel       12537 Jun 22 03:00 auth.log.1.gz
-rw-------   1 root  wheel       21025 Jun 19 17:00 auth.log.2.gz
-rw-------   1 root  wheel       31088 Jun 18 19:00 auth.log.3.gz
-rw-------   1 root  wheel       12868 Jun 16 14:00 auth.log.4.gz
-rw-------   1 root  wheel       14109 Jun 14 21:00 auth.log.5.gz
-rw-------   1 root  wheel       17252 Jun 13 21:00 auth.log.6.gz
-rw-------   1 root  wheel       21987 Jun 11 07:00 auth.log.7.gz
-rw-------   1 root  wheel          57 Jun 23 00:01 cgpav-sa.log
-rw-------   1 root  wheel         100 Jun 23 00:01 cgpav-sa.log.0.gz
-rw-------   1 root  wheel         100 Jun 22 00:01 cgpav-sa.log.1.gz
-rw-------   1 root  wheel         100 Jun 21 00:01 cgpav-sa.log.2.gz
-rw-------   1 root  wheel         101 Jun 20 00:01 cgpav-sa.log.3.gz
-rw-------   1 root  wheel         100 Jun 19 00:01 cgpav-sa.log.4.gz
-rw-------   1 root  wheel         100 Jun 18 00:01 cgpav-sa.log.5.gz
-rw-------   1 root  wheel         100 Jun 17 00:01 cgpav-sa.log.6.gz
-rw-------   1 root  wheel          99 Jun 16 00:01 cgpav-sa.log.7.gz
-rw-------   1 root  wheel       60102 Jun 23 15:55 console.log
-rw-------   1 root  wheel       17654 Jun 22 13:00 console.log.0.gz
-rw-------   1 root  wheel       17630 Jun 15 17:00 console.log.1.gz
-rw-------   1 root  wheel       18479 Jun  7 13:00 console.log.2.gz
-rw-------   1 root  wheel       17331 Jun  1 10:00 console.log.3.gz
-rw-------   1 root  wheel       15566 May 26 09:00 console.log.4.gz
-rw-------   1 root  wheel       17419 May 21 23:00 console.log.5.gz
-rw-------   1 root  wheel       53520 Jun 23 16:45 cron
-rw-------   1 root  wheel        8634 Jun 22 13:00 cron.0.gz
-rw-------   1 root  wheel        8543 Jun 20 11:00 cron.1.gz
-rw-------   1 root  wheel        8473 Jun 18 09:00 cron.2.gz
-rw-------   1 root  wheel        8584 Jun 16 08:00 cron.3.gz
-rw-------   1 root  wheel          91 Jun 23 03:01 dmesg.today
-rw-------   1 root  wheel         101 Jun 22 03:02 dmesg.yesterday
-rw-------   1 root  wheel      551376 Jun 23 16:48 drweb-cgp-4.32.2.log
-rw-------   1 root  wheel       74332 Jun 23 00:00 drweb-cgp-4.32.2.log.0.gz
-rw-------   1 root  wheel       72226 Jun 22 00:00 drweb-cgp-4.32.2.log.1.gz
-rw-------   1 root  wheel       80012 Jun 21 00:00 drweb-cgp-4.32.2.log.2.gz
-rw-------   1 root  wheel       18315 Jun 20 00:00 drweb-cgp-4.32.2.log.3.gz
-rw-------   1 root  wheel       21202 Jun 19 00:00 drweb-cgp-4.32.2.log.4.gz
-rw-------   1 root  wheel       69399 Jun 18 00:00 drweb-cgp-4.32.2.log.5.gz
-rw-------   1 root  wheel       69644 Jun 17 00:00 drweb-cgp-4.32.2.log.6.gz
-rw-------   1 root  wheel       68196 Jun 16 00:00 drweb-cgp-4.32.2.log.7.gz
-rw-r--r--   1 root  wheel    27513797 Jun 23 16:21 httpd-access.log
-rw-r--r--   1 root  wheel      311605 Jun 23 15:38 httpd-error.log
drwxr-xr-x  25 root  wheel        1024 Feb 22 16:39 ipfm
-rw-------   1 root  wheel        1318 Jun 23 03:01 ipfw.today
-rw-------   1 root  wheel        1318 Jun 22 03:02 ipfw.yesterday
-rw-r--r--   1 root  wheel       28084 Jun 23 15:42 lastlog
-rw-r--r--   1 root  wheel           0 Oct  9  2002 lpd-errs
-rw-r-----   1 root  wheel      954475 Jun 23 16:43 maillog
-rw-r-----   1 root  wheel      144749 Jun 23 00:00 maillog.0.gz
-rw-r-----   1 root  wheel      199395 Jun 22 00:00 maillog.1.gz
-rw-r-----   1 root  wheel      481254 Jun 21 00:00 maillog.2.gz
-rw-r-----   1 root  wheel      222227 Jun 20 00:00 maillog.3.gz
-rw-r-----   1 root  wheel      183158 Jun 19 00:00 maillog.4.gz
-rw-r-----   1 root  wheel      495713 Jun 18 00:00 maillog.5.gz
-rw-r-----   1 root  wheel      643329 Jun 17 00:00 maillog.6.gz
-rw-r-----   1 root  wheel      733989 Jun 16 00:00 maillog.7.gz
-rw-r--r--   1 root  wheel         285 Jun 23 16:32 messages
-rw-r--r--   1 root  wheel       21173 Jun 23 16:00 messages.0.gz
-rw-r--r--   1 root  wheel       17075 Jun 17 03:00 messages.3.gz
-rw-r--r--   1 root  wheel       18681 Jun  8 15:00 messages.4.gz
-rw-r--r--   1 root  wheel       17709 Jun  2 10:00 messages.5.gz
-rw-------   1 root  wheel         116 Oct  1  2003 mount.today
-rw-r--r--   1 root  wheel        1796 Oct  8  2003 netams.log
-rw-r-----   1 root  network         0 Oct  9  2002 ppp.log
-rw-------   1 root  wheel        3627 Jun 23 16:32 security
-rw-------   1 root  wheel       10451 Jun 23 16:00 security.0.gz
-rw-------   1 root  wheel        9396 Apr 21 10:00 security.1.gz
-rw-------   1 root  wheel       10777 Feb 11 17:00 security.2.gz
-rw-------   1 root  wheel        9309 Feb  9  2004 security.3.gz
-rw-r-----   1 root  wheel           0 Jun 23 10:00 sendmail.st
-rw-r-----   1 root  wheel           0 Jun 23 09:00 sendmail.st.0
-rw-r-----   1 root  wheel           0 Jun 16 10:00 sendmail.st.1
-rw-r-----   1 root  wheel           0 May 18 19:00 sendmail.st.10
-rw-r-----   1 root  wheel           0 Jun 16 09:00 sendmail.st.2
-rw-r-----   1 root  wheel           0 Jun  9 10:00 sendmail.st.3
-rw-r-----   1 root  wheel           0 Jun  9 09:00 sendmail.st.4
-rw-r-----   1 root  wheel           0 Jun  2 10:00 sendmail.st.5
-rw-r-----   1 root  wheel           0 Jun  2 09:00 sendmail.st.6
-rw-r-----   1 root  wheel           0 May 26 10:00 sendmail.st.7
-rw-r-----   1 root  wheel           0 May 26 09:00 sendmail.st.8
-rw-r-----   1 root  wheel           0 May 18 20:00 sendmail.st.9
-rw-------   1 root  wheel        5470 Apr 22 03:01 setuid.today
-rw-------   1 root  wheel        5406 Jan 26 03:01 setuid.yesterday
-rw-r-----   1 root  network         0 Oct  9  2002 slip.log
-rw-r--r--   1 root  wheel         863 Jun 23 16:46 snmpd.log
-rw-r--r--   1 root  wheel          97 Jun 23 00:00 snmpd.log.0.gz
-rw-r--r--   1 root  wheel          97 Jun 22 00:00 snmpd.log.1.gz
-rw-r--r--   1 root  wheel          97 Jun 21 00:00 snmpd.log.2.gz
-rw-r--r--   1 root  wheel          98 Jun 20 00:00 snmpd.log.3.gz
-rw-r--r--   1 root  wheel          97 Jun 19 00:00 snmpd.log.4.gz
-rw-r--r--   1 root  wheel          97 Jun 18 00:00 snmpd.log.5.gz
-rw-r--r--   1 root  wheel          97 Jun 17 00:00 snmpd.log.6.gz
-rw-r--r--   1 root  wheel          96 Jun 16 00:00 snmpd.log.7.gz
-rw-------   1 root  wheel      809762 Jun 23 16:23 spamd.log
-rw-------   1 root  wheel      107672 Jun 23 00:01 spamd.log.0.gz
-rw-------   1 root  wheel      161746 Jun 22 00:01 spamd.log.1.gz
-rw-------   1 root  wheel      438648 Jun 21 00:01 spamd.log.2.gz
-rw-------   1 root  wheel      187976 Jun 20 00:01 spamd.log.3.gz
-rw-------   1 root  wheel      151625 Jun 19 00:01 spamd.log.4.gz
-rw-------   1 root  wheel      452315 Jun 18 00:01 spamd.log.5.gz
-rw-------   1 root  wheel      596965 Jun 17 00:01 spamd.log.6.gz
-rw-------   1 root  wheel      679248 Jun 16 00:01 spamd.log.7.gz
-rw-------   1 root  wheel     3374547 Jun 23 16:33 spamtest-cgpro-lite.log
-rw-------   1 root  wheel      460430 Jun 23 00:01 spamtest-cgpro-lite.log.0.gz
-rw-------   1 root  wheel      552734 Jun 22 00:01 spamtest-cgpro-lite.log.1.gz
-rw-------   1 root  wheel      822390 Jun 21 00:01 spamtest-cgpro-lite.log.2.gz
-rw-------   1 root  wheel      225004 Jun 20 00:01 spamtest-cgpro-lite.log.3.gz
-rw-------   1 root  wheel      200747 Jun 19 00:01 spamtest-cgpro-lite.log.4.gz
-rw-------   1 root  wheel      689551 Jun 18 00:01 spamtest-cgpro-lite.log.5.gz
-rw-------   1 root  wheel     1008905 Jun 17 00:01 spamtest-cgpro-lite.log.6.gz
-rw-------   1 root  wheel     1056432 Jun 16 00:01 spamtest-cgpro-lite.log.7.gz
-rw-------   1 root  wheel         327 Oct 25  2004 userlog
-rw-r--r--   1 root  wheel        1804 Jun 23 15:42 wtmp
-rw-r--r--   1 root  wheel        1936 May 31 18:35 wtmp.0
-rw-r--r--   1 root  wheel        3124 Apr 30 13:33 wtmp.1
-rw-r--r--   1 root  wheel        1760 Mar 31 10:48 wtmp.2
-rw-r--r--   1 root  wheel        1408 Feb 28 20:06 wtmp.3
  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

10. "дисковый объем ползет в минус ;(" 
Сообщение от anton emailИскать по авторуВ закладки(??) on 23-Июн-05, 17:04  (MSK)
А логи squid-а где? дай ls -l той директории.
Так а sarg или иной анализатор логов имееш?
К слову ротацию бы не мешало настроить
>-rw-r--r--   1 root  wheel    27513797 Jun 23 16:21 httpd-access.log
>-rw-r--r--   1 root  wheel      311605 Jun 23 15:38 httpd-error.log
  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

11. "дисковый объем ползет в минус ;(" 
Сообщение от AMDmi3 Искать по авторуВ закладки on 23-Июн-05, 17:07  (MSK)
>Если система позволяет писать в удаленный файл - то это большая дыра
>в работе файловой системы.
А, ну да, где же ты все это время был! PR напиши :)

Если действительно кто-то пишет в удаленный файл, поставь lsof, и сделай  lsof | grep /var | sort -g +6. Сразу все увидишь.

  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

13. "дисковый объем ползет в минус ;(" 
Сообщение от lavr emailИскать по авторуВ закладки on 23-Июн-05, 18:48  (MSK)
>>Если система позволяет писать в удаленный файл - то это большая дыра
>>в работе файловой системы.
>А, ну да, где же ты все это время был! PR напиши
>:)
>
>Если действительно кто-то пишет в удаленный файл, поставь lsof, и сделай  
>lsof | grep /var | sort -g +6. Сразу все увидишь.
>

просто некоторые БЕЗ МОЗГОВ пытаются некоторые операции выполнять, ну
например такие как rm , а демоны при этом работают и работают и работают...
я у себя однажды уже разъяснял действия по зачистке при переполнениях

  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

15. "дисковый объем ползет в минус ;(" 
Сообщение от schtazen emailИскать по авторуВ закладки(??) on 24-Июн-05, 02:09  (MSK)
>>>Если система позволяет писать в удаленный файл - то это большая дыра
>>>в работе файловой системы.
>>А, ну да, где же ты все это время был! PR напиши
>>:)
>>
>>Если действительно кто-то пишет в удаленный файл, поставь lsof, и сделай  
>>lsof | grep /var | sort -g +6. Сразу все увидишь.
>>
>
>просто некоторые БЕЗ МОЗГОВ пытаются некоторые операции выполнять, ну
>например такие как rm , а демоны при этом работают и работают
>и работают...
>я у себя однажды уже разъяснял действия по зачистке при переполнениях
Довайте проясним ситуацию по поводу выполнения команд.
На серверах у меня есть только два вида ротации логов: newsyslog и встроенные механизмы в самих программах (например CommuniGate или squid -k rotate).
ДРУГИХ самописных скриптов, программ - НЕТ. Руками я ничего не удаляю, ибо не хватит времени удалять логи на всех серверах руками. Изначально я все настраиваю на полную автономию. Даже если сервера выключается по питанию, вмешательства они, как правило, не требуют.
Логи ВСЕХ демонов оборачиваются ЕЖЕДНЕВНО. Другими словами, 60 дней логи оборачивались НОРМАЛЬНО, а на 61 вдруг какой-то демон стал писать в удаленный файл? и за 3-4 часа ЗАПОЛНЯЕТСЯ ПРОСТРАНСТВО, КОТОРОЕ БЕЗ РОТАЦИИ ЛОГОВ ЗОПОЛНЯЛОСЬ БЫ 5 МЕСЯЦЕВ!!!! Откуда ПИШЕТЬСЯ в УДАЛЕННЫЙ файл 8 гигабайт логов?
  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

16. "дисковый объем ползет в минус ;(" 
Сообщение от anton emailИскать по авторуВ закладки(??) on 24-Июн-05, 11:07  (MSK)
Вообщем у меня было:
Скрипт запускал sarg и затем делал операции с лог файлами и файлами отчётов squid-а . Однажны он не успел вовремя это сделать, в итоге запустилась вторая копия данного скрипта. В результате сисуация описанная выше.

Из моего опыта наиболее часто такя ситуация, в результате некоретной работы скриптов статистики и ротаци логов.  

  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

12. "дисковый объем ползет в минус ;(" 
Сообщение от gr Искать по авторуВ закладки on 23-Июн-05, 17:08  (MSK)

>>У тебя в удаленный файл что-то продолжает писать. Скорее всего ротация логов
>>неправильно настроена.
>Если система позволяет писать в удаленный файл - то это большая дыра
>в работе файловой системы.

Именно так и есть. Но запретить руту что-либо, в частности удаление файлов, на системе со стандартной для униха системой прав мы тоже не имеем права:)

>Есть ротация логов newsyslog, настроена на многих подобных (по процессам) серверах -
>никаких проблем не вызывает.
>Проверю еще раз.

посмотри внимательнее на drweb и spam-test - возможно что-то именно там.

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

  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

14. "дисковый объем ползет в минус ;(" 
Сообщение от U Искать по авторуВ закладки on 23-Июн-05, 18:58  (MSK)
а вот это как понимать ?

# df -h
Filesystem    Size   Used  Avail Capacity  Mounted on
/dev/ad2s1a   242M    56M   167M    25%    /
devfs         1.0K   1.0K     0B   100%    /dev

/dev/ad2s1f   4.7G   4.7G -380.7M   109%    /home

/dev/ad2s1e   989M  10.0K   910M     0%    /tmp
/dev/ad2s1g    17G   1.7G    14G    11%    /usr
/dev/ad2s1d   9.5G   133M   8.6G     1%    /var
/dev/ad3s1d    14G   7.3G   5.8G    56%    /squid

FreeBSD 5.2.1

  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

18. "дисковый объем ползет в минус ;(" 
Сообщение от lynx Искать по авторуВ закладки(??) on 24-Июн-05, 12:53  (MSK)
>хотя ситуация, повторюсь - классическая.

уважаемый gr, не могли бы вы по подробнее объяснить как это происходит?

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


  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

19. "дисковый объем ползет в минус ;(" 
Сообщение от gr Искать по авторуВ закладки on 24-Июн-05, 16:18  (MSK)
>>хотя ситуация, повторюсь - классическая.
>
>уважаемый gr, не могли бы вы по подробнее объяснить как это происходит?
>
>
>я с этим сталкивался несколько раз на рабочей станции с линухом, вроде
>это как-то связанно с vmware тогда было, правда остается непонятным почему
>свободное место пропадает с такой большой скоростью...

следующим образом:

1.стартует процесс
2.открывает лог файл для записи и начинает туда писать
3.кто-то (что-то) удаляет файл (открытый для записи)

теперь вот что происходит: физически файл удаляется как только закрываются _все_ его дескрипторы, а поскольку в него кто-т о пишет - система исправно пишет данные на диск, НО в листингах и по команде du например - имя этого файла не показывает.

Отсюда разница в показаниях df и du - du такой файл просто не учитывает.

посему - если файл удален (неверно ротирован или очищен) - то надо передернуть процесс (или послать HUP) чтобы он переоткрыл файлы логов. Вот в этом момент - физически удалятся данные "невидимого" файла.

Отсюда кстати и рекомендация очищать логи примерно так:

echo -n > /var/log/logfile

Добавлю еще что как правило быстрорастущие логи у mysql query log - многие забывают это отключать. (вместо этого есть binlog если надо)

  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

20. "дисковый объем ползет в минус ;(" 
Сообщение от gr Искать по авторуВ закладки on 24-Июн-05, 16:26  (MSK)
>>>хотя ситуация, повторюсь - классическая.
>>
>>уважаемый gr, не могли бы вы по подробнее объяснить как это происходит?
>>
>>
>>я с этим сталкивался несколько раз на рабочей станции с линухом, вроде
>>это как-то связанно с vmware тогда было, правда остается непонятным почему
>>свободное место пропадает с такой большой скоростью...
>
>следующим образом:
>
>1.стартует процесс
>2.открывает лог файл для записи и начинает туда писать
>3.кто-то (что-то) удаляет файл (открытый для записи)
>
>теперь вот что происходит: физически файл удаляется как только закрываются _все_ его
>дескрипторы, а поскольку в него кто-т о пишет - система исправно
>пишет данные на диск, НО в листингах и по команде du
>например - имя этого файла не показывает.
>
>Отсюда разница в показаниях df и du - du такой файл просто
>не учитывает.
>
>посему - если файл удален (неверно ротирован или очищен) - то надо
>передернуть процесс (или послать HUP) чтобы он переоткрыл файлы логов. Вот
>в этом момент - физически удалятся данные "невидимого" файла.
>
>Отсюда кстати и рекомендация очищать логи примерно так:
>
>echo -n > /var/log/logfile
>
>Добавлю еще что как правило быстрорастущие логи у mysql query log -
>многие забывают это отключать. (вместо этого есть binlog если надо)


Добавлю еще - почему это так спроектировано имхо (read не возвращает ошибку записи) - например ты в одной консоли

less README

и кто-то README удалил. Так вот - ты будешь читать README вверх-вниз сколько угодно, пока его не закроешь- и тогда он "удалится окончательно". Имхо разумно:)

  Удалить Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх


Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ]
Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2021 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру