форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение		[Проследить за развитием треда]

"дисковый объем ползет в минус ;("
Сообщение от schtazen (??) 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 (ok) on 23-Июн-05, 15:32  (MSK)
	>Так вы вывод df покажите. У сквида кэш можно безболезненно перенести куда-нибудь в home. Пусть там и растет сколько надо
	Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

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

	9. "дисковый объем ползет в минус ;("
	Сообщение от schtazen (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 (??) 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 on 23-Июн-05, 18:48  (MSK)
	>>Если система позволяет писать в удаленный файл - то это большая дыра >>в работе файловой системы. >А, ну да, где же ты все это время был! PR напиши >:) > >Если действительно кто-то пишет в удаленный файл, поставь lsof, и сделай   >lsof | grep /var | sort -g +6. Сразу все увидишь. > просто некоторые БЕЗ МОЗГОВ пытаются некоторые операции выполнять, ну например такие как rm , а демоны при этом работают и работают и работают... я у себя однажды уже разъяснял действия по зачистке при переполнениях
	Удалить	Правка | Высказать мнение | Ответить | Рекомендовать в FAQ | Cообщить модератору | Наверх

	15. "дисковый объем ползет в минус ;("
	Сообщение от schtazen (??) 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 (??) 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 ]

Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.