Stopping NGINX process on initialization error

[Bruno Alvisio]

Hi all,

As part of the "init_worker_by_lua" code, I would like stop/exit the nginx process if there is an error. How can achieve that from LUA?

On related issue, would it make sense to unconditionally return 500 if an error is encountered during initialization instead of stopping the nginx process altogether?

Thanks!

Bruno

[xie cui]

you can try to call a c function exit() by using ffi.

Bruno Alvisio <bruno....@gmail.com> 于2020年7月16日周四 下午6:45写道：

--
You received this message because you are subscribed to the Google Groups "openresty-en" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openresty-en...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openresty-en/70843877-b69f-427f-9466-c78d6329c2f3o%40googlegroups.com.

[Bruno Alvisio]

Thanks. Calling 'os.exit()' works.

However, what I would actually like to do is to stop the nginx master process if a certain type of error occurs in one of the worker processes. Is there any way I can do this?

The reason I want to do this is that I am making a HTTP request when loading one of my LUA modules (I cannot do this in the init_by_lua since there is no support for this yet). If there is an error executing this request I would like ngnix to stop processing any further requests. (for example by stopping nginx altogether)

Thanks

Bruno

To view this discussion on the web visit https://groups.google.com/d/msgid/openresty-en/CAPbdGGdWNKZawO39Z5aZXbvJQ1ZygV15HHNfYCiBs9QqphkE5Q%40mail.gmail.com.

[Reed Weichler]

I don't have an answer to your question. I tried killing the parent process via ffi, which was unsuccessful. Posting here in case other people were curious:

local ffi = require 'ffi'
local SIGKILL = 9
local SIGTERM = 15
ffi.cdef[[
typedef int pid_t;
pid_t getppid();
int kill(pid_t pid, int sig);
]]
ffi.C.kill(ffi.C.getppid(), SIGKILL) -- returns -1

[Bruno Alvisio]

Thanks for the answer Reed.

The problem was that by default the worker process is run by the "nobody" user.

Once I changed the nginx.conf to run the worker process by root it worked.

thanks

[Igor Clark]

Others may call me over-cautious, but if this were for a service I was running in production on the public Internet, running nginx worker processes as root would make me feel very anxious.

nginx (et al) drop as many privileges as they can, as soon as they can, so as to avoid exposing processes with root privileges to any old client on Internet who could be fuzzing for whatever they can find, searching brute-force for exploits. Or people might have nasty zero-days. We don't know.

It might be a trade-off you're happy to make in order to be able to stop the server as you need, and that's totally your decision :-) But for what it's worth, I wouldn't want to do that, and would try to find some other way if possible. I don't know exactly how to do that, and haven't looked into it deeply - maybe you could do something somewhere in some part of you your orchestration layer, or systemd, or whatever you have starting and running nginx, maybe even thinking round the edges and coordinating somehow with some other service. I don't know. I just know that I wouldn't want to run services open to Internet abuse as root.

nginx and OpenResty certainly are solid and well-tested in battle, and I'm sure given OpenResty's heritage it seems at least very unlikely that there are many buffer overflows lying in wait - but nginx itself is not immune to vulnerabilities (https://www.cvedetails.com/product/17956/Nginx-Nginx.html?vendor_id=10048), and OpenResty is so much less high-profile than nginx that anything like that hiding inside it may simply not have been discovered yet.

Of course it's entirely your call, and I'd be interested to hear other opinions if people here disagree with me, but, just my 2 cents: I would try to avoid doing that.

cheers,

Igor

-- 
You received this message because you are subscribed to the Google Groups "openresty-en" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openresty-en...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openresty-en/15385070-4ed0-44b3-9432-566fe2e406bdo%40googlegroups.com.

[Reed Weichler]

Glad I could help.

I agree exposing a root process to the public Internet is probably bad if you are afraid of getting pwned. Maybe you could have a separate daemon to kill the master process.

To view this discussion on the web visit https://groups.google.com/d/msgid/openresty-en/B25F1D93-147E-4B0E-AEF5-935C7DF2B023%40gmail.com.