<p>传输守护进程内存使用率极高</p>

可能是 debian 9 的 bug。
今天我也遇到了这个问题。
我已经构建了一个静态链接的传输守护进程。 它工作正常。

这是解决此问题的临时方法。
用静态链接传输替换/usr/bin/transmission-daemon 。
更改/etc/systemd/system/multi-user.target.wants/transmission-daemon.service如下：

[Unit]
Description=Transmission BitTorrent Daemon
After=network.target

[Service]
User=debian-transmission
Type=simple
ExecStart=/usr/bin/transmission-daemon -f --log-error
ExecStop=/bin/kill -s STOP $MAINPID
ExecReload=/bin/kill -s HUP $MAINPID


[Install]
WantedBy=multi-user.target

然后运行命令：

systemctl daemon-reload
systemctl restart transmission-daemon

传输守护进程.zip

使用静态链接重新编译传输似乎已经成功

使用静态链接重新编译传输将导致传输在内存中为自己保留系统库的单独副本 - 使用更多内存。

我只有大约 350 个使用 7.5G 虚拟、2g 驻留的种子，因为每个种子都有很多 GB 长，我希望它使用大量内存进行缓冲。 根据 top，我看到传输使用了大约 2.092% 的内存和大约 1.3% 的一个 CPU。 我给它缓冲的内存越多，cpu 使用率越低，磁盘活动越少。

你服务的种子有多大？ 一个单一的 suse 版本出现在 DVD 上，可以轻松地占用 >4G。 您希望能够指定内存使用情况，因为如果您将其设置得太低，则会减慢 torrent 服务并增加不必要的磁盘活动。

@messyidea ， @Mechazawa ，你们在谈论“静态链接”，你到底是什么意思？ 发行版提供的传输守护程序（由 ldd 报告）与您构建的那个的依赖关系是什么？ 在我看来，无论链接如何执行，仅重建具有相同依赖项集的内容都会产生不同的结果......或相反亦然？ 或者使用不同的加密后端（openssl、wolfssl、mbedtls）？

@mikedld
这是我的构建脚本。
https://gist.github.com/messyidea/16f9c63d7b219d2a4755e30aedd8268e
基于这个回购。
https://github.com/lancethepants/transmission-mipsel-static/blob/master/transmission.sh

我昨天尝试从源代码进行定期重建，这对我来说似乎也很好。

我也被这个问题击中了。 我设置了一个简单的内存使用监视器，它从 /proc 中提取常驻集大小并询问守护程序当前的下载/上传速度，如报告给 systemd 的那样。
我希望下载/上传速度与内存使用量相关。 然而，守护进程似乎在启动时使用了大量内存（机器交换了很多），然后 - 不知何故 - 内存使用量稳定在 800MB 左右，并且保持这种方式与向下/向上速度无关。 我在会话中有大约 200 个正在运行的种子。
您可以在此处查看图表。 x 轴表示自监视开始以来的秒数。 内存使用量以页为单位，乘以 4 得到 KB。 我可以应要求提供数据文件。

现在，无论如何我都不是传输专家，但我想这根本与cache-size-mb设置无关：整个传输会话只有一个缓存对象，仅在读取时调整大小设置使其大小等于设置中请求的大小。 然后我想也许 I/O 预取是造成这种情况的原因（因为我的传输是在支持posix_fadvise情况下编译的），但是内存使用量不会计入守护进程本身，而是计入报告为内核的I / O缓冲区buff/cache在输出列free 。

运行 Debian 测试和传输 38d3d5377bd326369b65179e4881dece2f54a221。

我在 2.92 上的 raspbian 拉伸（树莓派型号 b+ w/ 512mb ram）上遇到了同样的内存泄漏问题。 raspbian存储库中的版本不可用，启动后根据htop立即跳转到50%内存使用率并开始爬升。 系统很快开始交换并变得无响应。

从源代码构建 2.92 效果更好，但与 2.84 相比，内存使用率仍然很高（约 30%）。 如果我从网络安装驱动器 (sshfs) 播种，则会发生内存泄漏。

我几周前才升级到拉伸，在此之前，我在 raspbian jessie 上使用 2.84 没有这样的问题。 它坚如磐石，传输连续运行数月，零问题。

我昨天从源代码构建并安装了 2.84，一切似乎恢复正常，因此不太可能是操作系统问题。 内存使用率很少超过 20%，目前徘徊在 15% 以下。

其他相关信息，我将 cache-size-mb 设置为 8。我加载了大约 700 个种子，但在任何给定时间都有大约 250 个种子正在播种。

我正在查看 2 个种子文件——一个 400MB 的种子文件大小为 256KB，另一个 6G 种子文件大小为 8M。 在接下来的 6 个中，3 个有 8MB 的块大小，最小的大小为 512KB，4 个有 4MB 的块大小。 那是 1 个 torrent，它在向 1 个客户端发送 1 个时必须占用 4MB 内存。 如果您提供的所有种子文件的大小均为 1MB，那么让其中的 256 个种子一次向 1 个客户端发送或接收 1 个种子将需要 256MB 的缓冲内存。

如果 2.84 对你来说“坚如磐石”，我会坚持下去。

一旦我被迫将播音员 URL 从 http 更改为 https，传输守护程序（2.92 主干 14736）在开始死锁几分钟后在 1.5G 可用 RAM（无交换）上运行 30- 60 分钟（没有机会手动杀死）直到 oom-killer 完成工作。 我想出了一个解决方法：现在我必须小批量启动这样的种子文件，并在中间延迟几分钟，因为传输守护程序在宣布大约 50 个种子文件后它的内存消耗增加了一倍。

将播音员 URL 设为 https 会占用大量资源。 最密集的是 TCP 连接的设置（这就是为播音员 URL 添加 UDP 的原因）。 将其更改为 HTTPS 会因多种因素而减慢速度。 我认为尝试支持在 https 中发布是不合理的——我只是不认为它在今天的硬件上在技术上是可行的。

更新- 上面，我只是在考虑设置加密会话所涉及的计算成本的增加。 我没有考虑可能会加剧性能问题的网络成本，因为 HTTPS 连接可能需要联系多个 3rd 方服务器，以根据可信任的根和您正在与之交谈的服务器之间的授权链_和_根据吊销列表检查密钥。 所有这些都需要往返网络成本（和等待），因为验证了授权链中的远程链接。 鉴于大部分验证都需要等待，我怀疑他们的内存成本会高于 CPU 成本。

我的解决方法只是稍微推迟了这个问题。 我已经看到内存消耗激增，直到它再次挂起。 似乎，如果由于某种原因宣布失败，那么同时宣布越来越多的种子，我必须避免这种情况。 所以挖掘资源是不可避免的。

@Astara ，是的，我知道带有 SSL 的 TCP 比明文 UDP 的成本更高，但我不是在说数百万个种子。 1.5GB 内存不足以支持 50 个使用 SSL 的 TCP 连接？ 这一定是传输中的一个错误，或者在某种程度上，我猜传输是如何使用 libcurl 的。

我拒绝相信它与 SSL 有任何关系。 感觉更像是内存泄漏。

@Mechazawa ，在我将播音员切换到 SSL 之前，我从来没有遇到过问题。 并且内存泄漏不能波动，它只能累积，相反，我观察到内存消耗的峰值，我猜这与重新发布一致。

@andreygursky我目前正在绘制其中一个守护进程的内存使用情况。 一旦由于内存不足而崩溃，我将发布结果

@Mechazawa ，你重新编译传输（GnuTLS，OpenSSL，NSS，..）时安装了什么风格的curl开发包？

@Mechazawa您已经说过使用静态链接重新编译可以解决问题。 这证明它不可能是代码中的问题并且不可能是内存泄漏。 此外，随着静态泄漏而消失的内存泄漏是什么感觉？

如果您认为这是内存泄漏 - 表明确实如此。 在 Valgrind 下运行它。 它可以跟踪每个分配。 使用符号编译传输，它可以准确指出哪些内存“丢失”（没有引用它）或退出时尚未释放的内存（但仍可能被引用）。 大多数导入是在程序退出时没有引用的内存。 最重要的是，valgrind 将向您显示泄漏的内存的确切分配位置。

我已经让传输 2.92 运行了几个月，并且它的内存使用没有改变——我不使用 SSL，但我确实允许在请求时进行加密。 我连接的所有站点都没有使用 SSL 跟踪器——主要是 http、一些 udp 和一些磁铁。 但是我无法相信传输可以运行数月，存在内存泄漏问题并且不会崩溃或内存不足。 我最近一直在重新启动它以释放网络带宽，但我的主守护进程（我通常运行 2 个实例以获得更好的优先级分级）自 9 月 12 日以来一直在运行......这是第 27 天......那是 15 天到目前为止 - 我不希望它有任何不同，因为二进制文件没有改变。

如果存在内存泄漏，它必须在我不使用的代码中——比如 SSL 声明代码——无论如何这都是一个糟糕的主意。 环顾网络，我看到 200-400 毫秒/连接的数字——每次宣布和每个洪流都会重复。 50 个种子可能需要多达 25 秒。 如果在容器中运行 xmission 可能需要两倍或三倍的时间。

这让我想起—— @andreygursky——你的机器有多少个 cpu，你是在容器还是虚拟机中运行传输？ 网络将是连接创建/拆除的较慢的虚拟化领域之一。 如果您在容器中执行 SSL，则 50 个种子可能会造成负担（我认为不太可能），但是重复 SSL 会话创建/拆卸时间虚拟化成本的成本可能会增加......

