opentracker服务器一直崩溃怎么办？改用2024年发布的完美稳定版，c语言永远是最强的

小樱

opentracker服务器一直崩溃怎么办？改用2024年发布的完美稳定版，c语言永远是最强的

c语言永远是最强的，就是代码不熟练的话，容易空指针崩溃，帮他修了好多，2024年的时候才给崩溃修好了，最近他又开始写崩溃代码了

这些代码全是我给他修的，把所有的问题都解决了




下方文本是对于崩溃的相关解答，摘选自 https://github.com/ngosang/trackerslist/issues/640 由于对方发的是英语，我在帖子中没有列出上下文，有条件建议看原文

你当前运行的opentracker提交代码太新，有一个崩溃问题，我正在联系作者共同修复，为了避免你出现崩溃，建议直接运行2024版

https://erdgeist.org/gitweb/opentracker/commit/?id=5d2033ac8932d223a00d7d6e29cedd9b2e23bc7f

崩溃报告中指向触发的崩溃函数是iob_reset，崩溃报告文件中 #1提到了 opentracker.c:162

1. Program received signal SIGSEGV, Segmentation fault.
   
2. 0x0000000000410fb0 in iob_reset ()
   
3. Missing separate debuginfos, use: debuginfo-install glibc-2.17-326.el7_9.3.x86_64 libzstd-1.5.5-1.el7.x86_64 zlib-1.2.7-21.el7_9.x86_64
   
4. (gdb) bt
   
5. #0  0x0000000000410fb0 in iob_reset ()
   
6. #1  0x000000000040275b in handle_dead (sock=95) at opentracker.c:162
   
7. #2  0x0000000000402a35 in handle_write (sock=95) at opentracker.c:227
   
8. #3  0x0000000000402d72 in server_mainloop (args=0x0) at opentracker.c:328
   
9. #4  0x0000000000404173 in main (argc=15, argv=0x7fffffffe4f8) at opentracker.c:806
   
10. (gdb) t 2
    
11. [Switching to thread 2 (Thread 0x7ffff731f700 (LWP 23051))]
    
12. #0  0x00007ffff73e59fd in nanosleep () from /lib64/libc.so.6
    
13. (gdb) bt
    
14. #0  0x00007ffff73e59fd in nanosleep () from /lib64/libc.so.6
    
15. #1  0x00007ffff73e5894 in sleep () from /lib64/libc.so.6
    
16. #2  0x0000000000403d61 in time_caching_worker (args=0x0) at opentracker.c:645
    
17. #3  0x00007ffff76f5ea5 in start_thread () from /lib64/libpthread.so.0
    
18. #4  0x00007ffff741eb0d in clone () from /lib64/libc.so.6
    
19. (gdb) t 3
    
20. [Switching to thread 3 (Thread 0x7ffff6b1e700 (LWP 23052))]
    
21. #0  0x00007ffff73e59fd in nanosleep () from /lib64/libc.so.6
    
22. (gdb) bt
    
23. #0  0x00007ffff73e59fd in nanosleep () from /lib64/libc.so.6
    
24. #1  0x00007ffff74162d4 in usleep () from /lib64/libc.so.6
    
25. #2  0x0000000000409b01 in clean_worker (args=0x0) at ot_clean.c:131
    
26. #3  0x00007ffff76f5ea5 in start_thread () from /lib64/libpthread.so.0
    
27. #4  0x00007ffff741eb0d in clone () from /lib64/libc.so.6
    
28. (gdb) t 4
    
29. [Switching to thread 4 (Thread 0x7ffff631d700 (LWP 23053))]
    
30. #0  0x00007ffff76f9a35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
    
31. (gdb) bt
    
32. #0  0x00007ffff76f9a35 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
    
33. #1  0x000000000040627b in mutex_workqueue_poptask (tasktype=0x7ffff631cf04)
    
34.     at ot_mutex.c:143
    
35. #2  0x000000000040a847 in fullscrape_worker (args=0x0) at ot_fullscrape.c:73
    
36. #3  0x00007ffff76f5ea5 in start_thread () from /lib64/libpthread.so.0
    
37. #4  0x00007ffff741eb0d in clone () from /lib64/libc.so.6
    
38. (gdb)
    

复制代码

请使用2024-05-10的提交代码，这是一个经过我验证的稳定版，或者在网站下载完整包 opentracker-1.0.tar.bz2
https://erdgeist.org/gitweb/opentracker/commit/?id=59c1c30107ccba4c633ae7ca11c3249c88719e83

虽然你目前没有遇到系统优化上的问题，也建议你提前做准备，或者后续优化参考
抄一下系统参数优化吧，你这个还没加入tracker list就已经爆炸了，经过我的帖子上提到的系统内核优化你才能和我一样稳定运行3000w peer同时在线高并发稳定不出问题
这份提交代码优化有效提升大概220%的cpu性能
在3000w peer高并发的情况下，cpu占用率从20%平均使用率下降为10%
https://github.com/1265578519/OpenTracker/commit/0eeb496a141b600b876a9bcb6169704c5edfa428
这份提交可以成功在1核1G的vps上运行千万级peer高并发
https://github.com/1265578519/OpenTracker/commit/c68e9eb0256b72cd0babd9e5adc0a88a71a38975

系统优化参考
https://bbs.itzmx.com/thread-115998-1-1.html
https://bbs.itzmx.com/thread-18214-1-1.html

仓库链接
https://github.com/1265578519/OpenTracker

想加入list的话，唯一还需要注意的是可能还需要购买一个1.88美元每年的域名，注意续期价格，除非你想每年新注册一个域名
不然仓库管理者可能因为使用免费duckdns共享域名而拒绝加入，我不确定，因为在trackers_all.txt上看到有其它人运行的免费域名
https://www.namesilo.com/pricing.php?rid=1a41e23ri
https://www.namecheap.com/?affId=87950

很高兴看到你成功修改ulimit的1024限制并且执行 /sbin/sysctl -p 后，现在正常了！

1. ulimit -n 1048576
   
2. echo "* soft nofile 1048576" >> /etc/security/limits.conf
   
3. echo "* hard nofile 1048576" >> /etc/security/limits.conf

复制代码

ping在线检测看到现在没有因为系统限制产生的丢包和高延迟现象发生了
一般来说是禁用防火墙nf驱动模块，不过你已经修改提高了数值，那么解决丢包效果是相同的，不关闭防火墙唯一的缺点是占用一定的ksoftirqd内核cpu消耗，你设置调整数值后同样可以成功解决丢包问题，我推荐的做法是直接禁用防火墙避免加载相关驱动
net.netfilter.nf_conntrack_max = 1048576

禁用防火墙降低cpu使用率的话

1. yum -y install iptables-services;service ip6tables stop;chkconfig ip6tables off;service iptables stop;chkconfig iptables off;systemctl stop firewalld;systemctl disable firewalld

复制代码

从上方评论得知你域名DNS添加了AAAA记录，代表你启用了ipv6，系统默认值是4096，虽然此数值比1024更高，但是为了预防也可以提前修改为2147483647

1. echo "net.ipv6.route.max_size = 2147483647" >> /etc/sysctl.conf

复制代码

最后一个tcp socket分配orphans端口时，同样系统默认值是4096，可以提高上限值

1. echo "net.ipv4.tcp_max_orphans = 100000" >> /etc/sysctl.conf
   
2. echo "net.ipv4.tcp_orphan_retries = 3" >> /etc/sysctl.conf

复制代码

现在你可以在DigitalOcean上承载3000w用户的高并发同时在线，取决于内存大小，大约消耗4G
如果未来你因为vps内存不足想要在不升级服务器配置的时候，限制内存保持tracker服务稳定运行随时联系我
https://bbs.itzmx.com/thread-18214-1-1.html

ngosang 你现在可以添加他的tracker到list中了

其实对于ipv6，我喜欢用另一个二级域名
因为客户端只会对tracker服务器域名其中一个ip地址发起请求，如果客户端发起请求为ipv6，那么其它人则找不到他对应的ipv4地址
你可以增加一个记录值为 tracker.vito-tracker.space 指向AAAA， vito-tracker.space 仅设置A，当然这会导致客户端产生两次网络请求，服务器每月流量传输消耗会翻倍消耗配额，根据你的喜好来，这并不是一个建议

some trackers reply with ipv4-mapped entries in the ipv6 reply.

你提到的这是一个bug，通过这种方式取得回应的peer是错误的，复现方式为

1. 首先添加tracker服务器ipv6 announce，在添加ipv4 announce，他获得了几个错误的peer

复制代码

我在2024年已经和opentracker作者共同修复这个bug，我这还存有当时的bug复现视频
https://github.com/1265578519/OpenTracker/assets/6442439/3e6c62b1-be18-4d7e-a014-d54cf097c7a8
建议所有使用udp tracker的人，都更新到这个提交修复bug
https://erdgeist.org/gitweb/opentracker/commit/?id=59c1c30107ccba4c633ae7ca11c3249c88719e83
这人当前运行的旧版代码有bug，需要和他联系让他更新版本，但是没有他的联系方式
这是一个题外话了，不应该在楼主的 Add new tracker 中回复，应该等待 ngosang 来添加
ipv6 peers二进制数据按照协议是在“peers6”节点返回，总之这是因为在ipv4请求上返回了peers6字段引起的bug，在2024版本的opentracker中，使用了bep15来进行修复这个bug
https://www.bittorrent.org/beps/bep_0015.html
而且udp通过peer6返回时，每用户字节为18，是ipv4的6字节3倍大小，不符合udp开销小而快的设计目标，必须要更新修复
这是需要在tracker服务器上更新解决bug的，不然没办法兼容现存的所有bt客户端，让所有人更新bt客户端版本去解析这个字段不太现实，而且还没有任何一款bt客户端实现你说的解析方案，而且还有上面提到的udp出现3倍流量消耗问题
总之运行2024年的opentracker，在连接udp tracker的过程就没有这个bug了，已经成功修复

