просто настройте logrotate и не мучайтесь с большим размером логов

вы не могли бы мне дать полезну ссылку по настройке или темку?
если под рукой нет ничего - пойду гуглить.

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/cciss/c0d0p2     20161204  13424420   5712644  71% /

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

- перебросить с одного (свободно более 20 ГБ и используется редко) раздела на вот этот корневой хотя бы еще 5Гб. хотелось бы это сделать безболезненно и без потери информации.
- настроить утилитку (помоему logrotate, не уверен), которая автоматически сможет подчищать эти же messages*

можно в этой теме продолжать или лучше создать отдельную тему с интересующим меня вопросом?

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

вот посоветовали создать символическую ссылку var/log на другой раздел и не менять размер дисков. как быть?

1.5Гб каждый.. messages1, messages2, messages3..

куда вам такой объем? и почему он в корневом каталоге у вас лежат?

наверное они сюда как-то попали. смело чистить каталог tmp?

[root@serverx root]# du -sH * | sort -nr
839MB   test

Это что у Вас в таком размере?

И tmp 5 гигов

тогда еще так
cd /
du -sH * | sort -nr
вывод может быть большой, весь выкладывать не надо, можно бдет понять что у вас занимает такой большой объем, еще  как вариант сделать проверку диска с помощью fsck

du -sH * | sort -nr запустил, пока что думает.
update:
[root@serverx /]# du -sH * | sort -nr
du: `proc/1889/fd/3': No such file or directory
943MB   proc
842MB   root
812MB   var
447kB   dev
418GB   mnt
196MB   home
159MB   lib
54kB    tftpboot
20MB    etc
17kB    lost+found
13MB    sbin
12MB    boot
8.2kB   hdd1
5.9GB   shared
5.8GB   tmp
5.5MB   bin
4.1kB   misc
4.1kB   initrd
4.1kB   1.txt
3.1GB   usr
1.2GB   opt

du: `proc/1889/fd/3': No such file or directory - 'это не этот глюк? логи были где-то по 1.5Гб каждый.. messages1, messages2, messages3..

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

дело в том, что я далеко не опытный и если она "ляжет" мне понадобится очень много времени, чтобы ее восстановить

п.с. где посмотреть задействован ли режим восстановления при загрузке и как его включить?

Filesystem            Size  Used Avail Use% Mounted on
/dev/cciss/c0d0p2      20G   19G  148M 100% /

[root@serverx root]# du -sH * | sort -nr
839MB   test
33kB    install.log
8.2kB   install.log.syslog
4.1kB   putse
4.1kB   anaconda-ks.cfg

Сегодня в очередной раз это сделал (удалял через WinSCP, но уверен но помоему держал зажатым клавишу Shift).

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/cciss/c0d0p2     20161204  18968336    168728 100% /
удалил логи /var/log (messages 1; messages 2; messages 3.. - самые объемные)

после этого свободное место в разделе не появилось. искал в этой директории каталог .trash, нет такого. уже даже сервер перезагрузил, так и осталось 100%.
Linux Red Hat, файловая система type ext3

помогите пожайлуста, куда могли улететь эти логи? или что я мог натворить зажав клавишу Shift и нажав Del?