LinuxMint.com.ru

Задолбался уже, крыша кипит. Опять поймал странную проблему, с которой даже гугл походу не знаком. Но может кто-нить здесь что-то подобное видел (или подобные симптомы не обязательно у transmission), так что - любые комментарии приветствуются. Ситуация:

Установлен debian 9 без gui на нем установлен transmission-daemon. Демон стартует, торренты качаются... но не долго. Через совершенно рандомное время - от нескольких минут до нескольких часов, без видимых закономерностей, без любых записей в логах, transmission как бы зависает. Перестает общаться с сетью, к нему становится невозможно подключится через transgui или зайти на веб-интерфейс. В списке процессов продолжает висеть. Единственное решение - перестартовать сервис: service transmission-daemon restart - после этого опять какое-то время все нормально, и потом опять виснет.
- Процесс не уходит в zombi мод.
- Ставил версии 2.92 (штатная), 2.94 - от testing, 2.82 от jessie, и даже 2.52 от debian 7 который там стоял раньше - и с которым никогда таких проблем не было. Поведение во всех случаях идентично. (!)
- Ядра за все время поиска решения были 4.9 (штатное), 4.15 и 4.16 из бекпортов. Не влияет.
- Файловая система машины btrfs на root, но специально выносил все связанное с transmission-daemon (/var/lib/transmission-daemon с конфигами и базой хешей, и разумеется сам каталог для файлов) на другой раздел, где исключительно ext4. Да и на другой машине с минтом у меня именно btrfs, где transmission не имеет ничего против. Т.е. сама fs, как таковая, вроде бы не при чем.

Единственное что дает хоть какой-то намек о происходящем - когда демон "зависает" - htop показывает что один из процессов transmission находится в т.н. delay состоянии: Остальные в обычном. В процессе работы, если понаблюдать за ним через htop это состояние периодически мелькает и так, но быстро пропадает.

Что это может быть за хрень, и как бы ее дальше отловить - чтобы хотя бы выяснить, что именно происходит? Идеи приветствуются. Бесит в первую очередь именно то, что в логах пусто. Причем пусто даже если поднять уровень детализации до "отладки" - пишет дофига разного касающегося пиров, сидов, файлов... Но ничего необычного, и даже без закономерностей. Просто в определенное время новых записей нету - вот и все.

У меня подобная фигня была на роутере, но причина нашлась быстро - transmission-daemon выжирал весь RAM, после подключения swap всё рассосалось. Псле того как отказался от роутера как торрентбокса, ни разу не наблюдал зависаний.

Посмотрел htop - тоже самое, что и у тебя
И логов тоже нет

Стоит на Orange PI под U16.04

... не так , но нечто подобное видел... решал ограничением скорости загрузки ( без ограничений все вставало намертво )...

Интересно, но на этой машине 2gb памяти + 2gb своп. Причем своп практически пустой всегда (в моменты зависаний процесса тоже). Однако чует интуиция - это может иметь отношение к делу. Слышал я как-то, что systemd (через которую стартует transmission-daemon в девятке) может контролировать расход памяти демонами. Надо покопать в эту сторону и посмотреть сколько памяти будет хотеть процесс в момент очередного зависания... И можно попробовать еще запустить без systemd, от обычного юзера напрямую...

qwertKI писал(а): ↑

10 июн 2018, 14:05

не так , но нечто подобное видел... решал ограничением скорости загрузки

Тоже для диагностики пойдет. А уровень выставленных ограничений не подскажите? Как точку отсчета?

Нифига.

1. Запустил вообще напрямую от обычного юзера без всякого systemd, как простое приложение - "transmission-daemon -f --log-info" виснет. На экране нифига интересного - а я уж надеялся что-то увидеть, думал, может systemd что-то "глотает". Нет.
2. Обрезал входящие/исходящие до 20 мегабит, и максимум пиров - до 70. Виснет. (На прошлой системе спокойно работало на лимитах в 60 мегабит и 200 пиров).

upd: Если в консоли где оно запускалось и повисло нажать Ctrl+C - вываливается с "ошибкой сегментирования". Походу, проблема не в недостатке памяти - памяти свободно было еще 1.5 гига в этот момент - смотрел специально. где-то косяк посерьезнее...

upd: Переставил еще раз на 2.94 (testing) - эта segfault не выдает, корректно завершается при нажатии Ctrl+C даже если находится в "повисшем" состоянии. Но все равно виснет... Что-же ей надо то, собаке...

В общем - спасибо тем кто отозвался. Сколько раз убеждаюсь, что написать вопрос в интернет - сродни шаманскому ритуалу. Даже если не помогут прямо - ответ или выход из ситуации после этого находится. Конкретно здесь - мысль поиграть с ограничениями была ключевой.

