Hello!
On Fri, Nov 22, 2013 at 2:02 PM, <i...@ecsystems.nl> wrote:
>
> A simple 'nginx' is all, with the nginx 1.5.7.2 Caterpillar version of
> course, but even simple unmodified nginx source+lua does the same thing.
>
Here is my test script in bash named "test.sh":
#!/usr/bin/env bash
NGINX=/usr/local/openresty/nginx/sbin/nginx
if [ ! -d logs ]; then
mkdir logs
fi
echo > /tmp/debug.txt
if [ -f logs/nginx.pid ]; then
kill -QUIT `cat logs/nginx.pid`
sleep 0.1
fi
$NGINX -p $PWD -c a.conf
cat /tmp/debug.txt
And below is the content in our nginx configuration file a.conf:
worker_processes 2;
error_log logs/error.log;
pid logs/nginx.pid;
events {
worker_connections 1024;
}
http {
init_by_lua '
if count == nil then count = 0; end;
count = count + 1;
local filex = io.open("/tmp/debug.txt", "a");
filex:write("count "..tostring(count).."\\n");
io.close (filex);
';
server {
listen 5678;
server_name localhost;
location / {
root html;
index index.html index.htm;
}
}
}
Note that we configure 2 workers here in the nginx configuration file.
And then run the test.sh:
$ ./test.sh
count 1
we can see that only one line "count 1" is in the file /tmp/debug.txt.
So the init_by_lua runs only once, as expected.
Can you test both my a.conf and test.sh above on your side?
>
> Then its a bug, question remains where, in nginx, in the Lua/nginx interface
> or Lua itself?
>
Please note that, when you use the "nginx -sstop" command to shut down
the nginx server, nginx will load the configuration first which
triggers Lua VM initiation (though it throws this new VM away
shortly). So always use kill -QUIT to shutdown your Nginx server. This
is the expected behavior, not a bug.
> I can validate 1 extra init run because when there is a Lua program error
> nginx aborts loading so it does do some validation at startup
> and of course
> while validating, any file reading/writing is done as well eventhough it
> should not behave like this while validating.
>
Let's talk about concrete and complate example that can reproduce the
issue with precise steps. Such (vague) description does not help much,
unfortunately.
>
> The second run must be the master loading and executing at startup and the
> third+ runs must be each worker doing the same as the master.
>
No, init_by_lua always runs while loading the configuration, which is
always in the master process and *before* forking out worker
processes. The init_by_lua thing does not run in each workers at all.
If yes, then it is a bug. And you'll have to provide a complete and
working example that can reproduce the issue on my side with precise
steps.
> Maybe we need to be able to test init_by_lua is running for a worker to make
> sure it only runs once.
>
As I've said, you have to provide a minimal and complete example. In
this email, I've already provided a minimal and complete example
(based on your original incomplete example) that suggests the other
way around.
Regards,
-agentzh
