请教在 stream-lua 中实现 access_by_lua* 时遇到的几个问题

rye.y.cn · 2016-05-16T15:48:08+00:00

On Wednesday, May 18, 2016 at 12:30:25 PM UTC+8, agentzh wrote:Hello! 2016-05-15 20:10 GMT-07:00 有莘: > 我使用mongol&#x...

请教在 stream-lua 中实现 access_by_lua* 时遇到的几个问题

rye.y.cn

Hi，各位

我刚接触 Nginx/OpenResty 模块开发不久，在实现 ngx_stream_lua_accessby 的过程中遇到一些问题，请大家指点，谢谢！
背景是我打算用 OpenResty 做 Thrift 服务的反向代理，对 thrift 请求进行动态访问控制，这几天学习了 Nginx 和 OpenResty 源码后有了一些思路，基于 stream-lua-nginx-module 来实现：

在现有 content_by_lua* 中通过 cosocket 实现，但需要额外实现向 upstream 转发的功能，无法直接利用 proxy_pass 指令。
实现 access_by_lua* 指令。预期可以与 proxy_pass 共存。

我选择了 2 方案，目前从 ngx_lua 模块中依葫芦画瓢实现了 ngx_stream_lua_accessby，增加了 NGX_STREAM_LUA_CONTEXT_ACCESS 阶段，在 ngx_stream_core_srv_conf_t 中注册了 ngx_stream_lua_access_handler 等等。现在 access_by_lua* 可以正确执行，但是依旧不能和 proxy_pass 同时有效。

看了几遍代码，还是有一些疑惑：

stream 子系统中阶段的执行顺序是在何处控制的？nginx core, stream 还是 stream-lua-nginx-module？如何使自己的 directive 在某个阶段被调用？
stream 中 lua access handler 应该注册到哪里？我尝试在 directive 中实现 ngx_stream_lua_access_by_lua 时将 access_handler 注册到 ngx_stream_core_srv_conf_t->handler 或 ngx_stream_core_main_conf_t->access_handler 中，但前者会覆盖其它 content 阶段的 handler，后者似乎不起任何作用。

agentzh

Hello!

2016-05-16 0:48 GMT-07:00 Rye Yao:
>     看了几遍代码，还是有一些疑惑：
>
> stream 子系统中阶段的执行顺序是在何处控制的？nginx core, stream 还是
> stream-lua-nginx-module？如何使自己的 directive 在某个阶段被调用？

这里的执行顺序都是由 ngnx 核心的 stream 子系统的 ngx_stream_init_connection 这个 C 函数来实现的。看那个函数就好了。

> stream 中 lua access handler 应该注册到哪里？我尝试在 directive 中实现
> ngx_stream_lua_access_by_lua 时将 access_handler 注册到
> ngx_stream_core_srv_conf_t->handler 或
> ngx_stream_core_main_conf_t->access_handler 中，但前者会覆盖其它 content 阶段的
> handler，后者似乎不起任何作用。
>

注册 cmcf->access_handler 是正确的做法。不起作用，应该是其他地方搞错了。调试的时候，直接盯紧
ngx_stream_init_connection 函数里对 cmcf->access_handler 的调用就好了。另外，应该开启
nginx 的调试日志（debugging log）。

Regards,
-agentzh

rye.y.cn

感谢章老师回复。

已经打开了调试日志，包括 --with-debug 和 -D DEBUG=1。

通过源码追查到 cmcf->access_handler 会在 ngx_stream_access_module 初始化时被覆盖，从 ngx_modules.c 中看到 ngx_stream_access_module 在数组中位于 ngx_stream_lua_module 之后，应该是在模块初始化的时候被覆盖的，由于希望保留 ngx_stream_access_module 模块，所以我在该模块初始化函数中增加了对 cmcf->access_handler 是否为 NULL 的判断，这个模块调用的问题就解决了，但是修改了 nginx 的源码。

另外，stream 子系统中对 access_handler 的调用位于 session 初始化之前，目前我能看到的影响，是在 access 阶段时 s-ctx 数组为 NULL，因此需要在 ngx_stream_get_module_ctx 前加判断条件，之后再通过 ngx_stream_lua_create_ctx 创建新的 ctx。但接下来在执行 ngx_stream_lua_run_thread 时，lua_resume 这一步出 core 了，不知道可能会是什么原因？用 gdb 查看到 orig_coctx 变量如下：

