This took a while for me to figure out, but I finally got it. This is related to the implementation fixes for https://github.com/antirez/redis/issues/162
I think it could be solved with the docs - though there might be another issue or two involved
If the kernel's max files is too low, then redis seems to lower it's requirement by re-spawning a new process. In practice, it looks like redis respawns a few times until it can start fully with an allowable max number of files files, because it can't grab the port from the previous process. I could be 100% wrong on this, but looking at my logs it appears that redis will respawn 10x, before it can grab the port.
As a result of this, redis will start from the init scripts, BUT the actual redis has a different PID than what was logged by the startup scripts. Calls to service stop redis-server will use the older, invalid, PID -- not the newer one -- and always fail.
There could be another issue going on, but if this is all that is happening... the docs should simply note that the init scripts will inherently fail unless you fix the max-files allocation.
Comment From: badboy
Redis does not respawn itself. All it does is trying to find a better limit or bailing out if it can't set the limit high enough.
Comment From: yoav-steinberg
@jvanasco I don't think your analysis is correct since redis does not respawn itself. This is old, but if this is still relevant then you may try to start redis not as a service, just run it as is, and see if the PID changes. If you can't figure it out, then perhaps ask the distro's package maintainer what is going on. What distro are you using? Who wrote the init scripts? I'm marking to be closed as this is old.
Comment From: jvanasco
Thanks for the reply.
This was under Ubuntu. Based on the date, likely 16.04; and definitely using their scripts. Also likely the 2.4 branch, if not earlier.
Feel free to mark as stale and close, I do not have a free system right now to do the tests you suggest and check if the respawning was caused by Redis or Ubuntu.
I do remember a bit about debugging this years ago, and do recall the change from the above PR somehow causing several instant restarts with different PIDs before succeeding on startup - but only the first PID was logged. i also recall the fix was increasing the ulimit.
On Sep 14, 2021, at 3:07 AM, yoav-steinberg @.***> wrote:
@jvanasco I don't think your analysis is correct since redis doesn not respawn itself. This is old, but if this is still relevant then you may try to start redis no as a service, just run it as is, and see if the PID changes. If you can't figure it out, then perhaps ask the distro's package maintainer what is going on. What distro are you using? Who wrote the init scripts? I'm marking to be closed as this is old.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.