I'm having an issue with SIGTERM, frequently my redis server is shut down by SIGTERM signal and i cannot find the reason. Are there any specific reasons to receive SIGTERM. Or is there any way to override redis signal handler...?
this the redis log for the shutdown
17164 | signal handler Received SIGTERM, scheduling shutdown... [17164] 23 Nov 00:03:01.996 # User requested shutdown... [17164] 23 Nov 00:03:01.996 * Saving the final RDB snapshot before exiting. [17164] 23 Nov 00:03:02.013 * DB saved on disk [17164] 23 Nov 00:03:02.013 # Redis is now ready to exit, bye bye...
Comment From: badboy
There are multiple ways this can happen. How much memory does redis use? How much memory does the machine have? If your memory is full the Kernel will kill programs. Check the kernel logs. If that's not the case check if any cronjobs, monitoring systems or other daemons are sending the SIGTERM.
Comment From: antirez
Hello, I believe that the kernel OOM kills with SIGKILL, so this is likely to be an user process... We can turn this into a feature request to log the PID of the killing process maybe?
Comment From: subhash-rajapaksha
this is my memory info part,
used_memory:1914272 used_memory_human:1.83M used_memory_rss:3403776 used_memory_peak:2152264 used_memory_peak_human:2.05M used_memory_lua:31744 mem_fragmentation_ratio:1.78 mem_allocator:jemalloc-3.2.0
since (used_memory_peak_human > used_memory_human), can this cause OOM kill, if so how can i increase allocated used memory for redis.
Comment From: badboy
You're using about 2Mb of memory. I'm sure you have atleast a Gb of memory. So no, this is not an OOM kill (and as antirez said the OOM killer sends SIGKILL).
Comment From: subhash-rajapaksha
egrep -i 'killed process' /var/log/messages
this command gave nothing, seems OOM killer is not responsible. by the way, I'm using a VM as the server, are there any known issues for vm.
redis_version:2.6.12 redis_git_sha1:00000000 redis_git_dirty:0 redis_mode:standalone os:Linux 2.6.18-308.el5 x86_64 arch_bits:64 multiplexing_api:epoll gcc_version:4.1.2 process_id:30698 run_id:4610ed61d1d2e348969ea4b3133b6bb4873f6329 tcp_port:6379 uptime_in_seconds:29674 uptime_in_days:0 hz:10 lru_clock:157887
Comment From: subhash-rajapaksha
the issue is figured out. At RDB file saving, the saving process is created in the same name of redis_server process, therefore when redis server data is saving to RDB file, there are two processes with two pid's but in the same name. my server application administration is configured to identify duplicate instance, so he identifies this saving child process as a duplicate process of redis. therefore he kills all duplicate processes and restarts. thanks for every help... :)
Comment From: sebastiantoro
@subhash-rajapaksha You didn't mention how did you solve the issue. Clearly this is quite an old thread but I am having this issue and would like to know how it was solved. Thanks in advance.
Comment From: jaehocho
I am having similar issue. I would love to hear how you fixed it
Comment From: richardm-surevine
I've got the same issue, on ECS. But only one redis process per instance.
Comment From: ShwetaDeep
I was running into the issue when running 2 redis instances on the same VM. Second instance would start and then receive SIGTERM and shutdown.
Changing supervised no in redis.conf to supervised systemd fixed this issue.
Comment From: aniruddha-a
I had quite many issues with more than one redis instance, turned out to be due to the backup RDB file writing! Even though I had given different directories+filename in the config files - it didnt work for me!
Comment From: aniruddha-a
I wish @subhash-rajapaksha could detail what the resolution was! Looks like I am hitting the same issue but the resolution detail is unclear!
Comment From: WiFeng
the issue is figured out. At RDB file saving, the saving process is created in the same name of redis_server process, therefore when redis server data is saving to RDB file, there are two processes with two pid's but in the same name. my server application administration is configured to identify duplicate instance, so he identifies this saving child process as a duplicate process of redis. therefore he kills all duplicate processes and restarts. thanks for every help... :)
@aniruddha-a If they are the same issue, I think you can check your server application administration configuration.
Comment From: SergykKhalif
In /etc/redis/redis-server.conf set: daemonize yes
Comment From: YuJF6
The same issue occurs when starting Redis by configuring the systemd service file. The daemonize in the configuration file cannot be set to yes. Of course, as mentioned in the official comment: "When Redis is supervised by upstart or systemd, this parameter has no impact", but when compiling Redis, it should support upstart or systemd functionality.