Почему после закрытия торрент-клиента Transmission в Debian 12 остаются процессы в памяти, которые используют процессор, и как это исправить

Введение: Проблема оставшихся процессов Transmission

Администратор удаленного сервера или опытный пользователь Linux часто сталкиваются с неприятной ситуацией: после того, как закрыли торрент-клиент Transmission, его процессы продолжают висеть в памяти, потребляя ресурсы процессора. Эта проблема особенно распространена на системах с Debian 12, где встречается сочетание факторов, приводящих к оставлению процессов в памяти и истощению системных ресурсов. Данная статья детально разберет причины этого явления, предоставит инструменты диагностики и предложит несколько методов решения проблемы.

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

Понимание природы оставшихся процессов Transmission

Типы оставшихся процессов

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

Зомби-процессы (Zombie Processes) представляют собой процессы, которые завершили свое выполнение, но их родительский процесс еще не считал статус выхода дочернего процесса. В результате процесс остается в таблице процессов ядра, хотя он полностью неживой. Эта ситуация возникает, когда родительский процесс не вызывает системные функции wait() или waitpid() для сбора статуса выхода потомка. Зомби-процессы не потребляют практически никаких ресурсов процессора, но занимают место в таблице процессов.

Фоновые процессы (Background Processes) полностью живы и продолжают работу после завершения родительского процесса. Они могут получить новый родительский процесс (обычно init с PID 1 в системах без systemd или systemd в современных системах), и система будет тратить реальные ресурсы на их выполнение. Таких процессов нельзя просто удалить из памяти игнорированием, они требуют активного завершения через системный вызов.

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

Физиология проблемы в контексте Debian 12

В случае Transmission на Debian 12 причины оставления процессов в памяти кроются в нескольких аспектах архитектуры приложения и взаимодействию с systemd. Debian 12 активно использует systemd для управления сервисами, и именно здесь часто возникает конфликт между ожиданиями systemd и поведением Transmission.

Основные причины проблемы с Transmission на Debian 12

Проблемы с интеграцией systemd и notificaton

Одной из ключевых причин является конфликт между типом сервиса systemd и способом, которым Transmission себя ведет. В современных версиях Transmission (особенно версии 4.0 и выше) применяется тип сервиса Type=notify, что означает, что приложение должно отправить сигнал systemd о готовности к работе используя функцию sd_notify().

Однако многие сборки Transmission не скомпилированы с поддержкой systemd, потому что при компиляции не была установлена библиотека libsystemd-dev. Это может произойти при установке из исходных кодов или при использовании пакетов из старых источников.

Когда systemd ожидает уведомления от сервиса с типом notify, но приложение его не отправляет, systemd по истечении времени ожидания (обычно 90 секунд) принудительно завершает процесс через отправку сигнала SIGTERM, а затем SIGKILL. Однако некоторые дочерние процессы Transmission могут остаться в памяти. Это происходит, потому что Transmission использует многопроцессный подход и создает дочерние процессы для различных операций.

Архитектурные проблемы многопроцессной модели

Transmission разработан с использованием многопроцессной архитектуры, где основной демон может создавать дочерние процессы для выполнения определенных задач. При резком завершении родительского процесса systemd не имеет информации о дочерних процессах в достаточной полноте, чтобы завершить их корректно.

Это особенно проблематично, когда Transmission работает с большим количеством торрентов. Каждый торрент может требовать отдельной обработки, и при наличии тысяч торрентов в очереди создается целая иерархия процессов. Если родительский процесс завершается неожиданно, эта иерархия может остаться в памяти.

Утечки памяти в зависимостях

Transmission зависит от нескольких крупных библиотек, которые сами могут содержать утечки памяти. В частности, в версии 3.00 была обнаружена серьезная утечка памяти, связанная с библиотекой OpenSSL3 и неправильным применением патча, которая пыталась обеспечить совместимость с устаревшими алгоритмами шифрования.

После длительной работы (часто через несколько часов до суток) демон Transmission начинает потреблять всю доступную оперативную память системы, вплоть до десятков гигабайт. На системах с ограниченной памятью это может привести к исчерпанию памяти и крушу ядра Linux.

