Nginx does not re-open log files on SIGUSR1.

Gena Makhomed gmm at csdoc.com
Mon Jan 3 19:20:36 MSK 2011


On 03.01.2011 17:19, John Feuerstein wrote:

> Apache has apachectl[1] or httpd's "-k" option for quite some time now.
> It is used by many distributions in init scripts and log rotation
> scripts instead of hardcoding signals and paths to pid files everywhere.

apachectl is ulgy hack, which *must* be used becouse apache has

   -D name            : define a name for use in <IfDefine name> directives
   -d directory       : specify an alternate initial ServerRoot
   -f file            : specify an alternate ServerConfigFile
   -C "directive"     : process directive before reading config files
   -c "directive"     : process directive after reading config files
   -e level           : show startup errors of level (see LogLevel)
   -E file            : log startup errors to file

options, which can dramatically change behavior of apache instance.

and apachectl is just shell script, which only read /etc/sysconfig/httpd
options before execution -k start|restart|graceful|graceful-stop|stop

and this is the main reason why httpd -k can't be used for this -
because it didn't read options from /etc/sysconfig/httpd config file.

> Nginx has the "-s" option. For me, this appears to be cleaner and
> simpler than to remember or always look up what custom signal X does to
> this daemon. For the most basic set of control signals I agree with you,
> but it still has the downside of having to find the pid first (and
> hardcoding parameters of the daemon configuration into external scripts).

just use

service nginx start|stop|reload|force-reload|restart|status|configtest

for control over nginx via command line.

and nginx -s now can't be used for control over nginx instances in UNIX
by same reason as httpd -k can't be used for control over httpd instances.

adding nginxctl is useless, because "service nginx ..." already exists

and

kill -USR1 `cat /var/run/nginx.pid`

works significantly faster then

nginx -s reopen

-- 
Best regards,
  Gena



More information about the nginx mailing list