Redis service for systemd on Linux

redis.service

[Unit]
Description=Redis persistent key-value storage
After=network.target

[Service]
Type=notify
ExecStart=/usr/bin/redis-server /etc/redis.conf --supervised systemd --daemonize no
ExecStop=/usr/bin/redis-cli -p 6379 shutdown
ExecReload=/bin/kill -USR2 $MAINPID
Restart=always

[Install]
WantedBy=multi-user.target

--daemonize no will hang the redis

@willzhang
Mode --supervised systemd requires --daemonize no. Otherwise, it should be turned on.

The ExecStop value is problematic if there is auth set. It seems to work fine without it because systemd will just send a SIGTERM to the process.

@crussell52 is there a better way to handle ExecStop to account for both auth and non-auth cases?

Without defining an ExecStop, systemd will send a SIGTERM to the process. At least in Redis 6, the server process seems to recognize that as a shutdown signal.

…

On Thu, Oct 14, 2021, 11:21 AM Sergii Shymko ***@***.***> wrote: ***@***.**** commented on this gist. ------------------------------ @crussell52 <https://github.com/crussell52> is there a better way to handle ExecStop to account for both auth and non-auth cases? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://gist.github.com/898aee7d0ec0e3d2a8a41f0956756530#gistcomment-3927104>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAC3T7UXU3OM2XNQQ2DZXYTUG3YPVANCNFSM4KQCTREA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

@crussell52
The reason to include ExecStop was to distinguish Redis instances running on different ports.
But looks like you're right, omitting the stop command will work in this case as well.