Hi! it seems that "sudo /etc/init.d/redis start" does start Redis but the init script does not return control / terminate: # sudo /etc/init.d/redis start * /var/run/redis: correcting mode * /var/run/redis: correcting owner * Starting redis ... <HANGING> Any ideas?
How did you build redis? Mind sharing your configuration? I've some instances running,never saw this.
Hi! (In reply to Tomáš Mózes from comment #1) > How did you build redis? Mind sharing your configuration? * USE="jemalloc -luajit -tcmalloc -test" * default configuration, zero changes Anything else?
Seems we edited the init script for stable releases: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6f9cc73493d498749aadc4322ba0a8accda697b8 Sebastian, try to enable daemon mode: # By default Redis does not run as a daemon. Use 'yes' if you need it. # Note that Redis will write a pid file in /var/run/redis.pid when daemonized. daemonize yes Seems like that commit only fixed situations when you had daemonize on. My myself never had it on, so the old style worked for me.
Thanks Tomáš! works for me.
(In reply to Tomáš Mózes from comment #3) > daemonize yes Works well for me, too. > Seems we edited the init script for stable releases: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=6f9cc73493d498749aadc4322ba0a8accda697b8 Could it be that that patch is for "deamonize yes" only? If so, maybe the init script could grep the config file and check for "deamonize yes" or "deamonize no" and adjust start_stop_daemon_args on the fly? Austin, what do you think?
(In reply to Sebastian Pipping from comment #5) > (In reply to Tomáš Mózes from comment #3) > > daemonize yes > > Works well for me, too. > > > > Seems we edited the init script for stable releases: > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > > ?id=6f9cc73493d498749aadc4322ba0a8accda697b8 > > Could it be that that patch is for "deamonize yes" only? If so, maybe the > init script could grep the config file and check for "deamonize yes" or > "deamonize no" and adjust start_stop_daemon_args on the fly? > > Austin, what do you think? Yes please. We broke the default installation this way :-/
Just ran into this issue as well while updating redis for my django channels server. Here is my shot at fixing this, perhaps it could be used for reference. get_daemonize_data() { if tac "${REDIS_CONF}" | grep -qm 1 -e '^\s*daemonize\s\+yes'; then pidfile="$(tac /etc/redis.conf | perl -e 'while(<>){ if(/^\s*pidfile\s+(\S.*)/) {print $1; exit;}; }')" pidfile="${pidfile:-/var/run/redis.pid}" else start_stop_daemon_args="-b -m -p '${pidfile}' ${start_stop_daemon_args}" fi } A call to this would be added to start_pre and stop functions. I used tac "Since Redis always uses the last processed line as value of a configuration directive". When Redis is set to daemonize, it looks for the pidfile directive in the top level config file, and defaults to what Redis's current default '/var/run/redis.pid'. Note that since there may be include directives, this is no catchall. Assuming/requiring that the default "daemonize no" to be set may be just as good of an option. The authors of redis' default config probably expected init to daemonize it, since its easier for distributions to configure the pidfile that way (ie. keep default config, just alter init script's pidfile variable).
Following KISS, I would say we revert changes rather than make more. There is little reason for most users to set 'daemonize yes' in the config since init handles that. And those that have to for some reason can change/maintain the init script themselves, though I would assume most who set it did so in error (or now because of this change). Should it be patched to auto-detect, remember to give the systemd init script similar capabilities. Sorry for the double post, forgot this was a mailing list and posted early to save changes, thinking I could edit it.
Seeing the commit I think that this is just a slip in s-s-d understanding of how it handles daemon statuses. The fix looks simpler to me than checking for daemonize and is just to not instruct s-s-d to create the pidfile. changing the openRC init script with this should work: start_stop_daemon_args="--background --pidfile ${pidfile} --chdir \"${REDIS_DIR}\" --user ${REDIS_USER} --group ${REDIS_GROUP}" - it does not hang any more - openRC status will report the redis service running correctly (which is what was tried to be fixed by the breaking commit) Could someone test as well and report that this is indeed a good solution to our problem ? If so, I'll deploy & revbump everything to fix this ASAP.
(In reply to Ultrabug from comment #9) > Seeing the commit I think that this is just a slip in s-s-d understanding of > how it handles daemon statuses. > > The fix looks simpler to me than checking for daemonize and is just to not > instruct s-s-d to create the pidfile. > > changing the openRC init script with this should work: > > start_stop_daemon_args="--background --pidfile ${pidfile} --chdir > \"${REDIS_DIR}\" --user ${REDIS_USER} --group ${REDIS_GROUP}" > > > - it does not hang any more > - openRC status will report the redis service running correctly (which is > what was tried to be fixed by the breaking commit) > > Could someone test as well and report that this is indeed a good solution to > our problem ? > > If so, I'll deploy & revbump everything to fix this ASAP. I can confirm adding --background option to start_stop_daemon_args worked for me. I haven't had to add --pidfile ${pidfile} though.
I've fixed the init script and left the pidfile option for what appears to me QA reasons. Will also do some revbumps soon. Closing.
(In reply to Ultrabug from comment #11) > I've fixed the init script and left the pidfile option for what appears to > me QA reasons. > > Will also do some revbumps soon. Closing. Thanks, works fine now with both redis set as deamonize true/false. If I understand correctly it means it will send it to background in both cases.
And next time, please, let's not modify the init script corresponding to the stable release :)
