删掉events块的那天我盯着nginx: [emerg] no events section in configuration这条日志愣了几秒。配置精简过头以为events只是可选的性能调优段结果 reload 直接失败。顺着报错去源码里定位最后停在一个叫ngx_event_init_conf的静态函数上。这个函数平时没什么存在感但它是 Nginx 事件框架在配置阶段的最后一扇门。如果你排查过 Nginx 启动失败、读过事件模块源码、或者自己折腾过自定义事件后端这篇笔记应该能帮你少走一段弯路。ngx_event_init_conf位于src/event/ngx_event.c是全局核心模块ngx_events_module的init_conf回调。它的输入很直接一个ngx_conf_t *cf和一个void *conf前者是配置上下文后者就是events {}块解析后产出的配置对象。它不创建任何新配置只负责在配置解析结束之后、模块初始化开始之前做几道必要的合法性校验。校验不过整个 Nginx 进程直接退出。1. 一个 emerg 日志把问题指到 events 配置先认识这个函数1.1 从 no events section in configuration 说起我当时犯的错误很典型把 nginx.conf 精简成一个能跑静态文件的最小形态顺手把events {}段移除了理由是想看缺了它系统会不会自己兜底。结果nginx -t直接拦下错误日志只有一句话nginx: [emerg] no events section in configuration这句日志就是从ngx_event_init_conf里输出的。它检查的是cycle-conf_ctx中ngx_events_module对应的配置槽位是否为 NULL。如果整个配置文件中从未出现过events关键字这个槽位就是空的函数直接记录NGX_LOG_EMERG日志并返回NGX_CONF_ERROR。返回错误后ngx_init_cycle会中止Nginx 进程起不来。所以别再把events当成一个可选的优化段。它是事件框架的硬性入口缺了它后续的所有连接处理逻辑都没有依托。1.2 函数在源码里的坐标ngx_events_module 的 init_conf在 Nginx 的模块体系里ngx_events_module是一个类型为NGX_CORE_MODULE的模块。它的模块上下文是ngx_core_module_t结构里面有两个关键回调create_conf和init_conf。static ngx_core_module_t ngx_events_module_ctx { ngx_string(events), NULL, ngx_event_init_conf };create_conf是 NULL说明这个模块不负责创建自己的配置对象。events {}块的配置对象是在指令解析阶段由events指令的 set 回调创建的。init_conf就是ngx_event_init_conf它在配置全部解析完成后被调用。这个函数是静态的外部看不到但它和ngx_event_core_module的ngx_event_core_init_conf是两回事。前者是外壳模块的总校验后者是事件核心模块的默认值和细节校验。很多人把这两个函数混在一起排查容易走弯路。1.3 这篇笔记适合谁如果你遇到以下情况这篇内容大概率对你有用第一Nginx 启动时出现emerg级别的事件配置错误第二你想搞清楚events {}配置从解析到真正生效的完整链路第三你在开发或移植自定义事件模块想知道init_conf阶段系统到底在检查什么。这篇文章会从触发时机、入参来源、函数本体、后续消费四个角度把它拆开最后聊几个和它相关的版本差异与踩坑经验。2. 三个模块一台戏ngx_events_module、event_core 与具体事件后端的关系2.1 三层模块各自的职责边界很多人一听到事件模块就以为是一个整体实际上 Nginx 里和事件相关的模块至少分三层角色完全不同。模块模块类型职责核心指令ngx_events_moduleNGX_CORE_MODULE提供events {}配置外壳做总校验eventsngx_event_core_moduleNGX_EVENT_MODULE事件框架核心提供默认值、事件循环初始化use, worker_connections, multi_accept, accept_mutexngx_epoll_module / ngx_kqueue_module / ngx_select_module / ngx_poll_moduleNGX_EVENT_MODULE具体事件后端提供真实的事件操作函数通常无指令ngx_events_module负责的是配置文件里有没有events{}这个块。ngx_event_core_module负责这个块里默认参数是什么、事件循环怎么组织。具体后端模块负责用 epoll 还是 kqueue、select、poll 去监听事件。在 Linux 上具体后端通常是ngx_epoll_module在 macOS 和 BSD 上则是ngx_kqueue_module如果编译时把高级事件模块都禁用掉会退回ngx_select_module或ngx_poll_module。2.2 ngx_event_conf_t 到底长什么样三个模块最终围绕同一个配置对象工作那就是ngx_event_conf_t。这个结构体定义在src/event/ngx_event.h是理解整个事件配置的钥匙。typedef struct { void **connections; void **files; ngx_uint_t connection_n; ngx_uint_t use_accept_mutex; ngx_event_module_t *use; ngx_event_actions_t actions; } ngx_event_conf_t;逐个字段解释一下。connections和files是后续要用的指针数组connections用于存放每个连接对象指针files用于存放文件描述符索引对应的对象指针。connection_n是worker_connections指令解析后的数值表示每个 worker 进程允许的最大连接数。use_accept_mutex控制 accept 互斥锁开关。use是指向具体事件模块上下文的指针actions是这个事件模块导出的操作函数表。注意use的类型它不是字符串而是一个ngx_event_module_t *指针。所以判断当前使用哪个事件模块在配置阶段看ecf-use指向哪里即可。2.3 use 字段不是一个字符串而是一个模块上下文ngx_event_module_t结构体是这样的typedef struct { ngx_str_t *name; void *(*create_conf)(ngx_cycle_t *cycle); char *(*init_conf)(ngx_cycle_t *cycle, void *conf); ngx_event_actions_t actions; } ngx_event_module_t;name是模块名字create_conf和init_conf是事件模块自己的配置回调actions是这个模块提供的事件操作函数集。当你在配置里写use epoll;时use指令的 set 回调会在ngx_modules数组里遍历找到名字为 epoll 的NGX_EVENT_MODULE类型模块然后把ecf-use指向它的module-ctx。到了ngx_event_init_conf执行时ecf-use已经是一个真实存在的模块上下文指针而不是字符串。这解释了为什么如果use写错名字错误会发生在指令解析阶段而不是ngx_event_init_conf阶段——因为init_conf根本看不到原始字符串。3. 触发时机和入参来源ngx_configure_module 里的舞台安排3.1 configure_module 如何按类型分发 init_confngx_event_init_conf不是在配置解析过程中被调用的而是在ngx_init_cycle的ngx_configure_module阶段被调用。这个阶段位于配置解析完成之后、模块init_module之前。简化后的调用逻辑类似这样for (i 0; cycle-modules[i]; i) { module cycle-modules[i]; if (module-type NGX_CORE_MODULE) { ngx_core_module_t *ctx module-ctx; conf cycle-conf_ctx[module-index]; if (ctx-init_conf) { rv ctx-init_conf(cf, conf); if (rv ! NGX_CONF_OK) { goto failed; } } } }ngx_events_module是NGX_CORE_MODULE所以它走的是上面这条分支。conf参数来自cycle-conf_ctx[ngx_events_module.index]也就是events {}块解析后生成的那个ngx_event_conf_t对象。这里要强调一个顺序问题在ngx_modules数组里ngx_events_module的 index 通常比ngx_event_core_module靠前因为它是更早注册的全局核心模块。所以ngx_event_init_conf会先于ngx_event_core_init_conf执行。这个顺序很关键意味着前者做检查时后者的默认值兜底逻辑还没跑。3.2 NGX_CONF_OK 与 NGX_CONF_ERROR 的返回约定Nginx 配置回调的返回值约定是返回NGX_CONF_OK本质上是 NULL表示成功返回NGX_CONF_ERROR表示失败也可以返回一个自定义的char*错误字符串这个字符串会被当作错误信息打印出来。ngx_event_init_conf失败时返回NGX_CONF_ERROR外层ngx_configure_module检测到不是NGX_CONF_OK直接返回NGX_ERRORngx_init_cycle随即返回 NULL整个启动流程终止。所以这个函数的任何一道检查不通过都没有警告继续跑的余地。我实际排查时发现一个有用的辅助手段nginx -t测试配置时同样会走ngx_init_cycle和ngx_configure_module所以events配置合法性的问题用nginx -t就能提前发现不需要真的启动服务。3.3 为什么 init_conf 不负责 create_confngx_events_module_ctx的create_conf是 NULL这和普通模块不太一样。普通NGX_CORE_MODULE模块通常会让框架先调用create_conf创建配置对象再调用init_conf初始化。但events块是配置文件的子块它的配置对象创建发生在指令解析阶段。events指令的 set 回调是ngx_conf_set_core_module_conf这个回调会从cf-ctx-conf_ctx中取出当前模块的配置槽位并分配内存。也就是说配置文件里写events {}的那一刻配置对象已经存在了。ngx_event_init_conf拿到的conf就是这个已经存在的对象它的职责是校验而不是重建。这也解释了为什么代码里第一件事就是检查这个对象是否真的存在。4. 函数本体拆解三道检查背后的设计逻辑4.1 第一道闸门events 段是否在配置里出现过函数开头第一段检查就是我遇到的报错源头if (ngx_get_conf(ncycle-conf_ctx, ngx_events_module) NULL) { ngx_log_error(NGX_LOG_EMERG, cf-log, 0, no \events\ section in configuration); return NGX_CONF_ERROR; }ngx_get_conf是一个宏本质上是从conf_ctx这个指针数组里按模块 index 取配置对象#define ngx_get_conf(conf_ctx, module) *(void **) ((char *) conf_ctx module-index)如果conf_ctx中ngx_events_module对应的槽位是 NULL说明解析器从未进入events {}块配置对象自然不存在。这种情况下没有任何默认配置可以兜底只能报错。这个设计看起来武断其实是合理的。Nginx 的 worker 进程必须要有事件循环连接事件、读写事件、定时器全部挂在事件框架上。如果连events段都没有后面的连接池、事件队列、accept 逻辑全都无从建立。与其在更深处报一个让人摸不着头脑的错误不如在配置阶段亮明态度。4.2 第二道闸门use 是否指向有效事件模块在不同版本里函数对ecf-use NULL的处理方式有差别。在较新的版本中默认事件模块的兜底选择放在ngx_event_core_init_conf里完成ngx_event_init_conf并不在这里做默认赋值。if (ecf-use NULL) { ngx_log_error(NGX_LOG_EMERG, cf-log, 0, the \use\ directive requires the event module name but no event module is loaded); return NGX_CONF_ERROR; }这个检查的意义在于ecf-use必须已经指向一个真实的事件模块上下文否则后续的ecf-actions ecf-use-actions会拿到空操作表事件循环跑起来就是空的所有连接监听会失效。但实际使用中绝大多数配置不写use指令也能启动因为ngx_event_core_init_conf会在用户没有显式指定时自动选择一个平台支持的事件模块。所以这个报错更多是防守性质的如果事件核心模块的兜底逻辑因为某种原因没有设置use比如编译时把高级事件模块全禁用了或者第三方模块注册异常这里会兜住最后一层。4.3 第三道闸门事件核心模块是否可创建配置函数里还会检查ngx_event_core_module.create_conf是否存在if (ngx_event_core_module.create_conf NULL) { ngx_log_error(NGX_LOG_EMERG, cf-log, 0, no \event_core\ module is loaded); return NGX_CONF_ERROR; }正常情况下这个检查永远不会失败因为ngx_event_core_module是 Nginx 事件框架的固定成员它的create_conf必然存在用于创建事件核心配置。但如果你在 configure 阶段做过极端裁剪或者动态模块加载出了问题这个检查就是最后的保险丝。它背后的逻辑是即使外壳events {}存在use也指到了某个后端如果事件核心模块本身不可用那整个事件循环仍然是空中楼阁。三道检查合起来其实是在回答三个问题配置存在吗后端选定了吗核心框架在吗4.4 注意这里不做默认值兜底读到这里可能有人会问worker_connections没写怎么办accept_mutex没写怎么办multi_accept没写怎么办这些默认值都不是ngx_event_init_conf设置的。ngx_event_core_create_conf在创建事件核心配置时会设置初始默认值比如connection_n默认 512accept_mutex默认开启等。ngx_event_core_init_conf则负责在配置解析完成后补齐没有显式指定的值。也就是说ngx_event_init_conf是先校验外层是否完备ngx_event_core_init_conf是再补齐内层细节。两者是先后关系不是重复关系。我最初读源码时也踩了这个概念坑以为events块的默认值逻辑都在ngx_event_init_conf里排查半天发现在ngx_event_core_module的上下文回调里。认清这两者的分工排查启动问题会快很多。5. 配置对象的一生从 events 关键字到事件循环真正跑起来5.1 配置对象的分配与写入ngx_event_conf_t的完整生命周期是这样的解析器读到events指令ngx_conf_set_core_module_conf分配ngx_event_conf_t并放入cycle-conf_ctx[ngx_events_module.index]然后进入子上下文解析块内指令。块内的use、worker_connections、multi_accept、accept_mutex等指令属于ngx_event_core_module的 commands。它们的 set 回调会往ngx_event_conf_t里写入对应字段。比如worker_connections 4096;解析完后ecf-connection_n就是 4096。这个阶段的特点是边解析边写值所有字段都是直接修改不做跨字段校验。真正开始做整体校验就是ngx_configure_module阶段了。5.2 从 init_conf 到 init_module 之间发生了什么ngx_event_init_conf通过之后ngx_configure_module会继续遍历后续模块的init_conf。接着ngx_init_cycle进入ngx_init_modules对每个有init_module回调的模块进行初始化。对事件框架来说ngx_event_module_init在这里被执行。它会做几件重要的事情检查connection_n是否超过了系统文件描述符上限、根据实际资源情况调整连接数、为连接指针数组和文件数组做预分配。这个阶段和ngx_event_init_conf的口感完全不同前者是纯粹的配置合法性检查后者已经进入实际资源核算。如果你设置了超大worker_connections比如超过ulimit -n的限制报错往往不会出现在ngx_event_init_conf而是在ngx_event_module_init阶段。排查时不要被函数名误导。5.3 后续消费连接数组与 actions 绑定再往后worker 进程 fork 出来后会执行ngx_event_process_init。这一步才开始真正分配大块内存每个 worker 的ngx_connection_t数组、读事件数组、写事件数组全部在这里落地。ngx_event_process_init还会把ecf-actions绑定到全局事件函数指针上。后续ngx_event_add_conn、ngx_event_del_conn、ngx_event_process_events这些调用最终都会跳到具体事件模块的 actions 函数。比如 epoll 模块的ngx_epoll_add_event、ngx_epoll_del_event、ngx_epoll_process_events。所以整个链路是events 指令解析 - 分配 ngx_event_conf_t - 写入 use/connection_n - ngx_event_init_conf 校验 - ngx_event_core_init_conf 补默认值 - ngx_event_module_init 核算资源 - worker fork - ngx_event_process_init 分配连接数组并绑定 actionsngx_event_init_conf在这条链路里是一个质量闸门它确保了进入后续阶段时配置外壳是完整可用的。6. 版本差异与自定义事件模块时最容易犯的错6.1 use 字段类型的版本演进ngx_event_conf_t的use字段在不同版本里变化比较大。早期版本里它是一个ngx_str_t字符串加一个独立的actions字段较新版本里改成了ngx_event_module_t *use指针actions直接从这个指针里取。如果你维护过第三方事件模块这个变化一定要清楚。老代码里自己组装ngx_event_conf_t或直接操作use.name的写法在新版本下会编译失败。正确做法是通过use指令的 set 回调让框架赋值不要手工改use字段。另一个容易忽略的点ngx_event_core_module自身也是一个NGX_EVENT_MODULE类型模块它的ngx_event_module_t结构里actions大多是 NULL。在做默认事件模块选择时要跳过它否则会把框架核心误当成事件后端。6.2 自定义事件模块如何接入 init_conf 链路如果你在写一个自定义事件后端最需要注意的是自己的模块必须正确注册到ngx_modules数组。事件模块的ngx_event_module_t里create_conf和init_conf都要写对。create_conf负责创建模块私有配置init_conf负责校验和补默认值。在配置里使用它时use指令要能找到模块名。查找过程是遍历ngx_modules中类型为NGX_EVENT_MODULE的模块比对ctx-name。如果模块编译进去了但名字不匹配或者模块被放到了动态加载路径里而加载顺序不对ecf-use就一直无法指向你的模块最终可能在ngx_event_init_conf或后续资源初始化时报错。实操中我建议先在ngx_event_core_init_conf的默认选择逻辑里打断点确认它是否把你的模块当成了候选。如果默认选择逻辑跳过了自定义模块多半是name字段或者模块类型不符合预期。6.3 那些不在 init_conf 报错却像它该管的问题最后聊几个实际排查中容易和张冠李戴的问题。第一use指令写了不存在的模块名比如use epoll_extra;报错发生在指令解析阶段ngx_event_use回调会发现找不到对应模块并提示无效事件类型这和ngx_event_init_conf无关。第二worker_connections设得过大超过系统文件描述符限制。这种问题通常不会在ngx_event_init_conf报出来而是在ngx_event_module_init里根据实际rlimit调整时记录错误或者等 worker 进程真正创建连接时才发现。第三事件模块的actions.init返回失败。这类错误发生在ngx_event_process_init是 worker 进程启动阶段比init_conf晚得多。如果你在init_conf阶段排查半天找不到根因可以看看错误日志里有没有更晚的函数名出现有时候问题根本不在配置而在系统资源。长话短说我现在的排查套路是看到emerg级别错误先分清阶段。配置解析阶段的问题找指令 set 回调和init_conf资源核算的问题找ngx_event_module_initworker 运行期问题找ngx_event_process_init。ngx_event_init_conf只是这条排查链上的第一站但它往往能帮你快速排除最基础的问题不至于带着残缺配置往下走。