Initd script - why check pidfile exists? about redisio HOT 10 CLOSED

If I compare let say to the nginx init.d script, if I run /etc/init.d/nginx start it does not warn me or anything that there's a PID file, it just go ahead and output Starting nginx: nginx. and the pid never change.

Meanwhile I've forked the repository and removed the if, tell me if you want me to PR.

Thanks!

from redisio.

Question, can't you feed monit the pid file of the process you are watching? It seems to me the problem is that something is trying to create a pid file for redis, when redis is creating it itself. If this is a problem you could configur e redis so that it doesn't create its own pidfile and doesn't deamonize.

The pidfile check should be there, if it's failing then that says to me that there is an existing pidfile that wasn't removed for some reason, or that something is trying to create a pidfile for redis even though redis wants to create it itself.

Doesn't monit allow something like the following:

check process redis-server with pidfile /var/run/redis/6379.pid

from redisio.

Yes, it checks the process without problem. The problem is when the process crash (i.e kill -9 1234), the pid is still there, but the process is not running anymore. Monit successfully finds out that the process is missing, even if the pid file is there present. Monit then try to send a restart command (/etc/init.d/redis restart), but it does not spin a new redis server, since the pid if in the init.d script blocks it.

Makes sense?

from redisio.

Well this makes sense because if the process died with an unrecoverable error the pid file will never be cleaned up. You probably don't want to automatically start the process again if it died without allowing for cleanup. You could very well have corrupted AOF files, or your RDB may never have gotten written to disk. If you were to send it a SIGTERM as opposed to SIGKILL it would clean up its pidfile and monit would start it again. Also you wouldn't want to use restart on a process that died unnaturally you would just want to START it.

I do not believe removing the logic around checking the pid file is the proper answer here. That means if you issue 3 starts you have 3 processes running but only 1 of them is actually recorded in the pidfile. The proper answer would be for monit or something else to clean up the pid file if the process died in an unnatural manner.

from redisio.

Start it back with monit, not restart it, small typo sorry :)

From my test, if I issue 3 start command without the if, only 1 process is run. Redis must be checking that a pid files does not exists before starting a new process. That's why I think the if in the init file is not required, since this "check" seems to already be in redis-server. Same thing goes for nginx, I can issue multiple start command without additional check in the init script, and only 1 process is launched.

I don't think there's a way for Monit to remove a stale pid file. God.rb looks like it has a command to do it: w.behavior(:clean_pid_file) here: http://godrb.com/

from redisio.

Another option would be to let the init script check for the pidfile, but then read it and check for the pid in the processes list - if the process is not running, it means the pidfile is stale, and it should be able to confidently overwrite it (i.e executing a new start command).

Thoughts?

from redisio.

You could very well have corrupted AOF files, or your RDB may never have gotten written to disk.

We wouldn't know if RDB didn't get written (if the process was gone). I would be more concerned if the db file was corrupted, but wouldn't this get caught during a START (or RESTART)?

from redisio.

This seems like it might get caught in a restart. It seems like it may be reasonable to just add further checks to the init script to allow it to pull out the pid and check if it is actually running.

from redisio.

Closing as old issue, please reopen if this is still a problem?

from redisio.

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

from redisio.