顺便说一句——我不是变速箱开发人员，但我确实建立了自己的系统并且已经使用了好几年。 我通常让它在我的家用机器上 24x7 全天候运行，所以我会注意到它是否行为不端......

ps 我在 linux 上运行守护进程并使用 Windows 传输 GUI 与它们交互（在大多数情况下）。 他们通过脚本在启动时启动并以自己的用户身份运行。 已经运行了 15 天的那个显示了 1266963K (~1.2G) 的使用量，这对于约 330 个种子种子的种子来说是正常的。

我已经删除了 libcurl4-gnutls-dev 和 libssl-dev 并安装了 libcurl4-openssl-dev 和 libssl1.0-dev 。 然后我重建了传输。 这似乎解决了这个问题。 搜索显示以下内容： https : https://github.com/curl/curl/issues/1086。 还不知道有什么关系。

如果我的问题与原始问题无关，请告诉我，打开一个新问题，或者@mikedld可以在已知问题列表中添加一个新条目？

PS 这有点奇怪，Debian 精选的 OpenSSL 1.1 补丁，但使用了 libcurl 的 GnutTLS 风格。 即使您喜欢使用 OpenSSL 风格的 libcurl，它也只是 1.0 版本，而混合是不可能的（并且通常不是什么好东西），因此目前无法使用 OpenSSL 1.1。

@Astara ，这是一台非常旧的 PC，带有一个核心 64 位 CPU。

运行 4 个守护进程，每个进程带有 ±2000 个种子（它们都有 ssl 公告 url）。 我现在已经绘制了内存使用情况（直到守护程序崩溃）。

不过，我现在没有时间更深入地研究它。

每个 2000 个种子？ 我使用 1.5-3Gb 和 350 个种子，没有 SSL。 这是所有 4 个守护进程的内存使用情况吗？ 那么大约 8000 个种子？ 您是否曾经使用过这种带传输功能或任何其他洪流程序的工作？ 只是看起来相当多的种子。 如果是内存泄漏，您应该能够使用 1 个实例和 500 个种子来重现它——可能需要更长的时间。 您是否尝试过，或者您只是运行 4 个实例，总共 8000 个种子。

你有没有提到你的硬件？ 机器上有多少内存？ 8G？ 多少核心？ 在此期间 %cpu 使用率是多少...

任何种子都处于活动状态吗？ 即实际上为客户提供交通服务？ 它们是否都在等待连接，或者其中一些是否“排队”？ FWIW，我不使用传输的“队列”功能——所以当我有 350 个种子时——它们都在等待客户端连接，并且每半小时发布一次（我认为）。 有些术语似乎有点令人困惑，因为当有人说他们有 2000 个种子时，不确定是所有人都在听还是只有少数人在听，其余的都在排队。

据我所知，有些人的机器因超过 10-20 个活跃的种子而过载——所以增加了排队以允许一次只允许一些人真正处于活动状态。 就我自己而言，当我得到大约 400 个种子时，我拆分了我的种子，因为我注意到我的 GUI 响应对于我的口味来说变得太慢了——但那是通过 RPC 客户端在本地网络上运行 GUI。 只是猜测，但可能与 RPC 接口有关，并且必须完成太多请求才能更新每个显示。 如果 RPC 接口有批量操作可能会有所帮助，但假设任何人都可以重新制作/重新编译 GUI，因为我被告知其作者已停止更新它（我尝试编译它，但无法在 Pascal 下编译它他们使用的编译器。

Anwway，当您有时间时，您可以尝试在 Valgrind 下运行 1 个具有 50 个客户端的实例（它在 valgrind.org 上是开源的）。 我发现它在跟踪内存问题（我的涉及使用后释放指针）方面非常宝贵。 你不会想运行它直到它耗尽内存——会产生太多的输出。 只需要运行 1 个广播（通过 SSL）循环，然后停止程序——它会显示任何丢失的内存。 如果真的是泄漏，即使是 1 个客户端也可能会显示问题——甚至是指针重用，因为它会跟踪所有内容。

@andreygursky - 顺便说一句，你说 50 个带有 SSL 的种子会重复这个错误......你也可以尝试运行 valgrind，即使使用 1 个种子+SSL 看看它会产生什么。 我相信即使使用普通的二进制文件它也能找到内存问题——但要让它有任何意义并追踪它，你最终会想要用符号重新编译。 顺便说一句——回复：stackoverflow 上的问题——好找！ 即使在那里，您也可以看到其他人使用不同的后端和截然不同的内存使用情况稍微改变了组合（即使他们无法重现问题）。 我很高兴你现在找到了解决方法......

我尝试了@andreygursky的解决方案，似乎已经解决了。

@阿斯塔拉
10Gigs 内存和 4 核 @3.2Gh/z。 传输守护进程在任何时候都几乎不使用任何 CPU。 我能够用一个实例和 1k 个种子来重现它。 我的种子都处于活动状态并且播种我很少有超过 3 个项目排队。

我还可以确认，在 debian/raspbian stable 上使用 libcurl4-openssl-dev 和 libssl1.0-dev 编译传输 2.92 似乎可以解决内存问题。 谢谢@andreygursky ！

有人向 debian 维护者报告了这个错误吗？

@Mechazawa ，正是我所说的尖峰。

@Bisaloo ，我在这里从 Debian 的错误报告传输守护进程 2.92 高内存使用中发现了这个问题。

那么这个问题 #333 是相关的吗？

我不知道 Debian 是否会在下游解决这个问题？

@Seeder101包维护者应该得到通知： https : //packages.debian.org/source/stretch/transmission

@Mechazawa https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865624
如果有人知道如何在 debian 系统中与这个错误/问题进行交互，那么自 Jun 以来这没有改变会很棒（我的意思是让维护人员对此进行更深入的研究）

你的意思是“制造”维护者......？ 嗯？ 你打算如何“让”一名志愿者做你想做的事？ 也许尝试编辑产品生成脚本（对于 rpm 将是“规范”文件.. 不确定它对于 debian 会是什么）......并提交修复版本作为建议的修复？

咳咳……人们想知道为什么开发人员会精疲力竭……

@Astara你错了，先生
我不是故意强迫他们什么的
我知道这是一个以志愿者为基础的……就像我在说如果有人可以报告或让他们知道这个问题
我认为@Mechazawa已经进行了互动
谢谢

对不起，如果我发表了虚假评论或被认为是不好的

问候

由于其他人已经发布了“如何解决问题”（andreygursky：我已经删除了 libcurl4-gnutls-dev 和 libssl-dev 并安装了 libcurl4-openssl-dev 和 libssl1.0-dev。然后我重建了传输。这个似乎解决了这个问题），我猜 debian 的人可能会在下一个版本中包含该修复程序，但我不知道 debian 的政策是在用户可能能够申请时发布针对单个产品的中期版本修复程序相同的解决方法......不知道......不要用debian工作......对不起...... @Seeder101 - 不要太担心......只是措辞似乎有点“有趣”对于一个星期天...

我记得一位软件经理在谈论如何试图“管理”软件工程师有点像试图养猫——让志愿软件工程师做事要困难得多......（尽管取决于软件工程师, 一份 6 件装的礼物或一个用于帮助他们中的一些人获得动力的箱子...;-))...

@Astara你用什么做服务器？

我有一个（现在有点老了），运行 Linux 的 Dell PowerEdge T610 Server @ home。 我用win7做桌面，用传输远程gui来控制传输守护进程。 我曾经定期运行 2 个 xm 守护进程，但有时在我偶尔玩多人游戏时会运行 1 个以释放一些网络带宽。 运行种子文件通常是戴尔的后台任务——它也作为 win7 的主要互联网连接，（代理、路由器、DNS、电子邮件、备份）。 桌面刚刚死了——所以需要换一个新的。 服务器仍在运行 @ 7 年以上。 我之前的“服务器”是一台经过改造的工作站，同样来自戴尔，持续了大约 10 年。

我尝试了这里提到的解决方案，它对我有用。 谢谢！

此解决方案的主要问题在于它实际上是一种解决方法。 传输应该与 curl 使用的任意 SSL 库一起使用，因为 curl 完全抽象了逻辑。 curl 和 curl 与 ssl 库之间的交互错误必须更加微妙。 但是由于没有人有时间使用变通方法进一步调查它是一种方法。

@Seeder101 ，

如果有人知道如何在 debian 系统中与此错误/问题进行交互会很棒

这很简单，您甚至不需要注册（就像在大多数现代错误报告系统中一样），只需向[email protected]发送一封电子邮件，在我们的例子中： [email protected]。

任何人， @nakhan98 ，@ciprian-radu，
您是否确切地知道，您是否有带有 SSL 跟踪器的种子或只有“普通”HTTP（但实际上带有 HTTPS 重定向）（UDP 不感兴趣）？ 我很惊讶，交换 SSL 库有助于纯文本跟踪器。

