或者在 do 前面塞一个分号也行

while read port do ... done

do 是不是得单独一行（

> <@telegram_1819101483:nichi.co> 现在网易云用什么客户端好 go-musicfox（

是我打错字了吗（）

[m.image] image.jpeg

（死掉

* 大概率是新版qq一直挂后台的bug（

kmscon中alt粘滞的问题如何解决（

大概率是新版qq的bug（

还在思考

好好好

https://music.163.com/st/webplayer

维护积极

试试 feeluown-netease

* 新web界面

新wab界面

现在网易云用什么客户端好

好，我手敲一下，现在只有 tty 是工作的，终端打不开（

跑这个脚本看看

sudo ss -x src "*/tmp/.X11-unix/*" | grep -Eo "[0-9]+\s*$" | while read port do sudo ss -p -x | grep -w $port | grep -v X11-unix done | grep -Eo '".+"' | sort | uniq -c | sort -rn

现在它还开着并且正常工作

装了，linuxqq from aur

你装了 qq 吗

我那个打不开任何程序 no qt platform plugin could be initialized 的问题复现了 这次是早上九点出门挂机挂到刚刚回来，一回来就这样了，没有睡眠或休眠，没有用过远程软件，tty 可以正常工作

服务器想偷个懒)

可以 起来了

* 你不能 libgit2 也先用 extra 里的吗

直接装arch的不就行了

你不能 libgit2 也用 extra 里的吗

😢只能等更新了

所以是 libgit2 的问题

[m.image] image.jpeg

lddtree /usr/bin/eza 看看？

我看看手动编译

刚刚cachyos的坏了 然后我试了下安装arch官方的包也是坏的 好奇怪

但是我这是arch官方仓库的包欸 奇怪

[m.image] image.jpeg

应该是cachy的构建慢了

你的也坏了?

你不说我还真没发现

[m.image] 我看我的eza和llhttp都是arch官方仓库的🤔

[m.image] 请问有人在用eza吗 我这个cachyos刚刚更新了下系统 找不到 libllhttp.so.9.2 现在系统只有这些 ❯ /bin/ls /usr/lib/libllhttp.so* /usr/lib/libllhttp.so /usr/lib/libllhttp.so.9.3 /usr/lib/libllhttp.so.9.3.1

倒逼上游更新了属于是

可能外面得用systemd的ProtectProc=ptraceable包一层？

突然想到，bwrap是不是不支持使用procfs的hidepid参数……要是没有pidns，他会把host的/proc直接bind进去

你用 waitpid(-1), 就需要额外的数据结构来保存 exit status 了

大部分程序都不会调吧，除非是专门考虑过这个问题的，需要长时间运行并且会调用不可预期的子命令的 daemon.

最好还是不要假设程序都会照顾好非亲生子女吧

* 不使用pidns的话有systemd兜底倒是确实也不需要……

有些程序你给它未预期的子进程，你信不信它死给你看？

为什么要调用 waitpid(-1)？

不使用pidns的话有系统init兜底确实也不怎么需要……

但是这种情况主程序真的不会回收吗？很多程序不会调用waitpid(-1)？只会调用waitpid(child_pid)？

哦。使用了pidns的话，主程序run as pid1，孙进程应该会被reparent到主程序而不是systemd --user…

*另外 `systemd --user` 也不是 pid 1 啊*

是在 pidns 里面的 pid 1 负责回收

它又不在 pidns 里面

外面还有systemd --user啊

不是程序的问题。普通的程序并不需要考虑 wait 孙进程的问题，但 pid 1 需要。

哦，不过主进程没退出systemd是不是就不wait了……但是我觉得这应该是程序自己的问题。

多数主程序应该会wait子进程的吧，可能孙进程会变僵尸？那样的话也会被systemd收养吧。

主进程退出之前可能会造出来很多僵尸进程

还没研究这个，我猜没啥问题，pid1只是要负责wait子进程，但是沙盒外面还有systemd --user的，本来就打算主进程退出后让这些东西一起去死的。 嗯，只是猜测。

而且开启pidns后会fork是expected，毕竟Linux内核不允许进程更改自己的pidns。

那样行为会有问题的，绝大部分程序不会想到自己要成为 pid 1

这个倒是明确可以用--as-pid-1关掉吧

嘛，不过某些程序确实是可以杀死bwrap的，bash不行，dolphin可以，我估计还是什么controlling terminal之类的玩意在发信号。

我觉得这是徒劳（

开了 pidns 的话在沙盒内也会有一个 fork 出来的 bwrap 进程，cmdline 和父进程一样但是作为 pidns 内的 pid 1 进程，只收养孤儿进程

强迫症呗，不想要多余的进程，想要一个in process沙盒。 其实留着它的json-status-fd获取状态汇报给systemd用也挺好的。

[m.image] 我这里一堆 bwrap 呢

为什么要杀死 bwrap 啊

* 内核有相关文档具体描述这个行为吗？

嗯……不太想看源码了。 探索路线太长了…… 不满意portable微信创建太多cgroup且仍然创建不知用途的.config/profiles → 试图直接用systemd沙盒化程序发现xdg-dbus-proxy需要跟程序本体使用不同的运行环境 → 想起https://forum.archlinuxcn.org/t/topic/15039 → 强迫症犯了研究bwrap并试图在它启动程序后杀死bwrap并保持程序运行 → bwrap的具体行为太有意思想看但是脑袋发烧到疼了

不太清楚

内核有相关文档具体这个行为吗？

但这个确切行为也没那么重要，弄清楚顺序就足够了

可能是对根目录的处理？算了不瞎猜了（

那就是内核行为了，我也不是很清楚具体原因，总之确实是这么个行为，可能是安全措施吧

O.o

我的意思是，我觉得不管顺序如何，写了--dev-bind应该总会比只写--bind 多一些挂载点，但我测试的结果是--dev-bind写在后面会多出来，写在前面就不会多出来

因为 bwrap 的 --bind 实际上是 rbind，非特权 user namespace 只允许 rbind

“覆盖”只是文件系统树看上去看不见之前挂载点里的东西而已吧，之前的挂载点不应该消失吧。

但是/proc/self/mountinfo里看不见更多的挂载点啊。按理说反过来写应该会看见两个/dev吧

后挂载的挂载点会覆盖先挂载的，而不是“自动合并”

是 --bind / / 把之前的挂载点覆盖掉了

明显顺序错了（

* 当简化的版本控制器在用(

当简化的版本控制器再用(

咱btrfs10分钟一个快照

* 但是反过来写不应该比单纯写`—bind / /` 多出一些 `/dev`挂载吗？还是说在先处理`—dev-bind`的时候挂载点不存在它也不创建？

* 但是反过来写不应该比单纯写`—bind / / 多出一些/dev`挂载吗？还是说在先处理`—dev-bind`的时候挂载点不存在它也不创建？

快照？btrfs吗

但是反过来写不应该比—bind / / 多出一些挂载点吗？

哦，它是完全按参数顺序挂载的……

难道不是你的参数写反顺序了的原因吗

在 rm 前面加 echo 来检查

[m.image] 直接截个图说一下具体复现办法好了。为什么这里面全是nodev挂载呢？

你可以去让别的LLM再检查一下