Здравствуйте, Robert.
# du -h /var | sort -nr | head -n 25
976k/var/db/mysql/mysql
892k/var/mail/freeline.in.ua/luda
888M/var/log/radius/radacct/10.11.19.50
858M/var/crash
840k/var/mail/freeline.in.ua/luda/cur
836k/var/db/firebird/help
608k/var/spool
564k
On 05/11/2012 09:32, Eugen Konkov wrote:
Здравствуйте, Robert.
# du -h /var | sort -nr | head -n 25
976k/var/db/mysql/mysql
892k/var/mail/freeline.in.ua/luda
888M/var/log/radius/radacct/10.11.19.50
858M/var/crash
840k/var/mail/freeline.in.ua/luda/cur
836k
Здравствуйте, Vincent.
Вы писали 5 ноября 2012 г., 12:38:47:
VH On 05/11/2012 09:32, Eugen Konkov wrote:
Здравствуйте, Robert.
# du -h /var | sort -nr | head -n 25
976k/var/db/mysql/mysql
892k/var/mail/freeline.in.ua/luda
888M/var/log/radius/radacct/10.11.19.50
858M
Eugen Konkov kes-...@yandex.ru writes:
Здравствуйте, Vincent.
Вы писали 5 ноября 2012 г., 12:38:47:
VH Its possible that a process is holding open an unlinked file (some
VH processes do this for tmp files as they are automatically deleted if the
VH program exit, I believe mysql does it for
how to find which process take space?
root@newflux:/var/log # cd /var
root@newflux:/var #
root@newflux:/var #
root@newflux:/var #
root@newflux:/var #
root@newflux:/var #
root@newflux:/var # df -h
Filesystem SizeUsed Avail Capacity Mounted on
/dev/ada0s1a 2G455M1.3G
On 11/2/2012 2:05 PM, Eugen Konkov wrote:
858M./crash
1.3G./db
3.7G./log
Cleanup old coredumps in /crash. Ensure /etc/newsyslog.conf captures all
of your big logfiles in /var/log. Also consider moving whatever is large
in /var/db elsewhere.
Bryan
Здравствуйте, Bryan.
Вы писали 2 ноября 2012 г., 21:09:49:
BD On 11/2/2012 2:05 PM, Eugen Konkov wrote:
858M./crash
1.3G./db
3.7G./log
BD Cleanup old coredumps in /crash. Ensure /etc/newsyslog.conf captures all
BD of your big logfiles in /var/log. Also consider moving
On 11/2/2012 2:20 PM, Eugen Konkov wrote:
Здравствуйте, Bryan.
Вы писали 2 ноября 2012 г., 21:09:49:
BD On 11/2/2012 2:05 PM, Eugen Konkov wrote:
858M./crash
1.3G./db
3.7G./log
BD Cleanup old coredumps in /crash. Ensure /etc/newsyslog.conf captures all
BD of your big
On Fri, 2 Nov 2012 21:20:51 +0200
Eugen Konkov kes-...@yandex.ru wrote:
Notice df -h
/dev/ada0s1d 30G 23G3.7G87%/var
and notice du -h -d 1
6.2G
I have only 6.2G are occupied by files
where 18Gb of disk space?
Probably in a deleted file still open by some
Eugen Konkov wrote:
how to find which process take space?
You might want to look at fstat and lsof. fstat is in system while lsof is
an add-on third party port. Keep in mind that when you do find the space you
are looking for it will be held 'open' as an open file in the file system as
Здравствуйте, Bryan.
Вы писали 2 ноября 2012 г., 21:27:15:
BD On 11/2/2012 2:20 PM, Eugen Konkov wrote:
Здравствуйте, Bryan.
Вы писали 2 ноября 2012 г., 21:09:49:
BD On 11/2/2012 2:05 PM, Eugen Konkov wrote:
858M./crash
1.3G./db
3.7G./log
BD Cleanup old coredumps in
Looks like /var/log has most of it.
If you're running X, check for a huge Xorg.0.log.
I had this problem as a result of a radeon graphics card that would get into
some kind of reinitialization loop.
In any case, look at the files in /var/log
On 11/02/12 13:05, Eugen Konkov wrote:
how to find
Gary Aitken writes:
Looks like /var/log has most of it.
If you're running X, check for a huge Xorg.0.log.
I had this problem as a result of a radeon graphics card that would get into
some kind of reinitialization loop.
In any case, look at the files in /var/log
A way to check
13 matches
Mail list logo