|
|
# 25 | 答疑（二）：特权进程的权限到底是什么？
|
|
|
|
|
|
你好，我是温铭。
|
|
|
|
|
|
专栏更新到现在，OpenResty第二版块 OpenResty API 篇，我们就已经学完了。恭喜你没有掉队，仍然在积极学习和实践操作，并且热情地留下了你的思考。
|
|
|
|
|
|
很多留言提出的问题很有价值，大部分我都已经在App里回复过，一些手机上不方便回复的或者比较典型、有趣的问题，我专门摘了出来，作为今天的答疑内容，集中回复。另一方面，也是为了保证所有人都不漏掉任何一个重点。
|
|
|
|
|
|
下面我们来看今天的这 6 个问题。
|
|
|
|
|
|
## 第一问，特权进程的权限
|
|
|
|
|
|
Q：我想请问下，特权进程是怎么回事，如果启动 OpenResty 的本身就是普通用户，如何获取root权限呢？另外，老师可以介绍下，特权进程的使用场景有哪些吗？
|
|
|
|
|
|
A：其实，特权进程的权限和 master 进程的权限保持一样。如果你用普通用户身份启动 OpenResty，那么 master 就是普通用户的权限，这时候特权进程也就没有什么特权了。
|
|
|
|
|
|
这一点应该还是很好理解的，普通用户启动的进程，无论如何也不会有 root 权限。
|
|
|
|
|
|
至于特权进程的使用场景，我们一般用特权进程来处理的是清理日志、重启 OpenResty 自身等需要高权限的任务。你需要注意的是，不要把 worker 进程的任务交给特权进程来处理。这并非因为特权进程不能做到，而是其存在安全隐患。
|
|
|
|
|
|
我见到过一个开发者，他把定时器的任务都交给了特权进程来处理。他为什么这么做呢？因为特权进程只有一个，这样 timer 就不会重复启动。
|
|
|
|
|
|
是不是觉得这看上去很聪明呀，不用 worker.id 这种笨方法就做到了。但是，别忘了，如果定时器的任务和用户的输入有关，这不就等于留了一个后门吗？显然是非常危险的。
|
|
|
|
|
|
## 第二问，阶段和调试
|
|
|
|
|
|
Q：老师，是不是无论在哪个阶段运行`ngx.say('hello')`，OpenResty都会在执行完本阶段的剩余代码后，直接响应给客户端，而不会继续执行其他阶段了呢？我测试出来是这样的。
|
|
|
|
|
|
A：事实上并非如此，我们可以来看下它的执行阶段的[顺序图](https://github.com/moonbingbing/openresty-best-practices/blob/master/images/openresty_phases.png)：
|
|
|
|
|
|
|
|
|
|
|
|
你可以做个测试，先在 content 里面 `ngx.say`；然后，在 log 或者 body filter 阶段使用 `ngx.log` 来打印下日志试试。
|
|
|
|
|
|
在专栏中，我并没有专门提到在 OpenResty 中做代码调试的问题，这也是开发者经常困惑的地方，我正好顺着这个问题在答疑中聊一下。
|
|
|
|
|
|
其实，OpenResty 中的代码调试，并没有断点这些高级功能（相应有一些付费的插件，但我并没有使用过），只能用 `ngx.say` 和`ngx.log` 来看输出。我知道的开发者，包括 OpenResty 的作者和贡献者们，都是这样来做 debug 的。所以，你需要有强有力的测试案例和调试日志来作为保证。
|
|
|
|
|
|
## 第三问，ngx.exit 和动手实验
|
|
|
|
|
|
Q：老师，文中的这句话，“OpenResty 的 HTTP 状态码中，有一个特别的常量：`ngx.OK`。当 `ngx.exit(ngx.OK)` 时，请求会退出当前处理阶段，进入下一个阶段，而不是直接返回给客户端。”
|
|
|
|
|
|
我记得，`ngx.OK`应该不能算是HTTP状态码，它对应的值是0。我的理解是：
|
|
|
|
|
|
* `ngx.exit(ngx.OK)`、`ngx.exit(ngx.ERROR)`和`ngx.exit(ngx.DECLINED)`时，请求会退出当前处理阶段，进入下一个阶段；
|
|
|
* 而当`ngx.exit(ngx.HTTP_*)`以`ngx.HTTP_*`的各种HTTP状态码作为参数时，会直接响应给客户端。
|
|
|
|
|
|
不知道这样想对不对呢？
|
|
|
|
|
|
A：关于你的第一个问题，`ngx.ok` 确实不是http状态码，它是 OpenResty 中的一个常量，值是0。
|
|
|
|
|
|
至于第二个问题，`ngx.exit` 的官方文档其实正好可以解答：
|
|
|
|
|
|
```
|
|
|
When status >= 200 (i.e., ngx.HTTP_OK and above), it will interrupt the execution of the current request and return status code to nginx.
|
|
|
|
|
|
When status == 0 (i.e., ngx.OK), it will only quit the current phase handler (or the content handler if the content_by_lua* directive is used) and continue to run later phases (if any) for the current request.
|
|
|
|
|
|
```
|
|
|
|
|
|
不过，文档里并没有提到， OpenResty对于`ngx.exit(ngx.ERROR)`和`ngx.exit(ngx.DECLINED)`是如何处理的，我们可以自己来做个测试，比如下面这样：
|
|
|
|
|
|
```
|
|
|
location /lua {
|
|
|
rewrite_by_lua "ngx.exit(ngx.ERROR)";
|
|
|
echo hello;
|
|
|
}
|
|
|
|
|
|
```
|
|
|
|
|
|
显然，访问这个 location，你可以看到 http 响应码为空，响应体也是空，并没有进入下一个执行阶段。
|
|
|
|
|
|
其实，还是那句话，在 OpenResty 的学习过程中，随着你逐步深入，一定会在某个阶段发现，文档和测试案例都无法回答你的问题。这时候，就需要你自己构建测试案例来验证你的想法了。你可以手动测试，也可以添加在 `test::nginx` 搭建的测试案例集里面。
|
|
|
|
|
|
## 第四问，变量和竞争
|
|
|
|
|
|
Q：老师，你好，我有下面几个问题想请教一下。
|
|
|
|
|
|
1. 前面讲过，`ngx.var`变量的作用域在nginx C和lua-nginx-module模块之间。这个我不太理解，从请求的角度来看，是指一个工作进程中的单个请求吗？
|
|
|
2. 我的理解是，在我们操作模块内的变量时，如果两个操作之间有阻塞操作，可能会出现竞争。那么，如果两个操作之间没有阻塞操作，恰好CPU时间到了后，当前进程进入就绪队列，这样可能产生竞争吗？
|
|
|
|
|
|
A：我们依次来看这几个问题。
|
|
|
|
|
|
第一，关于`ngx.var` 变量的问题，你的理解是正确的。实际上，`ngx.var` 的生命周期和请求一致，请求结束它也就消失了。但它的优势，是数据可以在 C 模块和 Lua 代码中传递。这是其他几种方式都无法做到的。
|
|
|
|
|
|
第二，关于变量竞争的问题，其实，只要两个操作之间有 `yield 操作`，就可能出现竞争，而不是阻塞操作；有阻塞操作时是不会出现竞争的。换句话说，只要你不把主动权交给 Nginx 的事件循环，就不会有竞争。
|
|
|
|
|
|
## 第五问，共享字典操作是否需要加锁呢？
|
|
|
|
|
|
Q：老师，如果多个worker并发存储数据，是不是需要加锁呢？比如下面这个例子：
|
|
|
|
|
|
```
|
|
|
resty --shdict 'dogs 10m' -e 'local dogs = ngx.shared.dogs
|
|
|
local lock= ngx.xxxx.lock
|
|
|
lock.lock()
|
|
|
dogs:set("Jim", 8)
|
|
|
lock.unlock()
|
|
|
local v = dogs:get("Jim")
|
|
|
ngx.say(v)
|
|
|
'
|
|
|
|
|
|
```
|
|
|
|
|
|
A：其实这里不用你自己加锁，共享字典（shared dict）的操作都是原子性的，不管是 get 还是 set。这种类似加锁的处理，OpenResty已经帮你考虑到了。
|
|
|
|
|
|
## 第六问，OpenResty 中如何更新时间？
|
|
|
|
|
|
Q：`ngx.now()`取时间，是发生在resume函数恢复堆栈阶段吗？
|
|
|
|
|
|
A：Nginx 是以性能优先作为设计理念的，它会把时间缓存下来。这一点，我们从 `ngx.now` 的源码中就可以得到印证：
|
|
|
|
|
|
```
|
|
|
static int
|
|
|
ngx_http_lua_ngx_now(lua_State *L)
|
|
|
{
|
|
|
ngx_time_t *tp;
|
|
|
|
|
|
tp = ngx_timeofday();
|
|
|
|
|
|
lua_pushnumber(L, (lua_Number) (tp->sec + tp->msec / 1000.0L));
|
|
|
|
|
|
return 1;
|
|
|
}
|
|
|
|
|
|
```
|
|
|
|
|
|
可以看出，`ngx.now()`这个获取当前时间函数的背后，隐藏的其实是 Nginx 的 `ngx_timeofday` 函数。而`ngx_timeofday` 函数，其实是一个宏定义：
|
|
|
|
|
|
```
|
|
|
#define ngx_timeofday() (ngx_time_t *) ngx_cached_time
|
|
|
|
|
|
```
|
|
|
|
|
|
这里`ngx_cached_time` 的值，只在函数 `ngx_time_update` 中会更新。
|
|
|
|
|
|
所以，这个问题就简化成了， `ngx_time_update`什么时候会被调用？如果你在 Nginx 的源码中去跟踪它的话，就会发现， `ngx_time_update` 的调用都出现在事件循环中，这个问题也就明白了吧。
|
|
|
|
|
|
通过这个问题你应该也能发现，开源项目的好处就是，你可以根据蛛丝马迹，在源码中寻找答案，颇有一种破案的感觉。
|
|
|
|
|
|
今天主要解答这几个问题。最后，欢迎你继续在留言区写下你的疑问，我会持续不断地解答。希望可以通过交流和答疑，帮你把所学转化为所得。也欢迎你把这篇文章转发出去，我们一起交流、一起进步。
|
|
|
|