(gdb) p *orig_coctx
$17 = {data = "" co = 0x4000d838, parent_co_ctx = 0x0, zombie_child_threads = 0x0, cleanup = 0x0, sleep = {data = "" write = 0, accept = 0,
instance = 0, active = 0, disabled = 0, ready = 0, _oneshot_ = 0, complete = 0, eof = 0, error = 0, timedout = 0, timer_set = 0, delayed = 0,
deferred_accept = 0, pending_eof = 0, posted = 0, closed = 0, channel = 0, resolver = 0, cancelable = 0, available = 0, handler = 0x0, index = 0,
log = 0x0, timer = {key = 0, left = 0x0, right = 0x0, parent = 0x7e16d0, color = 168 '\250', data = "" '\272'}, queue = {prev = 0x7ebaf0,
next = 0x7e1658}}, sem_wait_queue = {prev = 0x0, next = 0x7e1630}, co_top = 1, co_ref = 1, waited_by_parent = 0, co_status = 1, is_uthread = 0,
thread_spawn_yielded = 0, sem_resume_status = 0, flushing = 0}

(gdb) p *orig_coctx->co
$18 = {nextgc = {gcptr32 = 1073796944}, marked = 1 '\001', gct = 6 '\006', dummy_ffid = 1 '\001', status = 0 '\000', glref = {ptr32 = 1073742776},
gclist = {gcptr32 = 0}, base = 0x4000dd80, top = 0x4000dd88, maxstack = {ptr32 = 1073798832}, stack = {ptr32 = 1073798520}, openupval = {
gcptr32 = 0}, env = {gcptr32 = 1073797248}, cframe = 0x0, stacksize = 45}

Best Wishes!

Rye Yao

2016-05-18 12:16 GMT+08:00 Yichun Zhang (agentzh) <age...@gmail.com>:

Hello!

2016-05-16 0:48 GMT-07:00 Rye Yao:
> 看了几遍代码，还是有一些疑惑：
>
> stream 子系统中阶段的执行顺序是在何处控制的？nginx core, stream 还是
> stream-lua-nginx-module？如何使自己的 directive 在某个阶段被调用？

这里的执行顺序都是由 ngnx 核心的 stream 子系统的 ngx_stream_init_connection 这个 C 函数来实现的。看那个函数就好了。

> stream 中 lua access handler 应该注册到哪里？我尝试在 directive 中实现
> ngx_stream_lua_access_by_lua 时将 access_handler 注册到
> ngx_stream_core_srv_conf_t->handler 或
> ngx_stream_core_main_conf_t->access_handler 中，但前者会覆盖其它 content 阶段的
> handler，后者似乎不起任何作用。
>

注册 cmcf->access_handler 是正确的做法。不起作用，应该是其他地方搞错了。调试的时候，直接盯紧
ngx_stream_init_connection 函数里对 cmcf->access_handler 的调用就好了。另外，应该开启
nginx 的调试日志（debugging log）。

Regards,
-agentzh

--

agentzh

Hello!

2016-05-17 23:17 GMT-07:00 Rye Yao:
> 通过源码追查到 cmcf->access_handler 会在 ngx_stream_access_module 初始化时被覆盖，从
> ngx_modules.c 中看到 ngx_stream_access_module 在数组中位于 ngx_stream_lua_module
> 之后，应该是在模块初始化的时候被覆盖的，由于希望保留 ngx_stream_access_module 模块，所以我在该模块初始化函数中增加了对
> cmcf->access_handler 是否为 NULL 的判断，这个模块调用的问题就解决了，但是修改了 nginx 的源码。
>

是的，stream 子系统目前只允许一个模块注册 access_handler，这是显然的。

> 另外，stream 子系统中对 access_handler 的调用位于 session 初始化之前，
> 目前我能看到的影响，是在 access 阶段时
> s-ctx 数组为 NULL，因此需要在 ngx_stream_get_module_ctx 前加判断条件，之后再通过
> ngx_stream_lua_create_ctx 创建新的 ctx。


