nginx service commands not working any more if auto_ssl:init()

[communiteq]

We have an openresty 1.11.2.2 on Ubuntu 12.04 LTS and/or Ubuntu 14.04, and we're having issues with the service start/stop commands since we started using lua-resty-auto-ssl.

I have been able to narrow it down to a single line in the configuration file.
Once the line auto_ssl:init() in nginx.conf is commented out of nginx.conf, everything works. (i.e. all normal nginx/openresty functionality)

Once the line auto_ssl:init() is active, nginx can be started once using service nginx start or start nginx, but when a stop is attempted (service nginx stop or stop nginx)
nginx does stop, but the stop command never returns, and from that moment on, the start and stop commands do not work any more, until a reboot. No nginx processes are left running.

nginx can still be started by issuing the nginx command, and stopped using nginx -s stop...

openresty is self-compiled, lua-resty-auto-ssl 0.10.5 is installed using luarocks.

Do you have some pointers on this?

[GUI]

If nginx -s stop is still working, then I'm wondering if this issue is related to the script you're using to start and stop nginx as a service (although it's still odd that this init() is making a difference). So what type of service script are you using? Do you have an init.d script, or are you using upstart, or something else? Could you share the contents of that script?

And are there any errors being logged to your nginx error log file on either startup or shutdown?

Since it seems like the service script is getting hung up on shutdown, one other potential thing to debug is to see if any child processes are being left around. If you're using something like upstart, I'm wondering if the sockproc process might be left running, which might be confusing the shutdown script if it's paying attention to process groups. One way to potentially debug this is to use pstree to see what processes are running as a child to nginx. So after starting nginx, you could try running pstree -a -p and find the nginx processes in this output. Then after attempting to stop nginx, try running that same command again and see if there's still any processes hanging around under nginx's parent process.

[communiteq]

We're using upstart. Yes, it definitely has to do with the startup script, but it definitely has to do with auto_ssl:init() as well... those two are just not playing nicely together.

Here is /etc/init/nginx.conf

description "nginx - small, powerful, scalable web/proxy server"

start on filesystem and static-network-up
stop on runlevel [016]

expect fork
respawn

pre-start script
        [ -x /usr/sbin/nginx ] || { stop; exit 0; }
        /usr/sbin/nginx -q -t -g 'daemon on; master_process on;' || { stop; exit 0; }
end script

exec /usr/sbin/nginx -g 'daemon on; master_process on;'

pre-stop exec /usr/sbin/nginx -s quit

No errors in any logs. Yes, after some web searching I'm totally suspecting sockproc as well, but I don't even see it running.

 1578 ?        Ss     0:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
 1579 ?        S      0:00  \_ nginx: worker process                           
 1580 ?        S      0:00  \_ nginx: worker process                           
 1581 ?        S      0:00  \_ nginx: worker process                           
 1582 ?        S      0:00  \_ nginx: worker process                           
 1583 ?        S      0:00  \_ nginx: cache manager process  

Problem is: nothing seems to be stuck. After stopping they're all gone...

[communiteq]

Update: somehow removing expect fork solves this issue.

[GUI]

@discoursehosting: Sorry for the belated followup, but thank you very much for the sleuthing! Very interesting. I'm not super-familiar with upstart, but it definitely seems like us starting sockproc inside nginx is somehow interfering with how Upstart tracks forked processes. I'm glad you were able to find the workaround with removing expect fork, but I'll have to play around with Upstart at some point to see if there's a cleaner way we could be handling this.