Утечка памяти в libevent: Библиотека libevent, которую использует Transmission для управления событиями сокетов и таймеров, также содержит известные утечки памяти при определенных условиях. Особенно это касается функции evdns_getaddrinfo() при проблемах с разрешением имен или обработке соединений, которые закрываются ненормально.

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

Проблемы с управлением RPC-соединениями

Демон Transmission использует локальный RPC-сервер для взаимодействия с удаленными клиентами через веб-интерфейс (обычно доступный по адресу http://localhost:9091) или командную строку (утилита transmission-remote).

При большом количестве активных торрентов (тысячи торрентов) или при непрерывном потоке RPC-запросов буферы памяти для этих соединений могут не освобождаться полностью. Каждое соединение требует выделения буферов для приема и отправки данных, и если эти буферы не освобождаются при закрытии соединения, происходит фрагментация памяти.

Проблемы с randomize port и UPnP

Некоторые пользователи отметили, что проблема с утечкой памяти начинается после активации параметра «randomize port on launch» в сочетании с «use port forwarding from my router» в настройках сети Transmission. Это может быть связано с неправильной обработкой соединений с маршрутизатором при запросе UPnP маппирования портов.

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

Проблемы с версиями OpenSSL

В Debian 12 используется OpenSSL 3.0, который имеет серьезные отличия от OpenSSL 1.1. Transmission, при неправильной компиляции против OpenSSL 3.0, может не освобождать структуры данных криптографических контекстов. Это приводит к медленной, но неумолимой утечке памяти при работе с шифрованными соединениями.

Диагностика проблемы: инструменты и команды

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

Определение наличия процессов Transmission

Первый шаг — проверить, действительно ли остались процессы. Используйте команду:

bash ps aux | grep transmission

Эта команда показывает все процессы, содержащие слово «transmission» в своем имени или пути. Однако есть более элегантный способ без самого grep:

bash pgrep -a transmission

Команда pgrep предпочтительнее для скриптов, так как она не захватывает сам процесс grep в результаты. Флаг -a показывает полную командную строку.

Классификация оставшихся процессов

Чтобы определить, являются ли оставшиеся процессы зомби-процессами или живыми фоновыми процессами, используйте:

bash ps -A -ostat,pid,ppid | grep -e '[zZ]'

Если в выводе видны строки с буквой Z в первой колонке (STAT), это зомби-процессы. Живые фоновые процессы будут отмечены другими символами:

• S — спящий процесс (ожидает события)
• R — запущенный процесс (активно использует CPU)
• D — невпрерывающийся сон (ожидает I/O)
• T — остановленный процесс

Более детальная информация о конкретном процессе получается через:

bash ps -p <PID> -o stat,ppid,pid,cmd

где <PID> — это идентификатор интересующего процесса.

Измерение использования памяти и процессора

Для анализа потребления ресурсов конкретным процессом используется:

bash ps -p <PID> -o %cpu,%mem,cmd

Важно помнить, что %cpu в выводе ps показывает среднее использование процессора за все время работы процесса (cputime/realtime), а не текущее мгновенное значение. Для более точного мониторинга текущего использования ресурсов используется интерактивная команда:

bash top -p <PID>

Команда top обновляется в реальном времени (по умолчанию каждые 3 секунды) и показывает текущее мгновенное использование.

Анализ типов памяти процесса

Инструмент smem предоставляет более точную информацию о потреблении памяти процессами, разделяя память на три типа:

bash sudo apt install smem
smem -k -p <PID>

Результат показывает:

• USS (Unique Set Size) — уникальная память, используемая только данным процессом
• PSS (Proportional Set Size) — пропорциональная память, учитывающая разделяемые библиотеки
• RSS (Resident Set Size) — резидентная память, включая разделяемые ресурсы

Уникальная память (USS) показывает именно тот объем оперативной памяти, который используется только данным процессом. Это наиболее точный показатель для обнаружения утечек памяти.

Отслеживание открытых файлов и соединений

Инструмент lsof (list open files) позволяет увидеть все открытые файлы, сокеты и другие файловые дескрипторы, которые держит процесс:

bash lsof -p <PID>

Это полезно для определения того, почему процесс не может завершиться — возможно, он держит открытыми какие-то ресурсы.

Для более специфичной информации о сетевых соединениях используйте:

bash ss -tlnp | grep transmission
netstat -tlnp | grep transmission

Эти команды показывают все TCP соединения, слушающие на портах (флаги -tlnp), и фильтруют результаты только по transmission.

Отслеживание системных вызовов

Команда strace позволяет отследить все системные вызовы, которые делает процесс:

bash strace -p <PID> -e trace=file,process,signal

Это помогает понять, что именно пытается делать «зависший» процесс. Флаг -e trace=file,process,signal ограничивает вывод только системными вызовами, связанными с работой с файлами, процессами и сигналами.

Просмотр журнала systemd

Для проверки того, как systemd управляет сервисом Transmission:

bash journalctl -u transmission-daemon.service -n 50 -f

Флаг -n 50 показывает последние 50 строк, а -f включает режим следования (как tail -f). Это особенно полезно при перезагрузке сервиса для наблюдения в реальном времени за процессом запуска и остановки.

Более детальный вывод статуса сервиса:

bash systemctl status transmission-daemon.service

Эта команда показывает текущее состояние сервиса, последние логи, и потребление ресурсов.

Решение проблемы: пошаговый план действий

Решение 1: Изменение типа сервиса systemd

Самое простое и часто эффективное решение — изменить тип сервиса с notify на simple или forking. Это заставляет systemd не ожидать специального уведомления от Transmission, а просто запускает приложение в режиме foreground.

Отредактируйте файл сервиса командой:

bash sudo systemctl edit transmission-daemon.service

Эта команда откроет редактор с пустым файлом для переопределения параметров сервиса. В открывшемся редакторе убедитесь, что раздел [Service] содержит:

text[Service]
Type=simple
ExecStart=/usr/bin/transmission-daemon -f --log-level=error

Вместо текущих значений:

text[Service]
Type=notify
ExecStart=/usr/bin/transmission-daemon -f --log-level=error

Флаг -f в ExecStart означает, что Transmission будет работать в режиме foreground (не отсоединяясь от терминала), что необходимо для правильной работы с systemd.

Затем перезагрузите systemd и перезагрузите сервис:

bash sudo systemctl daemon-reload
sudo systemctl restart transmission-daemon

Также убедитесь, что в файле не указан ExecStop=/bin/kill -s STOP $MAINPID, что может привести к неправильному завершению процесса. Правильная строка должна быть:

text ExecStop=/bin/kill -s TERM $MAINPID

SIGTERM (сигнал 15) позволяет процессу корректно завершить работу и освободить ресурсы, в то время как SIGSTOP (сигнал 19) просто приостанавливает процесс.

Решение 2: Установка необходимых пакетов для systemd

Если вы хотите сохранить тип notify, но это не работает, попробуйте переустановить Transmission с поддержкой systemd. Сначала установите необходимую библиотеку:

bash sudo apt install libsystemd-dev

Библиотека libsystemd-dev содержит заголовки, необходимые для компиляции приложений с поддержкой systemd уведомлений.

Затем переустановите Transmission:

bash sudo apt remove transmission-daemon
sudo apt update
sudo apt install transmission-daemon

Если вы устанавливали Transmission из исходных кодов, пересоберите его с явным указанием поддержки systemd:

bash cmake -DWITH_SYSTEMD=ON ..
make
sudo make install

Решение 3: Увеличение таймаутов systemd

Если процесс запускается, но очень медленно (при наличии тысяч торрентов это может быть нормально), можно увеличить таймаут:

bash sudo systemctl edit transmission-daemon.service

Добавьте в раздел [Service]:

textTimeoutStartSec=300
TimeoutStopSec=30

TimeoutStartSec=300 устанавливает таймаут в 300 секунд (5 минут) для запуска сервиса. Это полезно, если Transmission требует времени для загрузки конфигурации с большим количеством торрентов.

TimeoutStopSec=30 дает процессу 30 секунд для корректного завершения перед принудительным убиением.

Решение 4: Отключение функций UPnP и port forwarding

Если проблема началась после активации функций UPnP и port forwarding, попробуйте их отключить. Отредактируйте конфигурацию Transmission:

bash sudo nano /var/lib/transmission-daemon/.config/transmission-daemon/settings.json

Найдите и установите следующие параметры:

json"port-forwarding-enabled": false,
"pex-enabled": false,
"random-port": false

• "port-forwarding-enabled": false — отключает UPnP маппирование портов
• "pex-enabled": false — отключает Peer Exchange, который может создавать много соединений
• "random-port": false — отключает изменение порта при каждом запуске

После редактирования перезагрузите демон:

bash sudo systemctl restart transmission-daemon

Решение 5: Очистка оставшихся процессов

Если процессы все же остались в памяти после применения вышеперечисленных методов, их необходимо явно завершить.

Для зомби-процессов сначала найдите родительский процесс:

bash ps -A -ostat,pid,ppid | grep -e '[zZ]'

Из результата возьмите PPID (идентификатор родительского процесса) и отправьте ему сигнал SIGCHLD:

bash kill -s SIGCHLD <PPID>

Однако это не всегда срабатывает, если родитель не обработает сигнал. Более надежный способ — завершить родительский процесс:

bash kill -9 <PPID>

Для живых «зависших» процессов используйте:

bash pkill -9 -f transmission-daemon

Более осторожный вариант с явной проверкой:

bash for pid in $(pgrep -f transmission-daemon); do
    echo "Завершение процесса $pid"
    kill -9 $pid
done

Решение 6: Исправление памяти через редактирование конфигурации

В некоторых случаях предотвращение утечки памяти достигается ограничением глубины буферизации и оптимизацией параметров:

bash sudo nano /var/lib/transmission-daemon/.config/transmission-daemon/settings.json

Примеры полезных параметров:

json"cache-size-mb": 16,
"blocklist-updates-enabled": false,
"script-torrent-done-enabled": false,
"watch-dir-enabled": false,
"peer-limit-global": 500,
"peer-limit-per-torrent": 25

• "cache-size-mb": 16 — максимальный размер буферизованной памяти для дисковых операций. Установите на значение от 4 до 32 МБ в зависимости от вашей системы. Меньшее значение уменьшит использование памяти, но может замедлить скорость записи на диск.
• "blocklist-updates-enabled": false — автоматические обновления списков блокировок требуют больше памяти и могут привести к утечкам
• "script-torrent-done-enabled": false — запуск скриптов при завершении торрентов может привести к утечкам памяти, если скрипты плохо написаны
• "watch-dir-enabled": false — постоянное наблюдение за директорией потребляет ресурсы и может создавать зависшие процессы при проблемах с файловой системой
• "peer-limit-global": 500 — ограничивает максимальное количество одновременных пиров до 500. Это снижает использование памяти при работе с большим количеством торрентов.
• "peer-limit-per-torrent": 25 — ограничивает количество пиров на один торрент

Решение 7: Использование более старой или специально собранной версии

Если проблема с памятью критична, можно вернуться на версию Transmission 3.00 из другого источника (например, из Debian 11). Будьте осторожны, так как старые версии могут иметь проблемы безопасности:

bash sudo apt remove transmission-daemon
sudo apt install -t bullseye transmission-daemon

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

Альтернативно, рассмотрите использование других торрент-клиентов:

• qBittorrent — более современный клиент на базе Qt, часто более стабилен по памяти
• Deluge — Python-based клиент с хорошей масштабируемостью
• rTorrent — минималистичный клиент на основе libtorrent

Решение 8: Автоматическая перезагрузка сервиса

Как временная мера (не решение, а паллиатив), можно настроить автоматическую перезагрузку сервиса при превышении использования памяти. Создайте скрипт /usr/local/bin/check-transmission.sh:

bash#!/bin/bash
max_memory=1000000  # в кб (примерно 1 ГБ)
mem=$(ps aux | grep '[t]ransmission-daemon' | awk '{print $6}' | head -1)

if [ "$mem" -gt "$max_memory" ]; then
    echo "$(date): Transmission использует $mem кб, перезагружаем..." >> /var/log/transmission-check.log
    systemctl restart transmission-daemon
fi

Сделайте скрипт исполняемым:

bash sudo chmod +x /usr/local/bin/check-transmission.sh

Добавьте его в crontab для периодического запуска:

bash sudo crontab -e

И добавьте строку:

text*/5 * * * * /usr/local/bin/check-transmission.sh

Это будет проверять использование памяти каждые 5 минут и перезагружать сервис, если он превышает 1 ГБ.

Дополнительные рекомендации для оптимизации

Оптимизация параметров Transmission

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

В файле settings.json найдите и отредактируйте:

json"peer-limit-global": 1000,
"peer-limit-per-torrent": 50

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

2. Ограничение скорости загрузки/выгрузки по памяти:

json"speed-limit-down-enabled": true,
"speed-limit-down": 100,
"speed-limit-up-enabled": true,
"speed-limit-up": 50

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

3. Отключение функций, требующих много памяти:

json"dht-enabled": false,
"pex-enabled": false,
"lpd-enabled": false,
"idle-seeding-limit-enabled": true,
"idle-seeding-limit": 30

• DHT (Distributed Hash Table) требует дополнительной памяти для отслеживания информации о пирах
• PEX (Peer Exchange) создает много временных структур данных при обмене информацией о пирах
• LPD (Local Peer Discovery) использует многокастинг на локальной сети
• idle-seeding-limit автоматически останавливает сидирование неактивных торрентов после 30 минут

Мониторинг с помощью системных инструментов

Используйте встроенные инструменты мониторинга для отслеживания проблем в реальном времени:

bash watch -n 5 'ps aux | grep transmission | grep -v grep'

Это обновляет информацию каждые 5 секунд.

Для более сложного мониторинга создайте скрипт на Python:

python#!/usr/bin/env python3
import subprocess
import time
from datetime import datetime

while True:
    result = subprocess.run(['pgrep', '-a', 'transmission-daemon'], capture_output=True, text=True)
    
    if result.stdout:
        processes = result.stdout.strip().split('\n')
        print(f"[{datetime.now().strftime('%H:%M:%S')}] Найдено {len(processes)} процессов:")
        for proc in processes:
            parts = proc.split()
            if len(parts) > 0:
                pid = parts
                memory = subprocess.run(['ps', '-p', pid, '-o', 'rss='], capture_output=True, text=True)
                cpu = subprocess.run(['ps', '-p', pid, '-o', '%cpu='], capture_output=True, text=True)
                print(f"  PID {pid}: Memory={memory.stdout.strip()} KB, CPU={cpu.stdout.strip()}%")
    else:
        print(f"[{datetime.now().strftime('%H:%M:%S')}] Нет процессов transmission")
    
    time.sleep(5)

Чек-лист решения проблемы

Для систематического подхода к решению проблемы используйте следующий чек-лист:

1. Диагностика:

• Запустить ps aux | grep transmission и подтвердить наличие оставшихся процессов
• Проверить тип каждого оставшегося процесса через ps -A -ostat,pid,ppid | grep transmission
• Установить базовый уровень использования памяти через ps -p <PID> -o rss=
• Проверить файл журнала systemd: journalctl -u transmission-daemon.service -n 50

2. Проверка конфигурации systemd:

• Просмотреть текущий тип сервиса: systemctl show transmission-daemon.service | grep Type
• Проверить наличие правильных параметров TimeoutStartSec и TimeoutStopSec
• Убедиться, что ExecStop правильно установлен (должно быть TERM, а не STOP)
• Проверить, скомпилирован ли Transmission с поддержкой systemd: transmission-daemon --help 2>&1 | grep systemd

3. Применение первичных исправлений:

• Изменить Type=notify на Type=simple (если применимо)
• Перезагрузить systemd: sudo systemctl daemon-reload
• Перезагрузить сервис: sudo systemctl restart transmission-daemon
• Дождаться 1-2 минут и снова проверить наличие процессов

4. Тестирование стабильности:

• Мониторить использование памяти в течение часа через watch -n 5 'ps aux | grep transmission'
• Проверить, растет ли использование памяти или остается стабильным
• Проверить значения CPU: они должны быть близки к 0, если нет активных торрентов
• Если рост присутствует, перейти к дополнительным мерам

5. Если проблема сохраняется:

• Отключить UPnP и port forwarding в Transmission
• Уменьшить пределы для соединений (peer-limit-global, peer-limit-per-torrent)
• Отключить DHT, PEX, LPD
• Уменьшить размер кэша (cache-size-mb)
• Рассмотреть понижение версии или замену на другой торрент-клиент

6. Окончательный вариант:

• Если ничто не помогло, явно завершить процессы через pkill -9 -f transmission-daemon
• Перезагрузить systemd и сервис: sudo systemctl daemon-reload && sudo systemctl restart transmission-daemon
• Мониторить в течение 24 часов
• При необходимости установить автоматическую перезагрузку

Предотвращение проблемы: Лучшие практики

Профилактические меры

1. Регулярное обновление системы:

bash sudo apt update
sudo apt upgrade

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

2. Использование консервативных параметров:

Установите более низкие лимиты с самого начала:

• peer-limit-global: 500 вместо 1000
• cache-size-mb: 8 вместо 16
• Отключите DHT и PEX по умолчанию

3. Регулярный мониторинг:

Используйте systemd-systemctl для установки оповещений о превышении использования памяти:

bash sudo systemctl edit transmission-daemon.service

Добавьте:

textMemoryLimit=2G

Это ограничит использование памяти Transmission 2 ГБ и автоматически перезагрузит сервис при превышении.

4. Логирование использования ресурсов:

Создайте systemd таймер для периодического логирования использования ресурсов:

bash sudo tee /etc/systemd/system/transmission-monitor.service > /dev/null <<EOF
[Unit]
Description=Monitor Transmission Resource Usage
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/log-transmission-stats.sh

[Install]
WantedBy=multi-user.target
EOF

И файл скрипта:

bash sudo tee /usr/local/bin/log-transmission-stats.sh > /dev/null <<'EOF'
#!/bin/bash
echo "$(date '+%Y-%m-%d %H:%M:%S') - $(ps aux | grep '[t]ransmission-daemon' | awk '{print "PID:" $2 " MEM:" $6 "KB CPU:" $3 "%"}')" >> /var/log/transmission-stats.log
EOF
sudo chmod +x /usr/local/bin/log-transmission-stats.sh

Затем создайте таймер:

bash sudo tee /etc/systemd/system/transmission-monitor.timer > /dev/null <<EOF
[Unit]
Description=Run Transmission monitoring every 5 minutes
Requires=transmission-monitor.service

[Timer]
OnBootSec=5min
OnUnitActiveSec=5min

[Install]
WantedBy=timers.target
EOF

sudo systemctl enable transmission-monitor.timer
sudo systemctl start transmission-monitor.timer

Выводы и рекомендации

Проблема с оставлением процессов Transmission в памяти на Debian 12 имеет многофакторную природу. Основной причиной часто является конфликт между типом сервиса systemd и способом работы Transmission. Простое изменение Type=notify на Type=simple решает проблему для большинства пользователей.

Для тех, кто не хочет иметь дело с таймаутами и зависаниями, рекомендуется:

1. Использовать Type=simple в systemd сервисе — это наиболее надежный и простой способ
2. Отключить функции, требующие много памяти (UPnP, PEX, DHT) сразу при установке
3. Регулярно мониторить использование памяти через журналы и скрипты
4. Установить таймаут перезагрузки через MemoryLimit в systemd, если утечки памяти неизбежны
5. Рассмотреть альтернативные торрент-клиенты для критичных систем

Диагностика остается ключом к пониманию проблемы. Использование правильных инструментов (ps, smem, lsof, strace, journalctl) позволит точно определить природу оставшихся процессов и выбрать наиболее подходящее решение.

Для пользователей критичных систем (серверы с гарантией времени работы, встроенные системы) рекомендуется также рассмотреть переход на альтернативные торрент-клиенты, которые потенциально могут быть более стабильны, или использовать контейнеризацию (Docker/Podman), которая изолирует проблемы Transmission от основной системы и упростит управление ресурсами.

Помните, что проактивное управление ресурсами и регулярный мониторинг — это лучшая защита от проблем в долгосрочной перспективе.