nginx kill nginx.pid

Hi folks. Other confusion with nginx. I'm trying some regular log rollovers and want to kill the process.

I have read that after moving and renaming my nginx.log, I want to do this:

Code:
kill -USR1 $( cat /var/run/nginx.pid )

That is the proper location of the pid file. The kill stops the server so it can release that binding to the log, and the -USR1 forces a new log.

That kill command throws an error manually:

Code:
kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]

Can I just insert a sudo nginx service restart in a script run in the crontab?
 
Well here's part of the answer with the above command. Even with these errors, the service is working fine.

Code:
[Tue May 01 02:52:07 adminuser@serverbox /var/log/nginx/expired_logs] sudo service nginx start
Performing sanity check on nginx configuration:
nginx: the configuration file /usr/local/etc/nginx/nginx.conf syntax is ok
nginx: configuration file /usr/local/etc/nginx/nginx.conf test is successful
Starting nginx.
nginx: [emerg] bind() to 0.0.0.0:8080 failed (48: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:8081 failed (48: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:8080 failed (48: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:8081 failed (48: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:8080 failed (48: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:8081 failed (48: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:8080 failed (48: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:8081 failed (48: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:8080 failed (48: Address already in use)
nginx: [emerg] bind() to 0.0.0.0:8081 failed (48: Address already in use)
nginx: [emerg] still could not bind()
/usr/local/etc/rc.d/nginx: WARNING: failed to start nginx
 
Why bother though? That's what newsyslog(8) is for. Check /usr/local/etc/newsyslog.conf.d to see what config files are already present. I don't use nginx myself but it is possible that it has set something up in there. And if not then this is the de-facto thing to use for logfile rotation. See also newsyslog.conf(5).

The advantage with this system is that you're in full control over the whole procedure. You can decide when it should rotate depending on time or filesize, how many files should be kept in retention, if (and how) they should be archived and of course also how the host process should be initialized. And I even forgot to mention the ownership and permission bits of the new logfile, those can be configured as well.

So yeah, I'd recommend using newsyslog over any manual scripting. Especially because chances are high that this daemon is already active on your system (it's enabled by default).
 
Well look at that. I will have a very good look. Thanks for that. I found it odd that nginx didn't have anything built in. Cheers
 
nginx does its own log rollover but maybe I'm mis-reading what you're doing.

I would have thought a much more robust rollover group of actions.

The reason it's fine is because the address is in use by a running nginx and you're trying to start another.

Sorry, that should have been sudo service nginx restart, so a stop and a start. After the first sanity check, I get this: [cmdnginx not running? (check /var/run/nginx.pid).[/cmd]. So it takes the restart, sanity check, shuts down, says it's starting up, and fails because it's already running.
 
There's no need to restart the whole nginx process. Simply sending a SIGUSR1 is enough to re-open the log files.
The kill stops the server so it can release that binding to the log, and the -USR1 forces a new log.
Actually, no. The kill doesn't stop the server. All the command does is send a SIGUSR1 signal(3) to the process. It's the nginx process that captures that signal and acts accordingly (it's a user defined signal).
 
OK I moved to the newsyslog yesterday to archive overnight and outside of a rollover notice placed into the new log, things went smooth. Exactly what I was looking for. I was trying to roll my own for monthly log archives. Couldn't be happier.

I was under the impression a kill simply destroys the whole process. Didn't know it provided a process-defined signal so the process can behave accordingly. Nice to know.
 
I was under the impression a kill simply destroys the whole process.
By default, yes. By default the SIGTERM signal is sent to a process, telling it to gracefully stop. There's also SIGKILL, this will forcefully stop a process (you may have seen somebody do kill -9 <pid>) But the command is a bit of a misnomer because there are a lot of other signals you can send (like SIGUSR1) and not all of them "kill" the process.
 
Back
Top