stream 子系统确实应该在 access_handler() 调用之前初始化 s->ctx 数组。你能给 nginx
官方提一个补丁吗？否则的话，access handler 和 content handler 之间将无法共享一个 ctx.

> 但接下来在执行 ngx_stream_lua_run_thread 时，lua_resume 这一步出 core 了，不知道可能会是什么原因？用 gdb 查看到 orig_coctx 变量如下：
>

用 gdb 检查 core 应该首先看 backtrace 呀，你怎么只看 orig_coctx?

另外，建议遇到此种情况，总是使用 valgrind memcheck
来检查。这是因为崩溃的位置不一定是第一现场，即使是第一现场，valgrind 也经常能给出更多的细节信息。

Regards,
-agentzh

rye.y.cn

多谢提醒，我尝试提个 patch。backtrace 没看出什么问题，因为 LuaJIT 没有 symbol 信息……

在 2016年5月19日星期四 UTC+8上午3:26:53，agentzh写道：

Hello!

2016-05-17 23:17 GMT-07:00 Rye Yao:
> 通过源码追查到 cmcf->access_handler 会在 ngx_stream_access_module 初始化时被覆盖，从
> ngx_modules.c 中看到 ngx_stream_access_module 在数组中位于 ngx_stream_lua_module
> 之后，应该是在模块初始化的时候被覆盖的，由于希望保留 ngx_stream_access_module 模块，所以我在该模块初始化函数中增加了对
> cmcf->access_handler 是否为 NULL 的判断，这个模块调用的问题就解决了，但是修改了 nginx 的源码。
>

是的，stream 子系统目前只允许一个模块注册 access_handler，这是显然的。

> 另外，stream 子系统中对 access_handler 的调用位于 session 初始化之前，
> 目前我能看到的影响，是在 access 阶段时
> s-ctx 数组为 NULL，因此需要在 ngx_stream_get_module_ctx 前加判断条件，之后再通过
> ngx_stream_lua_create_ctx 创建新的 ctx。

stream 子系统确实应该在 access_handler() 调用之前初始化 s->ctx 数组。你能给 nginx
官方提一个补丁吗？否则的话，access handler 和 content handler 之间将无法共享一个 ctx.

> 但接下来在执行 ngx_stream_lua_run_thread 时，lua_resume 这一步出 core 了，不知道可能会是什么原因？用 gdb 查看到 orig_coctx 变量如下：
>

用 gdb 检查 core 应该首先看 backtrace 呀，你怎么只看 orig_coctx?

另外，建议遇到此种情况，总是使用 valgrind memcheck
来检查。这是因为崩溃的位置不一定是第一现场，即使是第一现场，valgrind 也经常能给出更多的细节信息。

Regards,
-agentzh

luohoufu

楼主，请问这个最近有进展了吗？

在 2016年5月19日星期四 UTC+8下午12:13:10，Rye Yao写道：

多谢提醒，我尝试提个 patch。backtrace 没看出什么问题，因为 LuaJIT 没有 symbol 信息……

在 2016年5月19日星期四 UTC+8上午3:26:53，agentzh写道：
Hello!

2016-05-17 23:17 GMT-07:00 Rye Yao:
> 通过源码追查到 cmcf->access_handler 会在 ngx_stream_access_module 初始化时被覆盖，从
> ngx_modules.c 中看到 ngx_stream_access_module 在数组中位于 ngx_stream_lua_module
> 之后，应该是在模块初始化的时候被覆盖的，由于希望保留 ngx_stream_access_module 模块，所以我在该模块初始化函数中增加了对
> cmcf->access_handler 是否为 NULL 的判断，这个模块调用的问题就解决了，但是修改了 nginx 的源码。
>

是的，stream 子系统目前只允许一个模块注册 access_handler，这是显然的。

> 另外，stream 子系统中对 access_handler 的调用位于 session 初始化之前，
> 目前我能看到的影响，是在 access 阶段时
> s-ctx 数组为 NULL，因此需要在 ngx_stream_get_module_ctx 前加判断条件，之后再通过
> ngx_stream_lua_create_ctx 创建新的 ctx。

