LINUX.ORG.RU

Проверьте воспроизводимость бага в трансмиссии

 ,


0

1

Столкнулся с проблемой при установке лимита открытых файлов для transmission-daemon, проверял на версиях с 2.33 по 2.51 из дебиановских репозиториев.

Суть проблемы: после добавления торрента в клиент с дефолтным конфигом лимит числа открытых файлов сбрасывается на стандартные 1024. Я не уверен, виновата ли сама трансмиссия, или кто-то другой в моей системе.

Для проверки нужны:

  • transmission-daemon
  • transmission-cli
  • права рута

Шаги для воспроизведения (все выполняется от рута):

1. Устанавливаем лимит числа открытых файлов больше 1024:

# ulimit -n 10009
2. Запускаем трансмиссию, с указанием в качестве конфига несуществующей папки (чтобы получить дефолтные настройки):
# /usr/bin/transmission-daemon --config-dir /tmp/transmission-root
3. Смотрим, какие ограничения применились к процессу:
# grep open /proc/`pidof transmission-daemon`/limits 
Max open files            10009                10009                files  
4. Добавляем в трансмиссию заранее заготовленный торрент-файл (любой):
# transmission-remote --add test.torrent
localhost:9091/transmission/rpc/ responded: "success"
5. Снова проверяем лимиты для процесса:
# grep open /proc/`pidof transmission-daemon`/limits
Max open files            1024                 10009                files  

Софт-лимит сбросился на 1024!

Указывайте, пожалуйста, версию трансмиссии и сведения о системе. А я пока попробую в чистом debootstrap-нутом чруте воспроизвести.Воспроизвелось в чистой системе с трансмиссией 2.51

★★★

С помощью посетителей debian@c.j.ru было выяснено, что этот лимит в 1024 открытых файла едва ли не захардкоден там:

/* transmission-2.52/libtransmission/fdlimit.c:515 */
static void
ensureSessionFdInfoExists( tr_session * session )
{
    assert( tr_isSession( session ) );

    if( session->fdInfo == NULL )
    {
        struct rlimit limit;
        struct tr_fdInfo * i;
        const int FILE_CACHE_SIZE = 32;

        /* Create the local file cache */
        i = tr_new0( struct tr_fdInfo, 1 );
        fileset_construct( &i->fileset, FILE_CACHE_SIZE );
        session->fdInfo = i;

        /* set the open-file limit to the largest safe size wrt FD_SETSIZE */
        if( !getrlimit( RLIMIT_NOFILE, &limit ) )
        {
            const int old_limit = (int) limit.rlim_cur;
            const int new_limit = MIN( limit.rlim_max, FD_SETSIZE );
            if( new_limit != old_limit )
            {
                limit.rlim_cur = new_limit;
                setrlimit( RLIMIT_NOFILE, &limit );
                getrlimit( RLIMIT_NOFILE, &limit );
                tr_inf( "Changed open file limit from %d to %d", old_limit, (int)limit.rlim_cur );
            }
        }
    }
}

FD_SETSIZE определена где-то в системных хедерах как 1024.

/me закомментировал секцию про open-file limit и довольный ушел пообедать. Если вы вдруг имеете доступ к irc или багтрекеру трансмиссии, потратьте пять минут и зарепортите баг. Хотя, может, и я не поленюсь поискать незабаненные прокси и отправлю сам чуть позже :)

si0 ★★★ ()
Ответ на: комментарий от si0

Подтверждаю; нагулил некоторое время назад, что это как-то связано с ограничениями libevent, или того как оно применяется в трансмиссии; как-то так.

anonymous ()
Ответ на: комментарий от anonymous

https://trac.transmissionbt.com/ticket/4164

Я вот такое нагуглил. Якобы libcurl падала и роняла трансмиссию.

Сутки с закомментированными строками она проработала нормально, а потом я перетащил файлопомойку в rtorrent и сейчас занят игранием с его конфигом вместо опций configure у всяких там курлов :)

si0 ★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.