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 i386ns[/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 - ничего плохого не показывают.
что это может быть?
Так вы вывод df покажите.
>Так вы вывод df покажите.
У сквида кэш можно безболезненно перенести куда-нибудь в home. Пусть там и растет сколько надо
>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.
>Лечиться - перезагрузка... Но это не правильно, т.к. я не могу понять
>причину.Ну да, правильнее будет прогнать fsck на отмонтированных разделах диска.
>>Лечиться - перезагрузка... Но это не правильно, т.к. я не могу понять
>>причину.
>
>Ну да, правильнее будет прогнать fsck на отмонтированных разделах диска.
Как отнесется система к отмонтированному /var ? можно, конечно ссылку символическую сделать, сменить точку монтирования, переместить информациюю (только ее перемещять некуда - засада), но у меня по времени простоя критично, а перезагрузка 3-4 минуты...
можно пройтись fsck по примонтированному разделу с активной работой? прямого утверждения, что нельзя я в мане не вычитал... но сделать не рискнул.В том-то и дело, что я просто перезагрузил систему (reboot'ом) а не по питанию - все файловые системы были отмонтированы и помечены как clean.
Может это быть баг в ядре 4.7 в ufs?
случается переодично, раньше раз в неделю, последний раз - 2 месяца держался.
Причем место сжирается с катастрафической скоростью, т.е. примерно за 2-3 часа 8 гигабайт. такого нет ни почтового траффика, ни интернет траффика.Сдается мне здесь проблемы с UFS :(
>Сдается мне здесь проблемы с UFS :(
вряд ли...была вчера та же проблема. полностью забился var.
удалил логов мег на 200, но это пространство забилось чем-то буквально за пол минуты. удалил еще - так же моментально забилось. после перезагрузки нормально.Slack 10, 2.4.31
>>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.
классика..У тебя в удаленный файл что-то продолжает писать. Скорее всего ротация логов неправильно настроена.
>>>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, настроена на многих подобных (по процессам) серверах - никаких проблем не вызывает.
Проверю еще раз.
Покажи ls -l /var/log
Да случаем sarg не стоит? Если стоит как часто отчёты делает?
-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
А логи 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
>Если система позволяет писать в удаленный файл - то это большая дыра
>в работе файловой системы.
А, ну да, где же ты все это время был! PR напиши :)Если действительно кто-то пишет в удаленный файл, поставь lsof, и сделай lsof | grep /var | sort -g +6. Сразу все увидишь.
>>Если система позволяет писать в удаленный файл - то это большая дыра
>>в работе файловой системы.
>А, ну да, где же ты все это время был! PR напиши
>:)
>
>Если действительно кто-то пишет в удаленный файл, поставь lsof, и сделай
>lsof | grep /var | sort -g +6. Сразу все увидишь.
>просто некоторые БЕЗ МОЗГОВ пытаются некоторые операции выполнять, ну
например такие как rm , а демоны при этом работают и работают и работают...
я у себя однажды уже разъяснял действия по зачистке при переполнениях
>>>Если система позволяет писать в удаленный файл - то это большая дыра
>>>в работе файловой системы.
>>А, ну да, где же ты все это время был! PR напиши
>>:)
>>
>>Если действительно кто-то пишет в удаленный файл, поставь lsof, и сделай
>>lsof | grep /var | sort -g +6. Сразу все увидишь.
>>
>
>просто некоторые БЕЗ МОЗГОВ пытаются некоторые операции выполнять, ну
>например такие как rm , а демоны при этом работают и работают
>и работают...
>я у себя однажды уже разъяснял действия по зачистке при переполнениях
Довайте проясним ситуацию по поводу выполнения команд.
На серверах у меня есть только два вида ротации логов: newsyslog и встроенные механизмы в самих программах (например CommuniGate или squid -k rotate).
ДРУГИХ самописных скриптов, программ - НЕТ. Руками я ничего не удаляю, ибо не хватит времени удалять логи на всех серверах руками. Изначально я все настраиваю на полную автономию. Даже если сервера выключается по питанию, вмешательства они, как правило, не требуют.
Логи ВСЕХ демонов оборачиваются ЕЖЕДНЕВНО. Другими словами, 60 дней логи оборачивались НОРМАЛЬНО, а на 61 вдруг какой-то демон стал писать в удаленный файл? и за 3-4 часа ЗАПОЛНЯЕТСЯ ПРОСТРАНСТВО, КОТОРОЕ БЕЗ РОТАЦИИ ЛОГОВ ЗОПОЛНЯЛОСЬ БЫ 5 МЕСЯЦЕВ!!!! Откуда ПИШЕТЬСЯ в УДАЛЕННЫЙ файл 8 гигабайт логов?
Вообщем у меня было:
Скрипт запускал sarg и затем делал операции с лог файлами и файлами отчётов squid-а . Однажны он не успел вовремя это сделать, в итоге запустилась вторая копия данного скрипта. В результате сисуация описанная выше.Из моего опыта наиболее часто такя ситуация, в результате некоретной работы скриптов статистики и ротаци логов.
>>У тебя в удаленный файл что-то продолжает писать. Скорее всего ротация логов
>>неправильно настроена.
>Если система позволяет писать в удаленный файл - то это большая дыра
>в работе файловой системы.Именно так и есть. Но запретить руту что-либо, в частности удаление файлов, на системе со стандартной для униха системой прав мы тоже не имеем права:)
>Есть ротация логов newsyslog, настроена на многих подобных (по процессам) серверах -
>никаких проблем не вызывает.
>Проверю еще раз.посмотри внимательнее на drweb и spam-test - возможно что-то именно там.
Не забудь что это все-таки предположение - я , конечно, могу и ошибаться,
хотя ситуация, повторюсь - классическая.
а вот это как понимать ?# 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% /squidFreeBSD 5.2.1
>хотя ситуация, повторюсь - классическая.уважаемый gr, не могли бы вы по подробнее объяснить как это происходит?
я с этим сталкивался несколько раз на рабочей станции с линухом, вроде это как-то связанно с vmware тогда было, правда остается непонятным почему свободное место пропадает с такой большой скоростью...
>>хотя ситуация, повторюсь - классическая.
>
>уважаемый gr, не могли бы вы по подробнее объяснить как это происходит?
>
>
>я с этим сталкивался несколько раз на рабочей станции с линухом, вроде
>это как-то связанно с vmware тогда было, правда остается непонятным почему
>свободное место пропадает с такой большой скоростью...следующим образом:
1.стартует процесс
2.открывает лог файл для записи и начинает туда писать
3.кто-то (что-то) удаляет файл (открытый для записи)теперь вот что происходит: физически файл удаляется как только закрываются _все_ его дескрипторы, а поскольку в него кто-т о пишет - система исправно пишет данные на диск, НО в листингах и по команде du например - имя этого файла не показывает.
Отсюда разница в показаниях df и du - du такой файл просто не учитывает.
посему - если файл удален (неверно ротирован или очищен) - то надо передернуть процесс (или послать HUP) чтобы он переоткрыл файлы логов. Вот в этом момент - физически удалятся данные "невидимого" файла.
Отсюда кстати и рекомендация очищать логи примерно так:
echo -n > /var/log/logfile
Добавлю еще что как правило быстрорастущие логи у mysql query log - многие забывают это отключать. (вместо этого есть binlog если надо)
>>>хотя ситуация, повторюсь - классическая.
>>
>>уважаемый gr, не могли бы вы по подробнее объяснить как это происходит?
>>
>>
>>я с этим сталкивался несколько раз на рабочей станции с линухом, вроде
>>это как-то связанно с vmware тогда было, правда остается непонятным почему
>>свободное место пропадает с такой большой скоростью...
>
>следующим образом:
>
>1.стартует процесс
>2.открывает лог файл для записи и начинает туда писать
>3.кто-то (что-то) удаляет файл (открытый для записи)
>
>теперь вот что происходит: физически файл удаляется как только закрываются _все_ его
>дескрипторы, а поскольку в него кто-т о пишет - система исправно
>пишет данные на диск, НО в листингах и по команде du
>например - имя этого файла не показывает.
>
>Отсюда разница в показаниях df и du - du такой файл просто
>не учитывает.
>
>посему - если файл удален (неверно ротирован или очищен) - то надо
>передернуть процесс (или послать HUP) чтобы он переоткрыл файлы логов. Вот
>в этом момент - физически удалятся данные "невидимого" файла.
>
>Отсюда кстати и рекомендация очищать логи примерно так:
>
>echo -n > /var/log/logfile
>
>Добавлю еще что как правило быстрорастущие логи у mysql query log -
>многие забывают это отключать. (вместо этого есть binlog если надо)
Добавлю еще - почему это так спроектировано имхо (read не возвращает ошибку записи) - например ты в одной консолиless README
и кто-то README удалил. Так вот - ты будешь читать README вверх-вниз сколько угодно, пока его не закроешь- и тогда он "удалится окончательно". Имхо разумно:)