Your message dated Thu, 28 Jan 2021 10:18:47 +0000 with message-id <e1l54nz-0004qz...@fasolo.debian.org> and subject line Bug#981226: fixed in redis 5:6.0.9-4 has caused the Debian Bug report #981226, regarding redis: New systemd integration breaks replicaof handling to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 981226: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981226 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Source: redis Source-Version: 5:6.0.9-3 Severity: important Tags: upstream patch Forwarded: https://github.com/redis/redis/pull/8409 [ This might be worth being serious, but I'm not sure this falls under uncommon usage or similar, or not, so please bump if you agree. :) ] Hi! While preparing to switch to bullseye, we noticed that the new systemd integration breaks with replicaof handling. I've submitted this upstream, but it would be nice to fix in Debian even if upstream does not apply this in time for the freeze. The github PR and the attached patch against the version in Debian, describe the problem in further detail. Thanks, GuillemFrom f9505104123664c45b762b8a7bb15406c205c01d Mon Sep 17 00:00:00 2001 From: Guillem Jover <gjo...@sipwise.com> Date: Tue, 19 Jan 2021 00:34:59 +0100 Subject: [PATCH] Send the readiness notification when we are ready to accept connections On a replica we do accept connections, even though commands accessing the database will operate in read-only mode. But the server is still already operational and processing commands. Not sending the readiness notification means that on a HA setup where the nodes all start as replicas (with replicaof in the config) with a replica that cannot connect to the master server and which might not come back in a predictable amount of time or at all, the service supervisor will end up timing out the service and terminating it, with no option to promote it to be the main instance. This seems counter to what the readiness notification is supposed to be signaling. Instead send the readiness notification when we start accepting commands, and then send the various server status changes as that. Fixes: commit 641c64ada10404356fc76c0b56a69b32c76f253c Fixes: commit dfb598cf3304818e608ceb6b5d9529a293345c4a --- src/replication.c | 6 ++---- src/server.c | 4 ++-- 2 files changed, 4 insertions(+), 6 deletions(-) --- a/src/replication.c +++ b/src/replication.c @@ -1832,8 +1832,7 @@ void readSyncBulkPayload(connection *con serverLog(LL_NOTICE, "MASTER <-> REPLICA sync: Finished with success"); if (server.supervised_mode == SUPERVISED_SYSTEMD) { - redisCommunicateSystemd("STATUS=MASTER <-> REPLICA sync: Finished with success. Ready to accept connections.\n"); - redisCommunicateSystemd("READY=1\n"); + redisCommunicateSystemd("STATUS=MASTER <-> REPLICA sync: Finished with success. Ready to accept connections in read-write mode.\n"); } /* Restart the AOF subsystem now that we finished the sync. This @@ -2340,8 +2339,7 @@ void syncWithMaster(connection *conn) { if (psync_result == PSYNC_CONTINUE) { serverLog(LL_NOTICE, "MASTER <-> REPLICA sync: Master accepted a Partial Resynchronization."); if (server.supervised_mode == SUPERVISED_SYSTEMD) { - redisCommunicateSystemd("STATUS=MASTER <-> REPLICA sync: Partial Resynchronization accepted. Ready to accept connections.\n"); - redisCommunicateSystemd("READY=1\n"); + redisCommunicateSystemd("STATUS=MASTER <-> REPLICA sync: Partial Resynchronization accepted. Ready to accept connections in read-write mode.\n"); } return; } --- a/src/server.c +++ b/src/server.c @@ -5324,10 +5324,10 @@ int main(int argc, char **argv) { if (server.supervised_mode == SUPERVISED_SYSTEMD) { if (!server.masterhost) { redisCommunicateSystemd("STATUS=Ready to accept connections\n"); - redisCommunicateSystemd("READY=1\n"); } else { - redisCommunicateSystemd("STATUS=Waiting for MASTER <-> REPLICA sync\n"); + redisCommunicateSystemd("STATUS=Ready to accept connections in read-only mode. Waiting for MASTER <-> REPLICA sync\n"); } + redisCommunicateSystemd("READY=1\n"); } } else { InitServerLast();
--- End Message ---
--- Begin Message ---Source: redis Source-Version: 5:6.0.9-4 Done: Chris Lamb <la...@debian.org> We believe that the bug you reported is fixed in the latest version of redis, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 981...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Chris Lamb <la...@debian.org> (supplier of updated redis package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Format: 1.8 Date: Thu, 28 Jan 2021 10:12:06 +0000 Source: redis Built-For-Profiles: nocheck Architecture: source Version: 5:6.0.9-4 Distribution: unstable Urgency: medium Maintainer: Chris Lamb <la...@debian.org> Changed-By: Chris Lamb <la...@debian.org> Closes: 981226 Changes: redis (5:6.0.9-4) unstable; urgency=medium . * Send systemd readiness notification when we are ready to accept connections in order to fix systemd integration when Redis is used with replicaof. Thanks to Guillem Jover for the report and patch. (Closes: #981226) Checksums-Sha1: 20c9d19972d3be509fca0a75894be067c7aba7e8 2257 redis_6.0.9-4.dsc e853bfae6f30151dc6400acff69a74e3fbb5e17e 28860 redis_6.0.9-4.debian.tar.xz a98654bdb4044240a91313446c9926d710b1c4aa 7295 redis_6.0.9-4_amd64.buildinfo Checksums-Sha256: e06e5d46bf317fe7c13e46f95ea3549505100943692f8f2d7998e2414b40878f 2257 redis_6.0.9-4.dsc cead8747cbb151771a945da5b4d4fdaa9f21678b15535c985af8b0aba1769bec 28860 redis_6.0.9-4.debian.tar.xz b60d69967c5e52b25919b58cf4cd2873902dd221d77dcb321b5a3885150c225a 7295 redis_6.0.9-4_amd64.buildinfo Files: 20018ecfab84f476966ff93d0368766b 2257 database optional redis_6.0.9-4.dsc 8f4a288213820b74d28a0d284b3c84ce 28860 database optional redis_6.0.9-4.debian.tar.xz 5e44e3d2d61e2d022357de6a333377d2 7295 database optional redis_6.0.9-4_amd64.buildinfo -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEwv5L0nHBObhsUz5GHpU+J9QxHlgFAmASjkYACgkQHpU+J9Qx Hlg4oxAAq4RluSxxGG3ov++dFOELDnL7mT5C9YVG8mnCLEI1B+je1HkFpMQDc0YF ep+UnbPihSL/ajY22EJVWvVRWI8zfRJErFH/+UatsNal/YjRFPjPo9/nGEFhrwR3 d1EVZ6c3sKlRzs+iHEKZxgAyP3GJt2jYrkyNvckidGW1odOCsRSweFoCzY8Iw8TM NSaAbT+LQobnuQ//UX7tTTs+tFjmxqhfqfWhy/V/2GKg0nwAOtNJ0Ve5uRygluFO PJDR5koiJv96j0/lJ5Kv6U98UwBGsq3MQd65Fjw3JfcVR9BzrOTmh+hzOf6S/V18 wyhAIU1+vyyCYTY1qDGwjSlmlc+z08sNw6qg54DwH+iUoF2VhskDEv36ydK5iiUh w/z3MwWLBHTlLuEvAJGTDWZiczDH1wfOGBaXus07v6vof6WbISTw8/8v+3lcWnzM yisUHmLLboBErFu6XRi7xu2ljFfkGNUICe1E6PPVFm7ROFa8NHsJD4cXALSKWT0h lWcFD6CTZzwpxucK3R2srifvFUqyPESw3BCUFz/kEHi+prKyN9EYBDC9HWQucUMq QfXekKxkeKuS5nOLHW0a8+N9WVjIoGthJatWNvkg0w1dsAojevRQL8ecRVna8MEK C9x3hD9zc/63pXLSKZxF+a94s//w+5tnkQivsrjZ8D86p7pQpaM= =i8T7 -----END PGP SIGNATURE-----
--- End Message ---
