-
Notifications
You must be signed in to change notification settings - Fork 373
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: update some logs on extension host process service #2173
Conversation
这个配置名没想好,大概列一下,感觉可以投个票:
或者短一点的
|
默认关闭?通信恢复后如果插件进程没有被杀死,应该能直接重连 |
@hacke2 默认关闭的话常规用户使用就会出现大量僵尸进程,集成侧自行配置吧,正常情况应该是链接数量与插件进程相对应的才对。 |
这个直接断开有点粗暴,用户刷新下页面啥都没了。 要不然:过了五分钟还没有人连接,就清理进程。 |
你们出现过僵尸进程的情况吗?我们好像没有出现过 |
现在就是这个逻辑,这个时间集成方可以自动定义 |
Docker 环境下很容易复现这个问题,参考项目 https://github.com/opensumi/ide-startup |
Codecov ReportBase: 57.79% // Head: 57.77% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #2173 +/- ##
==========================================
- Coverage 57.79% 57.77% -0.03%
==========================================
Files 1313 1315 +2
Lines 82995 83012 +17
Branches 17254 17266 +12
==========================================
- Hits 47970 47963 -7
- Misses 31835 31854 +19
- Partials 3190 3195 +5
Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
试了一下,这个修改并不能修复僵尸进程问题,就算没加这个逻辑,目前的插件进程也是会在关闭页面后被推出 |
是的,杀死插件有两个时机:
当通信恢复时,可以不刷新页面,重新启动一个插件进程,这个插件进程在启动前会销毁前一个插件进程的副作用 |
定位到问题还是出在 |
看起来在 apline 下确实有问题,评论区给了 workaround. 写一个 |
这里提供的代码并不能解决问题,在稳定的 Docker 版本下,通过 PID 查找子进程的逻辑是正常被处理的,但问题发生在 https://github.com/pkrumins/node-tree-kill/blob/deee138a8cbc918463d8af5ce8c2bec33c3fd164/index.js#L53 这里,不能正常将进程 Kill 掉 |
https://askubuntu.com/questions/201303/what-is-a-defunct-process-and-why-doesnt-it-get-killed From your output we see a "defunct", which means the process has either completed its task or has been corrupted or killed, but its child processes are still running or these parent process is monitoring its child process. To kill this kind of process, kill -9 PID doesn't work. You can try to kill them with this command but it will show this again and again. |
root 491 1 6 04:33 ? 00:00:01 /usr/local/bin/node /release/hosted/ext.process.js --kt-process-sock-option={"path":"/tmp/sumi-ipc/sumi-ipc-ext_processc5aaADw_59dnt1kiqmHCD.soc
root 503 491 6 04:33 ? 00:00:01 /usr/local/bin/node --max-old-space-size=3072 /root/.sumi/extensions/vscode.typescript-language-features/deps/typescript/lib/tsserver.js --serve
root 504 491 7 04:33 ? 00:00:01 /usr/local/bin/node --max-old-space-size=3072 /root/.sumi/extensions/vscode.typescript-language-features/deps/typescript/lib/tsserver.js --useIn
root 521 504 1 04:33 ? 00:00:00 /usr/local/bin/node /root/.sumi/extensions/vscode.typescript-language-features/deps/typescript/lib/typingsInstaller.js --globalTypingsCacheLocat 就是这些插件进程:
这些插件进程是被 在 docker 上,这个 node 是 init 进程,当 ext host 没有 kill 完它的孩子后,它的孩子成为了孤儿就交给了 init 进程,init 如果是 systemd 这些,就会处理掉这个孤儿。但是我们的 node 没有实现这一步。 |
The only way you could remove the zombie/defunct process, would be to kill the parent. |
如这篇文章提到的 https://maximorlov.com/process-signals-inside-docker-containers/ , 直接通过 通过携带该参数的运行方式即可避免这个问题,如 该 PR 仅修改部分 Log 信息,便于排查后续问题,无其他增量修改。 |
Types
Background or solution
close #2166.
优化插件进程内部分日志展示,便于后续问题排查
Changelog
update some logs on extension host process service