stream 子系统确实应该在 access_handler() 调用之前初始化 s->ctx 数组。你能给 nginx
官方提一个补丁吗？否则的话，access handler 和 content handler 之间将无法共享一个 ctx.

> 但接下来在执行 ngx_stream_lua_run_thread 时，lua_resume 这一步出 core 了，不知道可能会是什么原因？用 gdb 查看到 orig_coctx 变量如下：
>

用 gdb 检查 core 应该首先看 backtrace 呀，你怎么只看 orig_coctx?

另外，建议遇到此种情况，总是使用 valgrind memcheck
来检查。这是因为崩溃的位置不一定是第一现场，即使是第一现场，valgrind 也经常能给出更多的细节信息。

Regards,
-agentzh

rye.y.cn

已经开发完了，等写完测试就提个 pr。

在 2016年5月25日星期三 UTC+8下午3:31:31，Tonny Luo写道：

楼主，请问这个最近有进展了吗？

在 2016年5月19日星期四 UTC+8下午12:13:10，Rye Yao写道：
多谢提醒，我尝试提个 patch。backtrace 没看出什么问题，因为 LuaJIT 没有 symbol 信息……

在 2016年5月19日星期四 UTC+8上午3:26:53，agentzh写道：
Hello!

2016-05-17 23:17 GMT-07:00 Rye Yao:
> 通过源码追查到 cmcf->access_handler 会在 ngx_stream_access_module 初始化时被覆盖，从
> ngx_modules.c 中看到 ngx_stream_access_module 在数组中位于 ngx_stream_lua_module
> 之后，应该是在模块初始化的时候被覆盖的，由于希望保留 ngx_stream_access_module 模块，所以我在该模块初始化函数中增加了对
> cmcf->access_handler 是否为 NULL 的判断，这个模块调用的问题就解决了，但是修改了 nginx 的源码。
>

是的，stream 子系统目前只允许一个模块注册 access_handler，这是显然的。

> 另外，stream 子系统中对 access_handler 的调用位于 session 初始化之前，
> 目前我能看到的影响，是在 access 阶段时
> s-ctx 数组为 NULL，因此需要在 ngx_stream_get_module_ctx 前加判断条件，之后再通过
> ngx_stream_lua_create_ctx 创建新的 ctx。

stream 子系统确实应该在 access_handler() 调用之前初始化 s->ctx 数组。你能给 nginx
官方提一个补丁吗？否则的话，access handler 和 content handler 之间将无法共享一个 ctx.

> 但接下来在执行 ngx_stream_lua_run_thread 时，lua_resume 这一步出 core 了，不知道可能会是什么原因？用 gdb 查看到 orig_coctx 变量如下：
>

用 gdb 检查 core 应该首先看 backtrace 呀，你怎么只看 orig_coctx?

另外，建议遇到此种情况，总是使用 valgrind memcheck
来检查。这是因为崩溃的位置不一定是第一现场，即使是第一现场，valgrind 也经常能给出更多的细节信息。

Regards,
-agentzh

agentzh

Hello!

2016-05-18 21:13 GMT-07:00 Rye Yao:
> 多谢提醒，我尝试提个 patch。backtrace 没看出什么问题，因为 LuaJIT 没有 symbol 信息……
>

我估计这是因为你 build LuaJIT 时没有启用调试符号。OpenResty 包含的 LuaJIT 默认是开启调试符号的。

LuaJIT 手工开启调试符号的做法是：

    make CCDEBUG=-g

Regards,
-agentzh

rye.y.cn

明白了，多谢！

在 2016年5月28日星期六 UTC+8上午4:13:46，agentzh写道：

Hello!

2016-05-18 21:13 GMT-07:00 Rye Yao:
> 多谢提醒，我尝试提个 patch。backtrace 没看出什么问题，因为 LuaJIT 没有 symbol 信息……
>

我估计这是因为你 build LuaJIT 时没有启用调试符号。OpenResty 包含的 LuaJIT 默认是开启调试符号的。

LuaJIT 手工开启调试符号的做法是：

make CCDEBUG=-g

Regards,
-agentzh