В общем, настоящую причину не нашел, но работать стабильно все-таки заставил. Уже сутки не виснет. Помогло:
1. Поставить версию 2.94 из testing.
2. Выставить размер дискового буфера в 10mb. До того у меня обычно стояло 100-300mb, чтобы диск поменьше дергало. Для старой системы это было очень ощутимо.

Сейчас посмотрел - хотя буфер и маленький, но ведет оно себя так же как раньше с большим - диск особо не теребит за каждый килобайт. Вот только я одного так и не понял - если что-то поменяли в самой программе, какого черта старая версия тоже висла с большим буфером? Она ведь именно с таким и работала на старой системе. Походу, тут какое-то комплексное взаимодействие идет с ядром или системными библиотеками. Т.к. в дебиане 7 который раньше стоял, и где версия 2.52 с большим буфером нормально работала ядро было 3.2, а здесь минимальное на котором пробовал 4.9.

Попутно накопал вот такую интересную темку в багтрекере, и походу, она как-то с этим связана... Во всяком случае про потребление памяти актуально - но память оно ест не основную, а под буферы - в htop, top, и free этого просто так не видно.
https://github.com/transmission/transmission/issues/313
Правда скомпилированная статически 2.92 у меня все равно висла с большим буффером. Но гораздо реже. Так что хоть и связано, но не напрямую...

!	Сообщение из: Dja
	Поскольку речь идет о программе, а не о специфике ОСи - переношу в работу с сетью. slant писал(а): ↑ 13 июн 2018, 16:26 подозреваю, что это как раз таки специфика debian 9. Т.к. тады ой.

Апдейт: нифига оно не исправилось. Просто, как выяснилось, раздача завершилась по лимиту розданного и нагрузка упала. Совпадение. Включил обратно - все так же виснет. :(

Поигрался с разными лимитами еще - как выяснилось, некую корреляцию дает количество одновременных раздач, или пиров в них... Чем больше - тем быстрее виснет. Закачка вроде бы не влияет.
Ограничил через systemd доступную сервису память до 400Мб - вроде бы стало стабильнее (причем не зависимо от настройки дискового кеша). Но все равно фигня творится. В общем - походу придется тупо watchdog на сервис вешать. Чтоб рестартил при зависаниях. Тупо, а что делать? Другого клиента с доступом через RPC я как-то не знаю... Просто веб-интерфейс не всегда удобен.

slant писал(а): ↑

11 июн 2018, 14:32

Поскольку речь идет о программе, а не о специфике ОСи - переношу в работу с сетью.

Сильно подозреваю, что это как раз таки специфика debian 9. Т.к. в минте есть тот-же самый transmission 2.84 (который я тоже пробовал в дебиане с идентичными явлениями) и ничего подобного с ним в минте не происходит.

slant, а не смотрел Deluge, rTorrent, QLiveBittorrent?

Я бы посоветовал вам использовать rtorrent. Один раз настроил, и забыл.

Мне нужен headless демон к которому может цепляться программа-клиент с другой машины. Просто web-интерфейс несколько не то.

Помню, мне Deluge ещё советовали, как альтернативу

Посмотрел сейчас Deluge - спасибо, что напомнили о нем. Я его когда-то очень давно смотрел - было что-то "перспективное в будущем". Будущее наступило однако. Теперь у него есть и работа в режиме демона, и отдельные GUI, и дофига настроек под любой случай - то что нужно. Буду переходить.

Да, переехал окончательно. Deluge сейчас по возможностям ничем не уступает, а то и превосходит уже. Полноценный клиент-сервер с демоном, клиентами на любой вкус, и веб интерфесом - причем шикарным. Настройка посложнее, но оно того определенно стоит. Спасибо за пинок в нужную сторону.

Надо будет тоже попробовать, а то я в своё время не внял совету

Всем привет.
Зарегался, специально, чтобы подтвердить такую же ситуацию и выход из нее, может кому-то еще поможет.
И так transmission-daemon на домашнем сервере, 100 лет работал норм, сеть гигабит, качало 300-400 Мбит(пров ограничивал).
И тут провайдер порадовал, подсыпал скорости до 800.
transmission-daemon начал мертво виснуть после 400Мбит.
Долго тестил, чтоб понять, что дело именно в скорости. Пробовал разные версии, в докере и без, разные кеш-буферы, настройки, разные тазики даже. Результат всегда один.
Наткнулся на этот топик, поставил deluge - все ок. Спасибо!
Клиент под андроид - transdroid

Мужики, а кто-нибудь решил эту проблему или все на Deluge перешли? А если перешли, то как решили вопрос с переносом базы с торентами?