页次: 1
因为PID=1的进程是/init而不是systemd,没法用systemctl,极度蛋疼。
依赖与systemctl的services全部没法用。。
离线
Systemd本身是作为pid 1设计的,而wsl的pid 1需要和windows侧通信,所以这种东西只能等ms解决。
如果是想要实现一个类systemd的daemon管理程序的话,那么有这么几个问题
1.windows的wsl安装是per user的,所以这个daemon必须在用户登录之后由某个东西启动。
同时,那个东西必须是一个windows侧的daemon,不然的话,如果那个东西结束,它打开的bash进程就会被结束,这样你所有linux侧的daemon都会结束。
2.你需要能通过那个windows侧的daemon和linux侧的daemon通信,然后每当你需要管理daemon的时候,都要用这个方法。
2的实现我大概能想到几种
比如说把stdio当作管道使用。但是这两个daemon中间隔着个bash,有些难受。
或者windows侧在随机tcp端口开个socket或者tls,用命令行参数传递给linux侧,然后linux侧连过去。类似这种的实现也是挺常用的了。
反过来linux侧在随机端口开socket或者tls,windows侧连接,这个看起来没上面那个好。
无论哪个办法,最后都会给你提供一个双向的pipe,这里面的协议就得自己设计了:-)
感觉对于个人来说不是一个很小的工程。。。
最近编辑记录 yw662 (2018-12-01 20:14:55)
ecmascript是世界上最好的语言
离线
感觉对于个人来说不是一个很小的工程。。。
看来还是原生的Arch好用,WSL什么的都是异端 (囧
离线
挖一挖,出来了一个解决方法。
https://www.oyohyee.com/post/note_wsl2_systemd
离线
Wsl2按说不会有这个问题才对吧。wsl2不直接是虚拟机吗。
ecmascript是世界上最好的语言
离线
Wsl2按说不会有这个问题才对吧。wsl2不直接是虚拟机吗。
因为它是Windows Subsystem for Linux,不是Linux。
我的猜想是:为了能够实现integration with Windows,一部分魔法被实现在了Microsoft provided init中,这个init是无法被替换的。
理论上更合适的方案是实现一个内核模块在内核态与Windows通信,但这个设计实现更困难(但至少比WSL1完全实现NT与Linux共存要容易得多),而且会禁止用户使用自定义内核(目前的WSL2是可以自定义内核的)。而用户态实现则方便的多,代价就是init必须由微软提供不能被替换。
反社会,精神极其不稳定,随时可能炸碎身边所有人
离线
一个看法是,你应该将WSL(即使是WSL2)看作一个完整的OS,不是一个Linux虚拟机,有一部分组件是不能替换的,应用商店中的Linux发行版都是这个OS上的app
反社会,精神极其不稳定,随时可能炸碎身边所有人
离线
页次: 1