Transmission-daemon приводит к DOS

dangerr

В общем симптомы такие: Есть компьютер с FreeBSD 7.2. Я на нём запускаю transmission-daemon, маунчу по ssh директории на свой десктоп, также на нём висит openvpn и nat, чтобы иметь доступ к внутренней сети организации, где он стоит. В последнее время, когда я запускаю transmission и подключаюсь к десятку раздач гигов на 50 в общей сложности, через некоторое время комп пингуется, но по ssh на него зайти не удаётся: пишу ssh <ip> жму enter, курсор переходит на следующую строчку, но в ней уже ничего не появляется даже через 10 часов.
При этом ещё какое-то время могут полноценно фунционировать sshfs маунты и vpn с natом, но потом и они отпадают.
Однажды это случилось, когда я сидел по ssh на ту машину. При этом там можно было печатать и стирать символы, но запуск df -h привёл к такой же пустой строке без вывода.
Если логиниться локально, то на имя пользователя получаю запрос о пароле, а после его ввода - снова новая пустая строка. Так что лечилось это только резетом, заходом в single-user-mode и закоменчиванием строки transmission-daemon_enable="YES" в /etc/rc.conf. Если этого не сделать, то он через минуту снова уходит в такое же состояние.
В системном логе ничего подозрительного не наблюдается.
Судя по всему у меня не создаются новые процессы или даже потоки. Почему не понятно. Кто-нибудь может подсказать как это продиагностировать и как лечить?

Sharp

Для начала попробуй в отдельной консоли запустить top и посмотреть в каком состоянии будут процессы в момент твоего подвисания.
Также можешь попробовать понажимать Ctrl+T после запуска чего-либо — хотя бы увидишь в каком состоянии у тебя все залипает.

dangerr

вот top в тот момент, когда ssh-маунты и vpn с натом ещё функционриуют.
Вроде ничего подозрительного не происходит.

dangerr

Ну что это за ппц: я смог выйти из топа, набрать su, ввести пароль, набрать reboot, нажать enter и понять, что в ребут никто уходить не смотря на это не собирается! :mad:

yroslavasako

Linux - самая надёжная в мире система, и не ты один это замечаешь. Я вот мечтаю давно уже настроить нормальный MAC для него

dangerr

Да я давно уже порываюсь туда gentoo поставить. Но времени нет всё снова настраивать.
Да и откуда мне знать в чём тут может быть проблема? Может железо барахлит, оно там старовато. Может сам трансмишн, в общем нет гарантий, что с генту не будет того же самого.
КЖ. Вообще там фря исторически сложилась. Я когда её туда ставил, ещё про генту не слышал. На десктопе даже с ХР на 2003 винду не перешёл, хотя после неё ещё была 2008 винда, а потом только гента. А фря всё это время там и стояла.
Даже жалко как-то её :) столько лет верой и правдой служит.

Sharp

Что-то не к добру, что у тебя процессы находятся в состоянии pfault.
Как варианты: у тебя плохая память (попробуй погонять memtest проблемы с жестким диском (или вообще, или в том месте, где у тебя swap расположен).
Еще не исключаю, что это какая-то бага freebsd, попробуй обновиться.

dangerr

я обновлялся с 7.1-RELEASE до 7.2-RELEASE после появления этой проблемы - ничего не поменялось... предлагаешь обновиться с последнего релиза до STABLE или CURRENT?
Кстати да, хорошая идея погонять memtest и mhdd, пожалуй так и сделаю.
А что значит pfault?

Dimon89

А что значит pfault?
page fault?

Sharp

Читаем файлик /usr/src/sys/vm/vm_page.c

/*
* vm_waitpfault: (also see VM_WAITPFAULT macro)
*
* Block until free pages are available for allocation
* - Called only in vm_fault so that processes page faulting
* can be easily tracked.
* - Sleeps at a lower priority than vm_wait so that vm_waiting
* processes will be able to grab memory first. Do not change
* this balance without careful testing first.
*/

В переводе на русский: процесс блокируется пока не появятся свободные страницы для выделения.
Оставить комментарий
Имя или ник:
Комментарий: