Filipe Pina's questions

我正在运行一个基于 image 的容器linuxserver/radarr:3.0.0.3095-ls12。
一旦我将标签/版本更新到linuxserver/radarr:3.0.0.3807-ls24应用程序停止工作。

经过一点调试后，我注意到date这张图片中的行为很奇怪：

$ docker run --rm --entrypoint "" linuxserver/radarr:3.0.0.3807-ls24 date
Fri 20 Feb 1970 03:17:15 AM UTC
$ docker run --rm --entrypoint "" linuxserver/radarr:3.0.0.3807-ls24 date
Sun 01 Mar 1970 09:09:15 AM UTC
$ docker run --rm --entrypoint "" linuxserver/radarr:3.0.0.3807-ls24 date
Thu 19 Feb 1970 09:04:59 AM UTC

但老不

$ docker run --rm --entrypoint "" linuxserver/radarr:3.0.0.3095-ls12 date
Sat 10 Oct 2020 12:15:09 AM UTC

冥想了一段时间后，假设时钟中有某种奇怪的黑魔法，决定运行它以--privileged获得完全/原始访问权限

$ docker run --rm --entrypoint "" --privileged linuxserver/radarr:3.0.0.3807-ls24 date
Sat 10 Oct 2020 12:16:22 AM UTC

它运行良好（应用程序也运行良好，但对这个问题并不重要）。

我已经浏览docker history了这两个图像，但是很多COPY并且RUN curl在构建之间可能会产生不同的结果。尽管如此，我认为没有人（图像维护者）会想要破坏日期，所以它一定是他们无法控制的（没有libfaketime找到）......

这是一个多架构图像，这些结果来自树莓派（因此图像的 arm 构建）。在我的 amd64 linux 笔记本电脑中，date即使没有特权，最新的图像也能正确报告...

会是什么呢？由于无法使用该--privileged标志，我什至如何开始调试它？

自从我得到这个新路由器并用dd-wrt ​​刷新它后，我就遇到了这个问题。
它并没有真正的影响（我会描述这个场景），但我很好奇......

这是网络设置的示意图：

• 在通过 WiFi 连接的 VMware Fusion（在 Mac/OSX 主机中）上运行的 Manjaro Linux
• 3 个树莓派（运行 Raspbian）连接到交换机 1（然后是路由器）
• 1 NAS (WDCloud) 连接到交换机 1
• 1 个树莓派连接到交换机 2（连接到交换机 1）

鉴于设置，问题：

• Mac over WiFi，Manjaro VM 处于桥接模式
  • ping 4 个 Pi 中的任何一个都显示在 5 分钟内丢包 - 有时 20%，有时更多
  • ping NAS 显示完全没有丢包
• Mac over WiFi，Manjaro VM 在 NAT
  • 任何场景都不会丢包
• Mac over LAN、Manjaro VM 处于 NAT 或桥接模式
  • 任何场景都不会丢包

所以，我最初的猜测是它与 Fusion 桥接模式有关，因为直接从 Mac（主机）ping 从来没有任何损失（也没有使用带有 NAT 的 VM）。

• 尝试过 Virtualbox，同样的情况（桥接显示丢包，NAT 没有）。
• 使用 DDWRT WiFi 设置玩了很多，但似乎没有任何区别。

意识到 ping NAS 没有丢包，所以它看起来只是桥接+WiFi+Raspberry 组合中的东西，所以我tcpdump icmp在其中一个树莓上运行并开始从 VM ping

虚拟机中的 Ping 输出：

64 bytes from  (192.168.1.22): icmp_seq=13 ttl=64 time=2.40 ms
64 bytes from  (192.168.1.22): icmp_seq=14 ttl=64 time=2.50 ms
===> lost sequences 15 to 42 <===
64 bytes from  (192.168.1.22): icmp_seq=43 ttl=64 time=34.1 ms
64 bytes from  (192.168.1.22): icmp_seq=44 ttl=64 time=2.31 ms

Pi 中的 tcpdump 输出：

01:24:42.397835 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 13, length 64                                    
01:24:42.397919 IP 192.168.1.22 > stretch: ICMP echo reply, id 436, seq 13, length 64                                      
01:24:43.399899 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 14, length 64                                    
01:24:43.399948 IP 192.168.1.22 > stretch: ICMP echo reply, id 436, seq 14, length 64                                      
01:24:44.404887 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 15, length 64                                    
01:24:45.422542 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 16, length 64                                    
===> requests hit but no replay is sent... <===
01:25:12.044102 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 42, length 64                                    
01:25:13.068516 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 43, length 64                                    
01:25:13.099164 IP 192.168.1.22 > stretch: ICMP echo reply, id 436, seq 43, length 64                                      
01:25:14.071065 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 44, length 64                                    
01:25:14.071129 IP 192.168.1.22 > stretch: ICMP echo reply, id 436, seq 44, length 64                                      

结论（我认为）：ping 请求命中树莓派，但没有发送回复（在那段时间，大约 30 秒）。
我正在使用 ping，因为它最容易显示/测试数据包丢失，但 TCP 也会发生这种情况，因为 SSH 会话时不时挂起。

关于检查树莓派配置以了解它为什么不发送 ICMP 回复的任何提示？它使它看起来与 Pi 相关，但是为什么在其他场景（Mac WiFi + VM 桥接）中不会发生这种情况，因为 Pi 保持不变？