@andreygursky我使用配置选项--enable-lightweight (https://github.com/transmission/transmission/blob/master/configure.ac#L605) 从源构建传输，因为我从 512 MB 的 Raspberry Pi 运行内存。 此选项在传输中设置了 _prefer unencrypted peer connections_。
无论如何，在我的情况下，传输的使用不是资源密集型的，但是，我确实有另一个服务，它也占用了完整的 CPU 和大量的 RAM，所以我怀疑当这两个服务都在运行时，我的 rPI 仍然没有内存。

@Seeder101出于好奇，传输是在 Debian 中用libcurl4-gnutls-dev而不是libcurl4-openssl-dev构建的吗？ 为什么，在这里https://github.com/transmission/transmission/wiki/Building-Transmission明确指定使用libcurl4-openssl-dev 。

@ciprian-radu

此选项首选传输中设置的未加密对等连接。

我相信没关系。 对我来说，问题是由 SSL 跟踪器连接触发的。

出于好奇，在 Debian 中使用 libcurl4-gnutls-dev 而不是 libcurl4-openssl-dev 在 Debian 中构建了传输吗？ 为什么

我猜是因为 openssl 是“邪恶的”，应该被 gnutls 取代。 关于许可证问题，我可以同意，但对于传输来说，这不是问题。

尝试自己构建（Raspberry Pi），但没有成功，有什么提示吗？

我的方式（几乎是维基的东西）：

    mkdir –p ~/builds/transmission/
    wget https://github.com/transmission/transmission-releases/raw/master/transmission-2.92.tar.xz
    tar xf transmission-2.92.tar.xz
    cd transmission-2.92

    CFLAGS="-Os -march=native" ./configure --disable-nls --disable-cli
    make
    checkinstall --fstrans=no

使用 systemctl 启动传输守护程序后给出超时

和

    CFLAGS="-Os -march=native" ./configure --disable-nls --disable-cli --with-systemd-daemon

有一个错误：

    checking for SYSTEMD_DAEMON... no
    configure: error: systemd startup notification support requested, but libsystemd-daemon not found.

编辑：
在 configure.ac 中安装 libsystemd-dev 并将 libsystemd-daemon-dev 更改为 libsystemd-dev 即可解决问题。
所以传输守护进程与 systemd 一起工作。 内存使用情况：

140MB @ 750 种子 - 5 个活跃（1MB/s 上升/1MB/s 下降）

大家好，
我还想确认在 raspbian 拉伸上传输的问题。 由于我是一个菜鸟，对这里每个人都在谈论的静态链接知之甚少，我将编写程序来帮助像我这样的人。
所以基本上@messyidea 为我指明了正确的方向，尤其是通过他的脚本，我能够达到目标：
https://gist.github.com/messyidea/16f9c63d7b219d2a4755e30aedd8268e

脚本中有几行应该修改以在 raspbian 上工作，在第 52 行它说：
./Configure linux-x86_64 \
将其更改为
./Configure linux-generic32 \
（请我不是 linux 专家，所以如果有人可以纠正我，请这样做，但这对我有用。）
同样在第 147 行：
--disable-nls \
应该
--enable-nls \

当脚本完成（需要一段时间）时，应该有 /home/pi/transmission/transmission-2.92/daemon 目录，并且应该有传输守护程序文件，如果你用 file 命令检查它，你应该看到它是静态链接：

pi<strong i="25">@raspberrypi</strong>:~/transmission/transmission-2.92/daemon $ file transmission-daemon
transmission-daemon: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, for GNU/Linux 3.2.0, BuildID[sha1]=c89515dde70bd52d07ccf902f91ad7701bd5cb95, not stripped

所以基本上你现在需要做的就是把这个新编译的传输守护程序文件复制到 /usr/bin/ 文件夹
pi<strong i="29">@raspberrypi</strong>:~/transmission/transmission-2.92/daemon $ sudo cp transmission-daemon /usr/bin/

并像@messyidea所说的那样更改 /etc/systemd/system/multi-user.target.wants/transmission-daemon.service（我只能看到旧服务之间 type=simple 的区别）。

希望这会帮助某人:)

问候

@andreygursky这样做也对我

我知道这并不是真正需要“支持”的地方，但我几乎到处都试图解决这个问题。

我尝试使用传输源包来应用补丁，但我无法在不安装 qt5 等的情况下重建包，这不是我想在无头系统上安装的东西。

我有大约 6000 个种子传输种子，它使用了所有 8 演出的内存，CPU 使用率也很高。 因此，我需要一种方法来应用此解决方法，而不会中断我的所有种子等。

我知道这是一个很长的镜头，但有人可以帮助我吗？ 甚至测试包也在使用 gnutls。

埃苏克斯写道：
>

我尝试使用传输源包来应用补丁，但是
我无法在不安装 qt5 等的情况下重建软件包，这不是我的东西
希望必须安装在无头系统上。

默认情况下，标准 make 将尝试构建所有内容。

您需要重新运行 'configure' 脚本（尝试使用 'configure --help'
查看所有选项）...在那里你可以确保你设置了你想要的选项
并禁用或构建“没有”你不需要的

看起来我从类似的东西开始：

配置 --enable-daemon --without-gtk --enabled-utp
--without-systemd-daemon --with-inotify

所以也许像这样的事情开始并适应什么
最适合您的设置...？

你好，

我正在尝试为我的 Raspberry Pi 编译传输 2.93。 但是当我尝试编译 curl 时，我总是收到此错误：

检查是否启用 iOS/Mac OS X 原生 SSL/TLS... 否
检查 pkg-config... /usr/bin/pkg-config
使用 pkg-config 检查 openssl 选项...找到
配置：pkg-config：SSL_LIBS：“-lssl -lcrypto”
配置：pkg-config：SSL_LDFLAGS：“”
配置：pkg-config：SSL_CPPFLAGS：“”
检查 -lcrypto 中的 HMAC_Update ... 否
检查 -lcrypto 中的 HMAC_Init_ex... 否
检查 -laxtls 中的 ssl_version ... 否
配置：警告：SSL 已禁用，您将无法使用 HTTPS、FTPS、NTLM 等。
配置：警告：使用--with-ssl、--with-gnutls、--with-polarssl、--with-cyassl、--with-nss、--with-axtls、--with-winssl 或- with-darwinssl 来解决这个问题。
检查默认 CA 证书包/路径...配置：错误：--with-ca-path 仅适用于 OpenSSL、GnuTLS 或 PolarSSL

有人可以帮我弄这个吗？

谢谢。

库卡米

嗨@kami83 ，

我正在尝试为我的 Raspberry Pi 编译传输 2.93。 但是当我尝试编译 curl 时，我总是收到此错误

正如我之前描述的（https://github.com/transmission/transmission/issues/313#issuecomment-332543087），您不需要重新编译 curl。 或者您的操作系统没有为 Debian 等不同 SSL 风格提供 curl 软件包？

我对解决方案有点困惑。 我已经升级了我的 pi 2 以使用 apt-get --dist-upgrade 进行拉伸，现在传输 2.92 并且内存泄漏。 （我有一个 Pi 3B+，我想开始使用，但由于这个错误而无法使用）。

我知道我需要删除 libcurl4-gnutls-dev 和 libssl-dev 并安装 libcurl4-openssl-dev 和 libssl1.0-dev 。 然后重建传输，但我该怎么做？

我可以清除两个有问题的库并安装两个替换库，但是我如何处理现有的传输？ 如何使用新库重建传输？

对不起，如果这是一个新问题，但你们这些人听起来很简单。

谢谢。

你好，

