init_by_lua is no longer run in Nginx config test??

Skip to first unread message

May 5, 2021, 9:29:40 AMMay 5
to openresty-en
So this is quite strange. Looks like a substantial behavioral change has been made to OpenResty in early 2019 - to not run init_by_lua during Nginx config test (nginx -t).

Does anyone know why this change was made?
This seems like a big mistake.

The Nginx config test is the only way to verify that your config will apply successfully. Because Nginx reload is done with one-way communication (you send a SIGHUP to Nginx and don't get anything back) - there is no way to know if your config applied successfully. Hence - the config test, which you can do prior the actual reload to verify that the reload will be successful. It's your only response from Nginx about whether or not it will accept your config during reload.

Now if you have a significant Lua codebase, and you are verifying things like customer configuration for example (over which you have no control) - you can only do that in init_by_lua, by using assert() to verify configuration validity and/or raising a fatal error() if there is a config issue. And it only makes sense to do it that way. 

And it is consistent with Nginx behavior - config processing being done both in config test and in actual initialization, and both are aborted in case there is a config error.

In fact, the only difference between a config test and an actual startup/reload of Nginx is that config test simply doesn't spawn the actual Nginx workers that listen for incoming traffic. It does everything else and then stops right before the master would fork into workers (as i understand).

It's a simple, clean and elegant model, and it works (or worked..) very well. I don't see why init_by_lua should now be exempted from it for some reason.

A couple years prior to this commit someone asked in lua-nginx-module github issues for this exact change:
And the response from maintainer agentzh was:
> Well, we have actually been taking advantage of the current behavior to test any problems when (pre)loading the application Lua library modules
> [...]
> So if any of these application modules fail to load, the test config can catch these errors.

Which makes perfect sense.
So just wondering why was this change made now? Does anyone know the reason(s) ?
Reply all
Reply to author
0 new messages