@fuis
@Still4
至少 yum-3.4.3-168.el7.centos.noarch 是能正确处理 sigint 的，所以留了个 pid 文件大概是别的原因

#6 > 可能是因为有其他锁的存在
问题不是锁，问题是判断锁是否有效的机制太简单了，就是看看 pid 文件里面的 pid 是不是对应正在运行的进程，这东西容易出现巧合。
要是一开始就用锁反倒不会出现重启之后还不能 yum 的问题（ flock 之类的肯定重启就释放了）

> 为甚麽按 ctrl+c 跟 ctrl+z ，无法解除 yum 进程锁定
理论上 yum 退出会正确的清理 pid 文件才对（但是是 sigkill/断电/crash 掉了的情况 yum 肯定没机会清理），就算没能清理，下一个 yum 启动的时候也会检查对应的 pid 是否是正在运行的进程，如果 pid 对应正在运行的进程就会等它退出。

所以出问题的情况就是 yum 没正常退出导致 pid 文件没清理（ bug ），然后 pid 文件记载的 pid 恰好被别的进程用了，判断逻辑搞不清楚究竟是不是有正在进行的事务于是放弃了（巧合）。

> 有甚么方法可避免 yum 进程锁定的发生?
改源码，做掉整个 lock 机制然后责任自负（同时两个包管理同时跑可能把系统或者包管理元数据搞坏，这个 lock 就是保证用户不能这么干）
或者给它改成用 flock 这样的机制来锁，这样子就会避免 pid 回收/恰好重启后 pid 被用了的巧合

其实我很好奇为什么 yum 不一开始就用 flock 之类的东西来做锁...

我猜要用到内核态的虚拟网卡驱动然后没有 windows arm64 的版本就挂了

这么新的设备要不要试试用一用 f40 的预发布版本看看

@liyafe1997 文件加密在
https://source.android.com/docs/security/features/encryption/file-based
它的密钥被
https://source.android.com/docs/security/features/keystore
保护
一般 keystore 的众多安全要求由 TEE 固件以及
https://en.wikipedia.org/wiki/Replay_Protected_Memory_Block
保护。

@liyafe1997 不行，tee 的数据在闪存的特殊区域上(rpmb)，这个区域实现上（通过密码学的手段）保证了绑定 SOC ，并且防篡改，重放和伪造。

简单的说结论就是除非你能拿到 SOC 里面的一些 key ，否则你不可能有效的备份 rpmb 区域。甚至从 Linux kernel 那边应该碰不到这些分区。

因为除了 libc 内部之外不需要接触到 DIR 这个结构的成员

结构体的定义就是告诉编译器，结构体的成员排布（每个成员的偏移，结构体的大小），要是编译器用不到这些信息就不会要求必须看到定义。（ C++ 管这叫做 odr-use ，但是不知道 C 有没有类似的术语，也可以类比前向声明的时候不需要具体定义）

要是没有用到具体定义的翻译单元，就没必要让编译器看到结构体的定义。然后包含这个结构体的定义的头文件大概没有被发布出来，只是被一些内部函数的定义的代码用到了（就是编译 libc 的时候有，但是在 libc 安装的时候没有被拷贝出来）。

targetSDK 是 33 ，在高版本 Android 上可以单独给相册权限

感觉是 jit 的活

得看解析的啥域名

记得 deepin 有魔改加自己的 pam 模块，可能是什么 pam 涉及用奇怪的方式处理密码然后没处理对？

--metrics 0.0.0.0:8000 没必要开，是在 8000 开一个 metrics 服务器，可以监控 cloudflared 的状态
--edge-ip-version 6 是用 ipv6 连接 cloudflare

@ljq29 `--protocol http2` 在 tunnel 后面
比如我的 docker cmd 就是 tunnel --protocol http2 --metrics 0.0.0.0:8000 --edge-ip-version 6 run --token ...

@cxsz 用甲骨文的 arm 实例，至少 1Gbps 能保证了

还有这东西会默认 quic/udp ，我刚看了下在我这儿切换到 http2 能快好几倍

要是 ipv4 慢可以试试 ipv6

ip -s -s link show <devname>
以及检查下
/proc/net/softnet_stat
看看有无因为网卡接收缓冲区爆掉了导致的丢包