我刚刚对其进行了测试，但是现在使用 curl 和传输进行编译时出现此错误：
libtool：警告：库“/root/transmission/opt/lib/libevent.la”已移动。
libtool：警告：库“/root/transmission/opt/lib/libevent.la”已移动。
CC blocklist-test.o
CCLD 阻止列表测试
libtool：警告：库“/root/transmission/opt/lib/libevent.la”已移动。
libtool：警告：库“/root/transmission/opt/lib/libevent.la”已移动。
./libtransmission.a(web.o): 在函数中createEasy': /root/transmission/src/transmission/transmission-2.92/libtransmission/web.c:178: undefined reference to curl_easy_init'
/root/transmission/src/transmission/transmission-2.92/libtransmission/web.c:182: 对curl_easy_setopt' /root/transmission/src/transmission/transmission-2.92/libtransmission/web.c:183: undefined reference to curl_easy_setopt 的未定义引用
/root/transmission/src/transmission/transmission-2.92/libtransmission/web.c:184: 对curl_easy_setopt' /root/transmission/src/transmission/transmission-2.92/libtransmission/web.c:185: undefined reference to curl_easy_setopt 的未定义引用
/root/transmission/src/transmission/transmission-2.92/libtransmission/web.c:186: 对curl_easy_setopt' ./libtransmission.a(web.o):/root/transmission/src/transmission/transmission-2.92/libtransmission/web.c:187: more undefined references to curl_easy_setopt 的未定义引用
./libtransmission.a(web.o): 在函数tr_webThreadFunc': /root/transmission/src/transmission/transmission-2.92/libtransmission/web.c:384: undefined reference to curl_global_init'
/root/transmission/src/transmission/transmission-2.92/libtransmission/web.c:385: 对curl_global_init' /root/transmission/src/transmission/transmission-2.92/libtransmission/web.c:407: undefined reference to curl_multi_init 的未定义引用
/root/transmission/src/transmission/transmission-2.92/libtransmission/web.c:432: 对curl_multi_add_handle' /root/transmission/src/transmission/transmission-2.92/libtransmission/web.c:450: undefined reference to curl_easy_pause 的未定义引用
/root/transmission/src/transmission/transmission-2.92/libtransmission/web.c:455: 对curl_multi_timeout' /root/transmission/src/transmission/transmission-2.92/libtransmission/web.c:471: undefined reference to curl_multi_fdset 的未定义引用
/root/transmission/src/transmission/transmission-2.92/libtransmission/web.c:484: 对curl_multi_perform' /root/transmission/src/transmission/transmission-2.92/libtransmission/web.c:496: undefined reference to curl_easy_getinfo 的未定义引用
/root/transmission/src/transmission/transmission-2.92/libtransmission/web.c:498: 对curl_easy_getinfo' /root/transmission/src/transmission/transmission-2.92/libtransmission/web.c:499: undefined reference to curl_easy_getinfo 的未定义引用
/root/transmission/src/transmission/transmission-2.92/libtransmission/web.c:500: 对curl_easy_getinfo' /root/transmission/src/transmission/transmission-2.92/libtransmission/web.c:503: undefined reference to curl_multi_remove_handle 的未定义引用
/root/transmission/src/transmission/transmission-2.92/libtransmission/web.c:505: 未定义引用curl_easy_cleanup' /root/transmission/src/transmission/transmission-2.92/libtransmission/web.c:488: undefined reference to curl_multi_info_read'
/root/transmission/src/transmission/transmission-2.92/libtransmission/web.c:524: 对curl_multi_cleanup' ./libtransmission.a(web.o): In function tr_webGetTaskInfo 的未定义引用：
/root/transmission/src/transmission/transmission-2.92/libtransmission/web.c:549: 对curl_easy_getinfo' ./libtransmission.a(web.o): In function tr_http_unescape 的未定义引用：
/root/transmission/src/transmission/transmission-2.92/libtransmission/web.c:636: 对curl_unescape' /root/transmission/src/transmission/transmission-2.92/libtransmission/web.c:638: undefined reference to curl_free 的未定义引用
./libtransmission.a(crypto-utils-openssl.o): 在函数中log_openssl_error': /root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:42: undefined reference to ERR_get_error'
/root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:52: 未定义引用ERR_load_crypto_strings' /root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:57: undefined reference to ERR_error_string_n'
./libtransmission.a(crypto-utils-openssl.o): 在函数中tr_sha1_init': /root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:101: undefined reference to EVP_MD_CTX_create'
/root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:103: 未定义引用EVP_sha1' /root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:103: undefined reference to EVP_DigestInit_ex'
/root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:106: 对EVP_MD_CTX_destroy' ./libtransmission.a(crypto-utils-openssl.o): In function tr_sha1_update 的未定义引用：
/root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:122: 对EVP_DigestUpdate' ./libtransmission.a(crypto-utils-openssl.o): In function tr_sha1_final 的未定义引用：
/root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:137: 未定义引用EVP_DigestFinal_ex' /root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:142: undefined reference to EVP_MD_CTX_destroy'
./libtransmission.a(crypto-utils-openssl.o): 在函数中tr_rc4_new': /root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:179: undefined reference to EVP_CIPHER_CTX_new'
/root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:181: 未定义引用EVP_rc4' /root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:181: undefined reference to EVP_CipherInit_ex'
/root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:184: 对EVP_CIPHER_CTX_free' ./libtransmission.a(crypto-utils-openssl.o): In function tr_rc4_free 的未定义引用：
/root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:194: 对EVP_CIPHER_CTX_free' ./libtransmission.a(crypto-utils-openssl.o): In function tr_rc4_set_key 的未定义引用：
/root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:205: 未定义引用EVP_CIPHER_CTX_set_key_length' /root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:207: undefined reference to EVP_CipherInit_ex'
./libtransmission.a(crypto-utils-openssl.o): 在函数中tr_rc4_process': /root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:226: undefined reference to EVP_CipherUpdate'
./libtransmission.a(crypto-utils-openssl.o): 在函数中tr_dh_new': /root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:239: undefined reference to DH_new'
/root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:244：对BN_bin2bn' /root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:245: undefined reference to BN_bin2bn'的未定义引用
/root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:247: 对DH_free' ./libtransmission.a(crypto-utils-openssl.o): In function tr_dh_free 的未定义引用：
/root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:260：对DH_free' ./libtransmission.a(crypto-utils-openssl.o): In function tr_dh_make_key'的未定义引用：
/root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:277：对DH_generate_key' /root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:280: undefined reference to BN_bn2bin'的未定义引用
/root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:281: 对DH_size' ./libtransmission.a(crypto-utils-openssl.o): In function tr_dh_agree 的未定义引用：
/root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:303: 未定义对BN_bin2bn' /root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:306: undefined reference to DH_size 的引用
/root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:309: 未定义对DH_compute_key' /root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:320: undefined reference to BN_free 的引用
./libtransmission.a(crypto-utils-openssl.o): 在函数中tr_rand_buffer': /root/transmission/src/transmission/transmission-2.92/libtransmission/crypto-utils-openssl.c:334: undefined reference to RAND_bytes'
collect2: 错误: ld 返回 1 个退出状态
Makefile:1067 : die Regel für Ziel “blocklist-test” scheiterte
make[1]: * [blocklist-test] Fehler 1make[1]: Verzeichnis „/root/transmission/src/transmission/transmission-2.92/libtransmission“ wird verlassenMakefile:507 : die Regel für Ziel “all-recursive” scheiterte制作：* [全递归] Fehler 1

也许有人可以帮助我？

库卡米

@sirskills ：

如何使用新库重建传输？

$ sudo apt-get build-dep transmission
$ sudo apt-get purge libcurl4-gnutls-dev libssl-dev 
$ sudo apt-get install libcurl4-openssl-dev libssl1.0-dev
$ apt-get source transmission
$ cd transmission-2.93
$ dpkg-buildpackage -uc -us
$ cd ..
$ sudo dpkg -i <transmission packages ...>

@卡米83 ：

我刚刚对其进行了测试，但是现在使用 curl 和传输进行编译时出现此错误：

在不知道您正在使用什么操作系统和重建传输的步骤的情况下，很难向您提出明确的建议。

你好，

我很抱歉刚刚忘记了。 我在 RPI 3B+ 上使用 raspbian 拉伸。 我试过你的 apt-steps，但我对内存有同样的问题。 建筑工作，但内存已满。

有什么帮助吗？？
非常感谢。

库卡米

@kami83你在这一步做了什么：
apt-get 源传输

是不是只是从我想象的github页面插入源代码，比如克隆https://github.com/transmission/transmission.git
?
还有 sudo dpkg -i 这

@kami83有一个 debian/control 文件。
https://anonscm.debian.org/cgit/collab-maint/transmission.git/tree/debian/control
将第 10 行从
libcurl4-gnutls-dev | libcurl4-dev | libcurl-dev,
到
libcurl4-openssl-dev | libcurl-dev,

嗨，我只是用我的 pi 3B+ 重新编译了 raspbian 下的所有内容。 在这个系统上，这不是 openssl/gnutls 问题。内存总是满了，系统就会崩溃。 问题一定出在其他地方。 我不仅安装了：libcurl4-openssl-dev libssl1.0-dev。 一切都是新的，但这里有同样的问题。

也许有人可以帮忙。

库卡米

在这种情况下，这不是同一个问题。 甚至可能根本不是与传输相关的问题。

好的。 但是，如果我在几秒钟后使用标准的 2.92-2 Debian 版本，则内存已满。 您可以在几秒钟内看到内存使用量是如何上升的。 我能做什么？

非常感谢。

库卡米

@kami基于transmission_2.92-2+deb9u1_armhf，我已经以这种方式成功地为pi 3B构建了传输。 试一试。

SystemOS：OSMC - debian stretch (9.4)
系统：树莓派 3B

让最初安装的版本通过 apt/apt-get 安装。

