Система пишет следущую ошибку:
Jan 10:52:29 domen /kernel :pid 98 (mail.local), uid 0 on /: file system fullВ чем засада??? Почту не оплучает и как исправить...на переполнение чего ругаеца где подчистить!!! ХЭЛП! горю =( Всем заранее спасибо за ответы!
>Система пишет следущую ошибку:
>Jan 10:52:29 domen /kernel :pid 98 (mail.local), uid 0 on /: file
>system full
>
>В чем засада??? Почту не оплучает и как исправить...на переполнение чего ругаеца
>где подчистить!!! ХЭЛП! горю =( Всем заранее спасибо за ответы!
дык / говорит переполнен, корень тобишь.
>дык / говорит переполнен, корень тобишь.как переполнен? Df смотрю все ОК... места достаточно...Что посоветуете?
Предположение: для пользователя, от которого выполняется fetchmail, заданы квоты (man quota ?).
>Предположение: для пользователя, от которого выполняется fetchmail, заданы квоты (man quota ?).
>Хммм.. квоты на кого? ниче же не менял.. все также рутом захожу...а на юзеров квот не стоит.(я думаю) все заходят как заходили.. просто с определенным интервалом пишет эту надпись.. интервал 30 мин. ровно. Есть еще какие-нибудь советы? Заранее благодарен.
>Хммм.. квоты на кого? ниче же не менял.. все также рутом захожу...Не, посмотри, от имени какого пользователя исполняется fetchmail, квоты могут быть у него. А /var расположена на отдельной партиции или там же, где и / ? Прямо после этого сообщения посмотри, что скажет df относительно / и /var.
Ещё на ум приходит root jail (chroot), но с этим подходом я совсем не знаком.
Феч исполняется от рута, / и /var располагаются на раздельных партициях. df показывает что / на 51% забит а var ваще на 8% тоесть место есть... Попробывал поменять пару параметров.. посмотрим что быдел.. Напишу о результатах позже.. Спасиб за помощь!!!!
трабл.Начались именно такие приколы / -full /usr -full и так далее на каждой ФС с которой пытался взаимодействовать какой либо сервис - апач, мта и так далее. С многочисленными предупреждениями: *XXXX socket (No buffer space available).
Начались они после:
sysctl -w net.inet.tcp.sendspace=262144И продолжались, пока:
#/sbin/sysctl -w net.inet.tcp.delayed_ack=0 # - типа нафиг.
#/sbin/sysctl -w net.inet.tcp.sendspace=262144
#/sbin/sysctl -w net.inet.tcp.recvspace=131072
#/sbin/sysctl -w net.local.stream.sendspace=131072
#/sbin/sysctl -w net.local.stream.recvspace=131072/sbin/sysctl -w net.inet.tcp.sendspace=65535
/sbin/sysctl -w net.inet.tcp.recvspace=65535
/sbin/sysctl -w net.local.stream.sendspace=65535
/sbin/sysctl -w net.local.stream.recvspace=65535cat sysctl.conf
kern.ipc.somaxconn=8192
net.inet.tcp.rfc1323=0
net.inet.ip.ttl=1500
kern.maxfiles=65535
kern.ipc.shm_use_phys=1
kern.ipc.shmmax=134217728
kern.ipc.shmall=32278
kern.ipc.nmbclusters=16384
kern.ipc.maxsockets=65535Итого: есть отличный путь не налетать - в sysctl.conf записывать только те значения, которые тщательно протестированы, а эксперименты исполнять
через скрипт ( со /sbin/sysctl -w bla-bla-bla), чтобы после удаленной перезагрузки эти сомнительные значения исчезали, как дурной сон.Иначе придется ехать.
Итак, удостоверяешься, что ты пока еще можешь исполнить shutdown -r now.
Держа палец на крючке, меняешь kern.*, net.* etc. Если что не так -
shutdown -r now.
Надо осторожно менять эти собблазнительные установки ядра.
>Надо осторожно менять эти собблазнительные установки ядра.
Кароч немного не понял.. помойму проблемы разные у нас были... Фишка в том что как и писал выше дрянь начилась хрензнает с чего... вродь ниче не менялось.. все работало как часы..и тут нате. фигня продолжает раздражать экран каждые пол часа по надписи.. ясно дело что как-то с фечмэйлом связано.. но вот как.. где косяк спрятался... или я его в тупую не вижу либо... Вообщем, вопрос открыт!!!
У вас что-то кончилось.Изучите ядро, что менялось при пересборке от умолчания?
Изучите содержимое sysctl.conf и loader.confПод "разгон" Фри в ядро очень часто ставятся слегонца противоречащие друг другу значения.