ngosang终于上线了！看来他一个月登录一次
现在你已经添加到了list中，明天这个时间点会达到访问量最大值（种子客户端每24小时更新一次txt）
看你购买了hetzner的云服务器虽然价格更便宜，但是他们有极其严格的人工策略管理和Connection Limit，可能并不适合tracker
https://www.hetzner.com/cloud?country=us&pk_medium=referral-program&pk_content=BQ5CnV5sfsaV
https://docs.hetzner.com/cloud/firewalls/overview/#limits
如果明天你突然网络丢包了，不用怀疑，是宿主机发生Connection Limit或者人工在后台限制，丢包问题没有发生在你服务器系统上
添加到ngosang list上24小时后，运行很稳定，当前没有任何问题，当前服务375w用户活跃在线

dead

确实死了，我分析了一下，在ipv4上正常工作，ipv6上离线（tcp端口未打开）
所以对于ip双栈，还是最好分成tracker1、tracker2两个二级域名，来观察情况
直接访问他的tracker服务器ipv4，发现他搭建了一个网站 https://ip/ 跳转到 https://域名/
可能是他配置了docker环境搭建了一个网站，导致防火墙被异常重新打开，需要重新关闭下系统防火墙
我不知道 楼主 是否还在查看评论区，如果还在看的话可以修复一下tracker

从mode=everything上看版本信息，你当前运行的提交代码不对
并不是 https://erdgeist.org/gitweb/opentracker/commit/?id=59c1c30107ccba4c633ae7ca11c3249c88719e83
你要重新下载源代码编译一下

由于故障持续了一天，你当前被 ngosang 从 trackers_best.txt 删除列表，现在你分配的流量会有所下降

在Ubuntu 24编译libowfat 0.32会遇到错误，在较新的系统上应该使用libowfat 0.33文件夹来成功编译文件
仓库当前libowfat文件夹（版本号为0.32），Ubuntu 24在使用 cd libowfat 进入目录的上方插入并且运行这段代码

1. rm -rf libowfat;mv libowfat-0.33 libowfat

复制代码

不过看你描述你已经成功解决了，不过你打补丁去编译的方式有点奇怪。。。
当前你的tracker服务器正常工作

其实进程不用分离，主要是域名DNS记录要分成2个二级域名去分别解析A、AAAA
你当前分的是 @ 和 v6，现在解析方式是正确的

原因是BT客户端并不会因为ipv6故障转而请求服务器的另一个ipv4地址，客户端始终发起请求为ipv6

使用tracker1、tracker2两个二级域名的时候，唯一的缺点是用户一个种子会有2个网络请求，上方也有提到过

是的，我与作者编写的opentracker源代码正式稳定版时间是发布在2024-05-10，对于关闭DWANT_NO_AUTO_FREE选项，则必须要用libowfat 0.34但发布在2024-10-31这个时间，我默认把这个编译选项打开以便适配旧版本操作系统来获取更多的进程可用内存，在512M或者1G内存的vps上可稳定运行。
我们先写完opentracker代码，后续让libowfat作者来更新适配，总之打开DWANT_NO_AUTO_FREE可以在libowfat 0.31及后续版本正常工作，想要关闭这个编译参数则最低版本必须使用0.34，在注释上有说明

我的仓库里确实有一些特别的cpu优化，作者说这些优化代码只能存在特定的分叉仓库上，没有合并到erdgeist上游仓库中

对于'MarkScan'机器人恶意使用Python脚本批量发DMCA投诉邮件实际上没有什么好的解决办法

两种方案
更换服务商，一些服务商不听你做解释，他们要看到的是需要没有收到DMCA邮件，不管对方是否真实，更换服务商是最好的解决办法，因为无法与其沟通

通过域名智能DNS解析，额外添加记录值去限制某些国家解析，让其解析到127.0.0.1或者其它任意ip，此时机器人的投诉邮件就不会发送到真正运行的服务器上，这么做就是这个国家没办法连接到tracker了

你先尝试和服务商沟通吧，你添加hash黑名单也不能真正解决问题，就算服务器关机十天，这个机器人只要在互联网上扫描到tracker，那么会无休止的一直发投诉邮件

参考资料
https://bbs.itzmx.com/thread-102072-1-1.html
https://x.com/MarkScandigital/status/1776145726998769954
https://x.com/MarkScandigital/status/1776145731738349707
推上的原话
引用: 将打击 Torrent 盗版的斗争推向新高度！
MarkScan 拒绝向数字盗版（尤其是种子盗版）屈服！我们的团队已经设计了一些主动策略来破坏世界上的种子公共tracker追踪器。
我们的主动方法包括向 OpenTracker 等平台发送 DMCA 删除通知，在过去一年中影响了超过 30 万个有问题的种子tracker跟踪器哈希值。我们的团队相信要付出更多努力，确保探索新的干扰措施。