将以下二进制文件保存到/usr/local/bin/并/etc/systemd/system/multi-user.target.wants/transmission-daemon.service这种方式更改您的 systemD 单元文件 (

#ExecStart=/usr/bin/transmission-daemon -f --log-error --logfile /var/log/transmission/transmission-daemon.log ExecStart=/usr/local/bin/transmission-daemon -f --log-error --logfile /var/log/transmission/transmission-daemon.log

https://www.dropbox.com/s/x9aatjdoajsiqry/transmission-daemon?dl=0
https://www.virustotal.com/de/file/7f394bebcdb7666bc989c49280dd9f6e053347385a0985d9cc91f7c4bbea8966/analysis/1525532872/

此外/作为解决方法，您可以将这两行添加到单元文件中以在失败时重新启动传输，对我而言，在我重新编译传输之前，这都是 2 小时。

Restart=on-failure
RestartSec=10

PS。：今晚我可以写一个分步指南，这对我有用。

@sirskills ：

$ apt-get 源传输

是不是只是从我想象的github页面插入源代码，比如克隆https://github.com/transmission/transmission.git
?

不，除非您更改了相应的配置文件，否则 apt-get 会从 Debian 存储库中提取并提取源 tarball。

还有 sudo dpkg -i 那是所有的依赖吗？

传输守护进程_2.93-1_amd64.deb传输通用_2.93-1_all.deb传输远程cli_1.7.0-1_all.deb（如果需要-gtk，-qt）。

@卡米83 ：

请发布输出

$ dpkg -l | grep -e libcurl -e libssl -e gnutls -e libevent

伙计们，这不是那么简单，您可以将使用 gnutls 的软件包与使用 openssl 的软件包交换。

@mikedld作为该项目的所有者，您能否阅读https://people.gnome.org/~markmc/openssl-and-the-gpl.html并将此类例外添加到传输许可证中？ 在不久的将来，我们希望 OpenSSL 能够在 Apache-2 下重新获得许可，但我们还没有做到。

确实，传输的主要许可证是 Expat，但 libtransmission 中的许多（如果不是全部）文件都在 GPL 下，并且这些文件也从 cURL 访问 SSL 对象。

一旦异常到位，如果我们能有一个传输版本（甚至是补丁版本，比如 2.74.1），那么 Debian 可以选择它并切换到libcurl4-openssl-dev并希望解决这个问题，那将是非常棒的许多用户非常渴望修复的错误。

谢谢！

@sandrotosi它已经存在于COPYING 中：

此外，允许链接和/或使用 OpenSSL。

@sandrotosi ：

伙计们，这不是那么简单，您可以将使用 gnutls 的软件包与使用 openssl 的软件包交换。

只是为了澄清“您”：对于用户而言，无论许可证如何，这只是重建软件包的问题。 这只是那些重新分发二进制包（即操作系统分发）的人的问题。

@mikedld ，感谢您的澄清！

@sandrotosi ，

顺便说一句，传输包在其构建依赖项中包含 libssl-dev 超过 7 年（可能更长）[1]。 所以它已经链接到 OpenSSL。

但是 libtransmission 中的许多（如果不是全部）文件都在 GPL 下，这些文件也从 cURL 访问 SSL 对象。

一旦异常到位，如果我们可以有一个传输版本（甚至是补丁版本，比如 2.74.1），那么 Debian 可以选择它并切换到 libcurl4-openssl-dev，那将是非常棒的

或者您过去在每个文件的基础上更详细地调查过这个问题，我的意思是使用 OpenSSL 的此类文件不是 GPL，因此是 libssl-dev dep？ OTOH，你说过“......（如果不是全部）文件”。 在所有文件的情况下，这意味着传输无法链接到 Debian 中的 OpenSSL。

[1] https://salsa.debian.org/debian/transmission/commit/49f786fdc067a4a4ba1313958bd034fd440923b3

大家好，

我刚刚得到了一些新信息：

• dpkg -l | grep -e libcurl -e libssl -e gnutls -e libevent
  ii libcurl3:armhf 7.52.1-5+deb9u5 armhf 易于使用的客户端 URL 传输库（OpenSSL 风格）
  ii libcurl3- gnutls:armhf 7.52.1-5+deb9u5 armhf 易于使用的客户端 URL 传输库（GnuTLS 风格）
  ii libcurl4-openssl- dev:armhf 7.52.1-5+deb9u5 armhf 开发文件和 libcurl 文档（OpenSSL 风格）
  ii libev4 1:4.22-1 armhf 以 libevent 为模型的高性能事件循环库
  ii libevent-2.0-5:armhf 2.0.21-stable-3 armhf 异步事件通知库
  ii libevent-core-2.0-5:armhf 2.0.21-stable-3 armhf 异步事件通知库（核心）
  ii libevent-dev 2.0.21-stable-3 armhf 异步事件通知库（开发文件）
  ii libevent-extra-2.0-5:armhf 2.0.21-stable-3 armhf 异步事件通知库（额外）
  ii libevent-openssl-2.0-5:armhf 2.0.21-stable-3 armhf 异步事件通知库（openssl）
  ii libevent-pthreads-2.0-5:armhf 2.0.21-stable-3 armhf 异步事件通知库（pthreads）
  ii libgnutls-dane0:armhf 3.5.8-5+deb9u3 armhf GNU TLS 库 - DANE 安全支持
  ii libgnutls-deb0-28:armhf 3.3.8-6+deb8u7 armhf GNU TLS 库 - 主要运行时库
  ii libgnutls-openssl27:armhf 3.5.8-5+deb9u3 armhf GNU TLS 库 - OpenSSL 包装器
  ii libgnutls26:armhf 2.12.20-8+deb7u3 armhf GNU TLS 库 - 运行时库
  ii libgnutls28- dev:armhf 3.5.8-5+deb9u3 armhf GNU TLS 库-开发文件
  ii libgnutls30:armhf 3.5.8-5+deb9u3 armhf GNU TLS 库 - 主要运行时库
  rc libgnutlsxx27:armhf 2.12.20-8+deb7u3 armhf GNU TLS 库 - C++ 运行时库
  ii libgnutlsxx28:armhf 3.5.8-5+deb9u3 armhf GNU TLS 库 - C++ 运行时库
  ii libneon27- gnutls:armhf 0.30.2-2 armhf HTTP 和 WebDAV 客户端库（启用 GnuTLS）
  ii libssl1.0- dev:armhf 1.0.2l-2+deb9u3 armhf 安全套接字层工具包-开发文件
  ii libssl1.0.0:armhf 1.0.1t-1+deb8u8 armhf 安全套接字层工具包 - 共享库
  ii libssl1.0.2:armhf 1.0.2l-2+deb9u3 armhf 安全套接字层工具包 - 共享库
  ii libssl1.1:armhf 1.1.0f-3+deb9u2 armhf 安全套接字层工具包 - 共享库
  ii python3-pycurl 7.43.0-2 armhf Python 绑定到 libcurl (Python 3)

这是我的输出， @andreygursky如果我尝试启动您的传输守护程序，我会收到如下错误：

内存访问错误

对不起。 也许您可以写下在树莓上构建传输守护程序的分步指南？

非常感谢。

库卡米

@kami83 ，除了一些混合看起来不错：

ii libgnutls26:armhf 2.12.20-8+ deb7u3 armhf GNU TLS 库 - 运行时库
ii libssl1.0.0:armhf 1.0.1t-1+ deb8u8 armhf 安全套接字层工具包 - 共享库

您已经在使用 Debian 9，但是您仍然拥有 7 和 8 的软件包。谁知道这会导致什么问题。

看来，您必须更深入地调查您的问题（确保您的所有软件包都是最新的，启用日志记录，增加详细程度，启用调试日志记录，..）。

十指相扣，但它已经运行了 12 个小时，没有任何问题，自从从 Jessie 升级到我的 pi 3B+ 后，我什么也没做。

dpkg -l | grep -e libcurl -e libssl -e gnutls -e libevent
ii libcurl3:armhf 7.38.0-4+deb8u10 armhf 易于使用的客户端 URL 传输库（OpenSSL 风格）
ii libcurl3- gnutls:armhf 7.38.0-4+deb8u10 armhf 易于使用的客户端 URL 传输库（GnuTLS 风格）
ii libcurl4-openssl- dev:armhf 7.38.0-4+deb8u10 armhf 开发文件和 libcurl 文档（OpenSSL 风格）
ii libevent-2.0-5:armhf 2.0.21-stable-3 armhf 异步事件通知库
ii libgnutls-deb0-28:armhf 3.3.8-6+deb8u7 armhf GNU TLS 库 - 主要运行时库
ii libgnutls-openssl27:armhf 3.3.8-6+deb8u7 armhf GNU TLS 库 - OpenSSL 包装器
ii libssl- dev:armhf 1.0.1t-1+deb8u8 armhf 安全套接字层工具包-开发文件
ii libssl-doc 1.1.0f-3+deb9u2 all Secure Sockets Layer toolkit - 开发文档
ii libssl1.0.0:armhf 1.0.1t-1+deb8u8 armhf 安全套接字层工具包 - 共享库

你好，

现在我只是用 deb7 和 deb8 清理并删除了旧包。 但这不是问题。 我找到了，我真的很抱歉让每个人都感到困惑。 这是 settings.json 中的一个设置。 我只是将 JSON 文件从更大的系统复制到树莓派，并且有“cache-size-mb”：245 所以这是我的问题。 我将其更改为 4 mb，一切都很好。

对不起库卡米

谢谢@mikedld，我应该更好地在 debian 中保持最新的版权信息； 2.94 将在几分钟内发布，链接到 libcurl-openssl

升级到我的 Pi 3B+ 进行拉伸，添加了测试仓库并安装了 2.94。 连续三天内存使用稳定。 我会说问题解决了非常感谢大家。

@sirskills ：

我会说问题解决了非常感谢大家。

从 2.94 打包 [1] 开始，该问题在 Debian 中通过应用建议的解决方法得到解决。 但总的来说还没有解决。 我继续对此进行进一步调查。

[1] https://tracker.debian.org/news/955142/accepted-transmission-294-1-source-amd64-all-into-unstable/

使用全新安装的最新版本（2018-11-13-raspbian-stretch.zip）在 Pi 上运行我发现了同样的问题。 内存消耗稳步增加，直到 OOM Killer 停止进程。

升级到 2.94 解决了这个问题，不幸的是，这涉及将它安装到 debian 测试存储库并混合来自稳定和测试版本的包。

@javicacheiro你能介绍一下如何在 arm 设备上安装 2.94 吗？ 如何混合和匹配等...如果可能的话谢谢

@dkimmortal这是我遵循的过程：

• 激活 raspbian 测试存储库，将以下行添加到 /etc/apt/sources.list

# Testing branch to get transmission-daemon 2.94 and solve excessive memory allocation in 2.92
deb http://raspbian.raspberrypi.org/raspbian/ testing main contrib non-free rpi

• 更新包的缓存

apt update

• 安装最新版本的传输守护程序

apt install transmission-daemon

对我来说，这已经安装了传输守护程序版本 2.94-1+b2，但它可能会随着 repo 的未来更新而改变。
要强制使用此特定版本，您可以明确请求它，但通常我会坚持使用最新版本。

apt install transmission-daemon=2.94-1+b2

之后，您可以禁用测试存储库并在修改后的拉伸系统中继续，或者完全跳转到运行apt dist-upgrade的测试版本（但这不是让传输守护程序 2.94 工作所必需的）。

主要问题是，由于您混合了来自稳定版本和测试版本的软件包，这可能会在安装其他软件时引起一些冲突，这主要是因为库版本不兼容。

@javicacheiro ：

# Testing branch to get transmission-daemon 2.94 and solve memory leak in 2.92

只是为了避免进一步混淆：这不是内存泄漏，而是可以称为“过度内存分配”的行为。 许多不够小的内存块几乎一次分配，然后定期（或以高速率）释放。

次优 curl 构建配置选项引发了如何访问 SSL 证书数据、gnutls 中次优代码来访问此数据以及 curl 如何使用此代码（以及次优配置的跟踪器服务器在重新宣布强制同时建立多个证书后立即关闭 SSL 连接）如果许多种子计划几乎同时重新发布，则单独的 SSL 连接）。 事实证明，OpenSSL 可以更有效地管理 SSL 验证。 我想，没有多少人可以在传输本身中解决。

@andreygursky非常感谢您的澄清。 我已经更新了评论以避免混淆。
如果我理解正确，则可以在 2.92 中使用 OpenSSL 而不是 gnutls 重新编译包来解决问题，就像@nakhan98所做的那样。 我看到存在许可问题，但由于测试存储库中的 2.94 已经使用 gnutls 编译，我想它们已经解决了。 所以应该可以在稳定的 repo 中对 2.92 做同样的事情。 你知道是什么阻止了这个修复进入稳定的回购吗？

@javicacheiro
也许只需要一个推送/请求。 最初的错误报告已修复并关闭，因此它可能超出了维护者的范围： https : =865624

如果还没有打开的错误报告/请求，我将查看是否向上面的错误添加评论以要求向后移植。

@andreygursky非常感谢提供的详细信息。
我最近刚刚将我的 NAS 升级到基于 Debian Stretch 的操作系统 (OMV) 版本，这个问题让我抓狂。
在重新编译传输 2.92 后，昨天，使用您提到的库，问题不再出现，到目前为止。

不幸的是，升级到 2.94 并没有解决我的问题。

在带有传输 2.94 的 Ubuntu 16.04.6 LTS 上，我也继续遇到这个问题。 http 宣布 url 工作完美，但 https 总是会导致内存泄漏，在数小时内占用所有可用内存。

@sergey-alekseev @andrasveto
不确定是上游版本修复了这个错误，还是上游端的错误。 在 Debian 上，从 bug 报告中可以看出，高内存使用是通过使用libcurl4-gnutls-dev编译产生的，这与本 Wiki 的构建说明不匹配，并通过编译解决使用libcurl4-openssl-dev ，与构建指令匹配：

• 错误报告： https : =865624
• 构建说明： https :

也许 Ubuntu 也是如此，并且仍然使用错误的库构建，而不管上游版本更新如何？

@MichaIng感谢您提供详细信息。 我在我的 Raspbian 上遵循了“构建说明： https :

checking for LIBEVENT... configure: error: Package requirements (libevent >= 2.0.10) were not met:

No package 'libevent' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables LIBEVENT_CFLAGS
and LIBEVENT_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

稍后会尝试解决问题，并会在几天后在这里报告我是否遇到任何问题。

@谢尔盖-阿列克谢耶夫
如果您根据说明编译 libevent，我猜自定义编译会在 /usr/local/lib 中创建它，这可能不是传输编译然后查找它的默认路径的一部分。 也许ldconfig能够解决它。

但是，如果您使用的是 Raspbian Buster，则有可用的更新版本，应该可以使用，因为构建说明说“获取最新版本”和错误消息“libevent >= 2.0.10”。 在 Buster apt install libevent-dev安装 v2.1.8 应该可以工作。

@MichaIng感谢您的帮助。

是的，我使用的是 Raspbian Buster，我必须先安装它才能安装传输 2.94。

现在我遇到了另一个问题，我稍后会尝试解决（由于某种原因失败mkdir -p ）：

 /bin/mkdir -p '/usr/local/share/transmission/web/images'
/bin/mkdir: cannot create directory '/usr/local/share/transmission': No such file or directory
make[3]: *** [Makefile:408: install-dist_dataDATA] Error 1
make[3]: Leaving directory '/var/tmp/transmission-2.94/web/images'
make[2]: *** [Makefile:477: install-am] Error 2
make[2]: Leaving directory '/var/tmp/transmission-2.94/web/images'
make[1]: *** [Makefile:499: install-recursive] Error 1
make[1]: Leaving directory '/var/tmp/transmission-2.94/web'
make: *** [Makefile:510: install-recursive] Error 1

****  Installation failed. Aborting package creation.

将在这里发布我的进展以帮助其他人。

@谢尔盖-阿列克谢耶夫
这确实很奇怪，因为-p正是通过预先创建所有必需的父目录来解决这个错误。 当您手动调用此命令时，它是否也会失败？

@MichaIng

当您手动调用此命令时，它是否也会失败？

不，它成功了。

我在类似错误（ No such file or directory ）后多次手动创建必要的目录后成功。

在遇到一些问题后，我设法让它工作，然后删除了/etc/transmission-daemon/settings.json因为在构建它之后，配置文件似乎变成了.config/transmission-daemon/settings.json 。 现在它不能再工作了......所以可能稍后再试一次......

$ curl http://192.168.0.2:9091
curl: (7) Failed to connect to 192.168.0.2 port 9091: Connection refused

现在同时拥有/etc/transmission-daemon/settings.json和.config/transmission-daemon/settings.json时，运行sudo pkill -HUP transmission-da和sudo service transmission-daemon restart并没有帮助。

@谢尔盖-阿列克谢耶夫
请注意，它首先取决于命令行选项，其次取决于使用哪个配置文件的用户。 当您使用某个用户从终端运行时，将使用~/.config/transmission-daemon/settings.json或创建的配置目录（如果它不存在）。
或者可以使用命令行选项-g /path/to/config/dir来指定特定目录。

默认的 Debian 软件包，例如带有/etc/transmission-daemon/settings.json 。 但实际上用户debian-transmission将其主目录设置为/var/lib/transmission-daemon ，其中包含设置文件/var/lib/transmission-daemon/.config/transmission-daemon/settings.json ，它是/etc/transmission-daemon/settings.json的符号链接。 所以有点混乱循环来满足一些标准，如在运行用户家迪尔斯/var/lib/<name>和守护程序配置文件/etc/<name>与给定的可能性transmission-daemon二进制。
长话短说，当您进行自定义构建时不使用/etc/transmission-daemon ，因此您可以将其删除。

哪个用户运行守护程序（ systemctl cat transmission-daemon ）并且您是否确认您在其主目录（ getent passwd <username> ）中创建/编辑了正确的配置文件？

我仍然对mkdir -p错误感到困惑，特别是如果您使用相同的用户同时运行make和mkdir （手动预创建目录）。 我认为如果权限丢失，可能会出现此错误，但实际上只是尝试过，然后它会这样说而不是“没有这样的目录”......可能是一些我不理解的环境黑魔法🤣，但是，很高兴你设法完成了构建。

@MichaIng感谢您提供详细信息。 但是目前不知道为什么它不起作用。

sergey<strong i="7">@raspberrypi</strong>:~ $ systemctl cat transmission-daemon
# /run/systemd/generator.late/transmission-daemon.service
# Automatically generated by systemd-sysv-generator

[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/init.d/transmission-daemon
Description=LSB: Start or stop the transmission-daemon.
Before=multi-user.target
Before=multi-user.target
Before=multi-user.target
Before=graphical.target
After=remote-fs.target
After=network-online.target
Wants=network-online.target

[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
SuccessExitStatus=5 6
ExecStart=/etc/init.d/transmission-daemon start
ExecStop=/etc/init.d/transmission-daemon stop
ExecReload=/etc/init.d/transmission-daemon reload

我将传输守护进程作为sudo service transmission-daemon start 。 我有/etc/transmission-daemon/settings.json和~/.config/transmission-daemon/settings.json 。

我也对mkdir -p错误感到困惑。

@谢尔盖-阿列克谢耶夫
啊，这是一个 sysvinit 服务，它自动翻译成一个 systemd 单元。 是否有一些编译选项可以在安装时创建 systemd 单元？

至少有一个单位可用：

wget https://raw.githubusercontent.com/transmission/transmission/develop/daemon/transmission-daemon.service -O /etc/systemd/system/transmission-daemon.service
systemctl daemon-reload
systemctl enable transmission-daemon

但是不是必需的，sysvinit 也应该这样做。 要检查运行用户，然后：

cat /etc/init.d/ transmission-daemon

第一行周围的某个地方是一个 USER 条目。 然后可以使用以下内容查找用户的主目录，从而获取使用的配置文件位置。

getent passwd <username>

感谢您的帮助@MichaIng。 不幸的是，我没有成功构建传输。 所以我改回使用通过apt-get安装的transmission-daemon apt-get 。 这个问题很烦人，但还不如没有可用的种子。 希望有人能够成功构建传输并摆脱评论后的内存问题。

我在没有解决方案的情况下解决了这个问题。 在 Pi 4 4gb 上运行 Raspbain Buster。

我在没有解决方案的情况下解决了这个问题。 在 Pi 4 4gb 上运行 Raspbain Buster。

您是否尝试过@andreygursky的建议？ 这对我有用

我在没有解决方案的情况下解决了这个问题。 在 Pi 4 4gb 上运行 Raspbain Buster。

您是否尝试过@andreygursky的建议？ 这对我有用

我尝试了@javicacheiro解决方案，因为它应该在最新版本中解决。 但不幸的是，事实并非如此。 由于我很菜鸟，重新编译对我来说似乎很复杂。

# Prepapare
sudo apt remove libcurl4-gnutls-dev libssl-dev
sudo apt install libcurl4-openssl-dev libssl1.0-dev wget gcc cmake

# Download Transmission
wget https://github.com/transmission/transmission/archive/2.94.tar.gz
tar xf transmission-2.94.tar.gz
rm transmission-2.94.tar.gz
cd transmission-2.94

# Build
mkdir build
cd build
cmake ..
make

# Install
sudo apt remove transmission-daemon
sudo make install

@Lipown我还没试过，但这个脚本应该

• 卸载错误的 SSL 依赖项
• 安装好的 SSL 依赖项
• 安装（一些）用于编译的构建工具
• 下载传输 2.94
• 构建传输 2.94
• 卸载传输
• 安装传输 2.94（修复没有内存泄漏）

可能是它抱怨在构建过程中找不到依赖项，但这应该通过安装所述依赖项来解决。

# Prepapare
sudo apt remove libcurl4-gnutls-dev libssl-dev
sudo apt install libcurl4-openssl-dev libssl1.0-dev wget gcc cmake

# Download Transmission
wget https://github.com/transmission/transmission/archive/2.94.tar.gz
tar xf transmission-2.94.tar.gz
rm transmission-2.94.tar.gz
cd transmission-2.94

# Build
mkdir build
cd build
cmake ..
make

# Install
sudo apt remove transmission-daemon
sudo make install

@Lipown我还没试过，但这个脚本应该

• 卸载错误的 SSL 依赖项
• 安装好的 SSL 依赖项
• 安装（一些）用于编译的构建工具
• 下载传输 2.94
• 构建传输 2.94
• 卸载传输
• 安装传输 2.94（修复没有内存泄漏）

可能是它抱怨在构建过程中找不到依赖项，但这应该通过安装所述依赖项来解决。

谢谢。 我只是在执行第二行时出错。 输出是（对不起，它是从捷克语自动翻译的）：

795/5000
正在加载包列表...完成
创建依赖树
正在加载状态信息……完成
gcc 是最新版本 (4: 8.3.0-1 + rpi2)。
gcc 设置为手动安装。
git 是最新版本 (1: 2.20.1-2 + deb10u1)。
wget 已经是最新版本（1.20.1-1.1）。
wget 设置为手动安装。
无法安装某些软件包。 这可能意味着您需要
不可能的情况，或者如果您使用的是不稳定的分布
所需的包尚未创建或从传入队列中移出。
以下信息可以帮助您解决这种情况：

以下软件包具有未完成的依赖项：
libcurl4-openssl-dev：与：libssl1.0-dev 合并，但将安装 1.0.2q-2
E: 问题无法修复，有些包处于损坏状态。

没有，我一一安装没有报错，但是在编译和make之后，很不幸出现了很多错误

同样的问题。 解决了几个月，现在又回来了。

Debian 10. 传输 3.00

问题又来了，Linux raspberrypi 5.4.72-v7l+ Transmission-daemon 2.9.4。 至少这次它非常慢，需要几天时间才能最大化我的 1GB RAM，从闲置开始使用大约 250MB，在 Pi 上，幸运的是只是杀死了进程而不是我的 pi，所以我必须重新启动传播。

我注意到 oom-reaper 每周有几次杀死传输守护进程。我使用 prometheus 的 nodeexporter 实用程序来监视内存使用情况。它似乎以每分钟 13.6 Mb 的速度增长，直到它崩溃（20 分钟内从 458Mb 增加到 737Mb）现在。 我会监控，看看这是否会随着某个完成而改变。 我在 systemd 配置中添加了“Restart=always”，希望它能让问题不那么烦人

正如我现在所看到的，它以大约 8Mb/分钟的速度增长，当下载 6 个种子时，最终只下载 1 个种子，结果是一样的。

大约 400 个种子
传输守护进程 2.92 (14714)
debian9，kvm 来宾
内存：htop 报告总共 1.14Gb
基线是 151Mb 内存，传输在 1.07Gb 时被终止

$ file /usr/bin/transmission-daemon
/usr/bin/transmission-daemon: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=3fce1f657bdfb4b3730593a12abbdebc804621a1, stripped

使用 ssl 或 tls 搜索已安装的库：

$ find /usr/bin /usr/local/bin /bin -type f -perm /a+x -exec ldd {} \; | grep so | sed -e '/^[^\t]/ d' | sed -e 's/\t//' | sed -e 's/.*=..//' | sed -e 's/ (0.*)//' | sort | uniq -c | sort -n | grep -E 'ssl|tls'
  1 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2
  4 /usr/lib/x86_64-linux-gnu/libssl.so.1.1
  7 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
 16 /usr/lib/x86_64-linux-gnu/libgnutls.so.30

接下来，传输守护程序使用的库，加上 debian 包，它的版本和文件系统位置。

$ for i in $(ldd /usr/bin/transmission-daemon | cut -d " " -f3); do pkg=$(dpkg -S $i | cut -d":" -f1); ver=$(dpkg -s $pkg | grep -i     Version:); echo "$pkg $ver $i"; done
libminiupnpc10 Version: 1.9.20140610-4 /usr/lib/x86_64-linux-gnu/libminiupnpc.so.10
libnatpmp1 Version: 20110808-4+b1 /usr/lib/x86_64-linux-gnu/libnatpmp.so.1
libc6 Version: 2.24-11+deb9u4 /lib/x86_64-linux-gnu/librt.so.1
libevent-2.0-5 Version: 2.0.21-stable-3 /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5
libcurl3-gnutls Version: 7.52.1-5+deb9u12 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4
libssl1.1 Version: 1.1.0l-1~deb9u1 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
libsystemd0 Version: 232-25+deb9u12 /lib/x86_64-linux-gnu/libsystemd.so.0
zlib1g Version: 1:1.2.8.dfsg-5 /lib/x86_64-linux-gnu/libz.so.1
libc6 Version: 2.24-11+deb9u4 /lib/x86_64-linux-gnu/libpthread.so.0
libc6 Version: 2.24-11+deb9u4 /lib/x86_64-linux-gnu/libc.so.6
libnghttp2-14 Version: 1.18.1-1+deb9u1 /usr/lib/x86_64-linux-gnu/libnghttp2.so.14
libidn2-0 Version: 0.16-1+deb9u1 /usr/lib/x86_64-linux-gnu/libidn2.so.0
librtmp1 Version: 2.4+20151223.gitfa8646d.1-1+b1 /usr/lib/x86_64-linux-gnu/librtmp.so.1
libssh2-1 Version: 1.7.0-1+deb9u1 /usr/lib/x86_64-linux-gnu/libssh2.so.1
libpsl5 Version: 0.17.0-3 /usr/lib/x86_64-linux-gnu/libpsl.so.5
libnettle6 Version: 3.3-1+b2 /usr/lib/x86_64-linux-gnu/libnettle.so.6
libgnutls30 Version: 3.5.8-5+deb9u5 /usr/lib/x86_64-linux-gnu/libgnutls.so.30
libgssapi-krb5-2 Version: 1.15-1+deb9u1 /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2
libkrb5-3 Version: 1.15-1+deb9u1 /usr/lib/x86_64-linux-gnu/libkrb5.so.3
libk5crypto3 Version: 1.15-1+deb9u1 /usr/lib/x86_64-linux-gnu/libk5crypto.so.3
libcomerr2 Version: 1.43.4-2+deb9u2 /lib/x86_64-linux-gnu/libcom_err.so.2
libldap-2.4-2 Version: 2.4.44+dfsg-5+deb9u4 /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2
libldap-2.4-2 Version: 2.4.44+dfsg-5+deb9u4 /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
libc6 Version: 2.24-11+deb9u4 /lib/x86_64-linux-gnu/libdl.so.2
libselinux1 Version: 2.6-3+b3 /lib/x86_64-linux-gnu/libselinux.so.1
liblzma5 Version: 5.2.2-1.2+b1 /lib/x86_64-linux-gnu/liblzma.so.5
liblz4-1 Version: 0.0~r131-2+b1 /usr/lib/x86_64-linux-gnu/liblz4.so.1
libgcrypt20 Version: 1.7.6-2+deb9u3 /lib/x86_64-linux-gnu/libgcrypt.so.20
libunistring0 Version: 0.9.6+really0.9.3-0.1 /usr/lib/x86_64-linux-gnu/libunistring.so.0
libhogweed4 Version: 3.3-1+b2 /usr/lib/x86_64-linux-gnu/libhogweed.so.4
libgmp10 Version: 2:6.1.2+dfsg-1 /usr/lib/x86_64-linux-gnu/libgmp.so.10
libp11-kit0 Version: 0.23.3-2 /usr/lib/x86_64-linux-gnu/libp11-kit.so.0
libidn11 Version: 1.33-1+deb9u1 /lib/x86_64-linux-gnu/libidn.so.11
libtasn1-6 Version: 4.10-1.1+deb9u1 /usr/lib/x86_64-linux-gnu/libtasn1.so.6
libkrb5support0 Version: 1.15-1+deb9u1 /usr/lib/x86_64-linux-gnu/libkrb5support.so.0
libkeyutils1 Version: 1.5.9-9 /lib/x86_64-linux-gnu/libkeyutils.so.1
libc6 Version: 2.24-11+deb9u4 /lib/x86_64-linux-gnu/libresolv.so.2
libsasl2-2 Version: 2.1.27~101-g0780600+dfsg-3+deb9u1 /usr/lib/x86_64-linux-gnu/libsasl2.so.2
libpcre3 Version: 2:8.39-3 /lib/x86_64-linux-gnu/libpcre.so.3
libgpg-error0 Version: 1.26-2 /lib/x86_64-linux-gnu/libgpg-error.so.0
libffi6 Version: 3.2.1-6 /usr/lib/x86_64-linux-gnu/libffi.so.6

我在上面读到人们猜测 gnutls 是罪魁祸首 - 当我的系统上的软件包更新时，我抬头看了看。 我没有 memleaks 开始的确切日期，但如果我猜的话，它们可能是在libcurl3-gnutls:amd64 7.52.1-5+deb9u10之后开始的，因为问题并没有持续那么长时间。 这是在我的系统上安装/更新 gnutls 的日志（希望它是完整的）

$ cat * | grep installed | grep -E 'gnutls'
2020-10-31 00:11:44 status half-installed libgnutls30:amd64 3.5.8-5+deb9u4
2020-10-31 00:11:44 status half-installed libgnutls30:amd64 3.5.8-5+deb9u4
2020-10-31 00:12:04 status installed libgnutls30:amd64 3.5.8-5+deb9u5
2020-09-28 06:29:31 status half-installed libcurl3-gnutls:amd64 7.52.1-5+deb9u11
2020-09-28 06:29:31 status half-installed libcurl3-gnutls:amd64 7.52.1-5+deb9u11
2020-09-28 06:29:31 status installed libcurl3-gnutls:amd64 7.52.1-5+deb9u12
2020-07-30 06:13:32 status half-installed libcurl3-gnutls:amd64 7.52.1-5+deb9u10
2020-07-30 06:13:32 status half-installed libcurl3-gnutls:amd64 7.52.1-5+deb9u10
2020-07-30 06:13:32 status installed libcurl3-gnutls:amd64 7.52.1-5+deb9u11
2020-02-26 06:44:42 status half-installed libcurl3-gnutls:amd64 7.52.1-5+deb9u9
2020-02-26 06:44:42 status half-installed libcurl3-gnutls:amd64 7.52.1-5+deb9u9
2020-02-26 06:44:42 status installed libcurl3-gnutls:amd64 7.52.1-5+deb9u10

如果他们使用共享库重新编译，是否有人遇到过这个问题？

接下来，传输守护程序使用的库，加上 debian 包，它的版本和文件系统位置。

libcurl3-gnutls 版本：7.52.1-5+deb9u12 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4

这就是制造麻烦的原因。 传输应该在安装了 libcurl4-openssl-dev（而不是 libcurl4-gnutls-dev）的情况下构建。

@andreygursky我想我很幸运这并没有影响我很长时间，但对我来说，这个问题只在过去 3-4 个月才开始。 我在上面编辑了我的帖子，但在 2020 年 7 月 30 日，我从 2020 年 2 月 26 日的版本进行了更新。 我已经丢弃了上面日志的“半安装”部分，但如果我不得不猜测， 7.52.1-5+deb9u11引入了问题， 7.52.1-5+deb9u10很好

2020-07-30 06:13:32 状态已安装 libcurl3- gnutls:amd64 7.52.1-5+deb9u11
2020-02-26 06:44:42 状态已安装 libcurl3- gnutls:amd64 7.52.1-5+deb9u10

也许构建合并了新代码，但也许他们升级了构建操作系统或更改了构建选项？

当软件包在我的系统上更新时，我抬头看了看。

降级当然是最简单的解决方案。 但是 Debian oldstable 软件包可能只是因为安全问题才更新，因此只能在短时间内进行降级。

@andreygursky它的崩溃速度不足以使其无法使用，它只花了 1 小时就被杀死了。 我在 systemd 配置中添加了“Restart=always”，这样我就不必干预了。

我会等 20 分钟，看看内存增加的速度有多快，然后看看删除一些种子是否有帮助。

如果删除一些种子有帮助

相反，它是足够保证，以http小号纤夫没有太多的种子几乎同时公布。 您可以尝试阻止它们，然后在延迟一段时间后开始一个又一个。

完成后我让我的种子暂停（很遗憾）但是，但是即使种子暂停，传输也可以连接到跟踪器吗？

我删除了所有种子，它似乎停止增长，但停留在 460Mb（系统上使用的内存总量）。 我没有等太久，但重新启动它后，它又降到了系统使用的 109Mb 并且它似乎没有增长，所以是的，问题解决了。

如果最平滑的选项是在 50 之后删除所有内容，我想这会阻止播种：/但如果它使崩溃不那么频繁，我会接受它

但是即使在 torrent 暂停的情况下，传输也可以连接到跟踪器吗？

不，不应该。

试试这个https://github.com/raspberrypi/linux/issues/3210#issuecomment -716510916 - 我没有在传输上尝试过，但在我的情况下效果很好。

我的已经稳定了2天以上。 我认为我的问题实际上来自我的 Windows 机器上的 transgui。 如果我让它打开，它似乎会占用我 pi 守护进程的内存。 我为 transgui 使用 SSL。 编辑：我的意思是从传输远程 GUI 到守护程序的 SSL 调用。

@sirskills非常确定我可以确认这一系列事件.. 我的一直运行顺利，但一夜之间发生了崩溃。 我昨天没有下载任何东西，但我确实打开了传输远程 gtk 并且与服务器的连接使用了 TLS（虽然由 nginx 终止，而不是传输守护进程）

除了晚上 9.11 点外，昨天机器没有流量，之后流量开始上升。 我认为我当时没有对下载做任何事情..

@sirskills非常确定我可以确认这一系列事件.. 我的一直运行顺利，但一夜之间发生了崩溃。 我昨天没有下载任何东西，但我确实打开了传输远程 gtk 并且与服务器的连接使用了 TLS（虽然由 nginx 终止，而不是传输守护进程）

除了晚上 9.11 点外，昨天机器没有流量，之后流量开始上升。 我认为我当时没有对下载做任何事情..

我也在使用 nginx 反向代理，可能是什么。

我将尝试更进一步，随着时间的推移获得 nginx + 传输守护程序的内存使用情况，因为我们只是在上面看到内核与用户空间..

哦，但我只看到 oom-killer 获得传输守护进程 - 而不是 nginx。 所以我们需要看看transmission-daemon的内存的哪一部分在增长..

将记录 pid 的 smap 文件几个小时，看看发生了什么https://unix.stackexchange.com/questions/36450/how-can-i-find-a-memory-leak-of-a-running-process

哦，但我只看到 oom-killer 获得传输守护进程 - 而不是 nginx。 所以我们需要看看transmission-daemon的内存的哪一部分在增长..

将记录 pid 的 smap 文件几个小时，看看发生了什么https://unix.stackexchange.com/questions/36450/how-can-i-find-a-memory-leak-of-a-running-process

是的，我没有看到 nginx 的内存增加，只是传输守护程序。 不确定 pmap 是什么。

我可能必须重新编译传输守护程序以启用所有调试符号，当前没有行号，但这是附加到我正在运行的传输守护程序（通过 nginx 反向代理执行 TLS 终止）后 memleax 工具的报告https://gist .github.com/afk11/f97b25952016195f9944e8cee325a857

我在增长的内存区域上运行字符串（根据 pmap），开始有 torrent 文件名、一些跟踪器 url 等，但很快它就会移动到真正随机的字符串上。

在文件的最后，它完全是胡言乱语
就在它变得完全胡言乱语之前，我看到了这样的部分：
在 GDB 的内存转储上运行字符串：

// output trimmed
?dAA*
AplI0.
UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
8 AE
8&d 
// output trimmed

如果我们再滚动一点，我注意到一些批次的 UUUUU 以 LAME3.9something 为前缀

// cat dump-outputfile.dump | grep LAME
LAME3.98
$LAME3.98UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
LAME3.98
LAME3.98
*LAME3.98
LAME3.98
LAME3.93UUUUUU

可能不是很有帮助，稍后会尝试从源代码构建

我的已经稳定了至少 10 天了。 我所要做的就是确保我没有在我的 Windows 机器上打开我的传输远程 GUI。

即使使用“固定”的 Debian 版本 2.94-2 和 openssl 而不是 gnutls，我也遇到了这个问题。 它不像这里的某些人所经历的那样明显，但是传输守护程序仍然从 45MB RSS（这正是传输守护程序在 Windows 上使用相同数量的种子所使用的内存量）增长了 2-3 天到 180MB RSS。

随着传输守护程序 3.0 向后移植，我不再看到它。 初始内存再次大约为 45MB RSS，然后随着种子的添加和下载，它很快增长到 55MB。 但到目前为止，它相对稳定在 55MB RSS。

这是大约 650 个种子种子，顺便说一句。 如果内存使用以一种或另一种方式显着改变，我将进行编辑。

我只能建议你们从测试中提取 3.0 版。 由于依赖项很少，因此相对容易。 我没有看到任何问题。