nginx kill nginx.pid

daBee

Active Member

Reaction score: 7
Messages: 190

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?
 
OP
OP
daBee

daBee

Active Member

Reaction score: 7
Messages: 190

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
 

ShelLuser

Son of Beastie

Reaction score: 1,693
Messages: 3,512

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).
 
OP
OP
daBee

daBee

Active Member

Reaction score: 7
Messages: 190

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
 

drhowarddrfine

Son of Beastie

Reaction score: 1,122
Messages: 3,059

nginx does its own log rollover but maybe I'm mis-reading what you're doing.
Even with these errors, the service is working fine.
The reason it's fine is because the address is in use by a running nginx and you're trying to start another.
 
OP
OP
daBee

daBee

Active Member

Reaction score: 7
Messages: 190

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.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 7,182
Messages: 29,471

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).
 
OP
OP
daBee

daBee

Active Member

Reaction score: 7
Messages: 190

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.
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 7,182
Messages: 29,471

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.
 
Top