Replies: 4 comments 12 replies
-
|
这个需求和项目相关。我不希望增加维护负担。 skynet 目前可以把信号以消息形式转发给服务(目前用于 log)。如果需要更多支持,可以考虑最小维护成本的基础机制。 |
Beta Was this translation helpful? Give feedback.
-
|
确实,这个功能需要兼容不同操作系统,还有不同 CPU 架构的话,还挺复杂。考虑到这种情况,一般要处理的是SIGSEGV这类危险信号,最好是现场处理,不要转发。底层机制,能否允许业务设置自定义的 signal handler? |
Beta Was this translation helpful? Give feedback.
-
|
这需要和 log 处理 SIGHUP 一样,在底层处理。但是不走转发的话,没想好怎么绕过任务调度器去执行一段用户定义的代码。 或许在系统启动时启动特定服务主动注册 signal handler 就可以了? |
Beta Was this translation helpful? Give feedback.
-
|
如果不是要支持获取 lua 堆栈,应该用 gcc 的 constructor 特性加 LD_PRELOAD 加载一下信号捕获模块,就可以了,不需要依赖 skynet 上下文。但要获取 lua 堆栈就比较 hack 了,要从 skynet_context 入手,拿到 lua state,再去遍历堆栈。 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
目前业务上遇到了分析coredump比较麻烦的问题,因为服务端在海外的k8s集群里面,一旦coredump了,k8s不会保留现场,会直接重新拉起新的容器。一个大的coredump文件,从海外拉回来比较麻烦。
内部讨论了一下,可以在skynet内部捕获信号,在coredump的时候,把一些关键信息保存到文本,可以快速确认一下问题的范围。
参考android的tombstone机制,我实现了以下功能,如果觉得这个机制有用,我可以提一个PR。
Beta Was this translation helpful? Give feedback.
All reactions