systemd Unit, Restart, and Log Rotation for Redis

The distro Redis package already ships a systemd unit. Your job is not to rewrite it from scratch. Your job is to know what it starts, how it restarts, where logs go, and how to change one setting without a full-file edit that the next apt upgrade will clobber. A Redis that does not come back after a crash, or that fills /var with redis.log, is an operations bug, not a Redis bug.

On Ubuntu the unit is redis-server.service. On Rocky and Alma it is redis.service. systemctl cat prints the file systemd actually uses, including drop-ins.

Use the package unit, then drop-ins

systemctl cat redis-server
systemctl status redis-server --no-pager -l
systemctl is-enabled redis-server

The package unit already sets Type, User=redis, Group=redis, ExecStart with the config path, and often Restart=always. supervised systemd in redis.conf is the matching server-side setting so Redis signals readiness to systemd. If you installed from source and wrote your own unit, you now own restart policy, ulimits, and upgrades. Prefer the package.

When you need a change, add a drop-in instead of copying the whole unit.

sudo systemctl edit redis-server

That opens /etc/systemd/system/redis-server.service.d/override.conf. A restart policy and open-file limit are the two edits that pay off on a busy cache.

# /etc/systemd/system/redis-server.service.d/override.conf
[Service]
Restart=always
RestartSec=2
LimitNOFILE=65535

Restart=on-failure is stricter: a clean systemctl stop stays down, a crash comes back. Restart=always also restarts a clean exit, which surprises people who run redis-cli SHUTDOWN and watch systemd bring the process back. For a VPS cache, always is usually what you want. For a maintenance window, systemctl stop is the explicit off switch, and you should disable the unit if the stop must survive a reboot.

After the drop-in:

sudo systemctl daemon-reload
sudo systemctl restart redis-server
systemctl show redis-server -p Restart -p LimitNOFILE -p MainPID

LimitNOFILE matters because each client is a file descriptor, plus the AOF, the RDB, and the listening socket. The default 1024 is enough for a laptop and tight for a session store. Redis maxclients should sit below LimitNOFILE, not above it.

Logs: journald first, redis.log second

Many distro units set StandardOutput and StandardError to journal, and the package still writes logfile /var/log/redis/redis-server.log. Pick one as the source of truth. journalctl -u redis-server -e is the fastest incident view. The file is useful if you want logrotate without talking to journald.

journalctl -u redis-server -e --no-pager
journalctl -u redis-server --since "10 min ago"
ls -lh /var/log/redis/

If logfile is set, logrotate must rotate it. Ubuntu usually ships /etc/logrotate.d/redis-server. Read it. If it is missing, add a small file rather than rotating by hand.

# /etc/logrotate.d/redis-server
/var/log/redis/*.log {
    weekly
    rotate 8
    missingok
    notifempty
    compress
    delaycompress
    copytruncate
}

copytruncate is the safe option when Redis holds the file open and you do not want to send a signal. A create-and-kill-HUP setup is cleaner if the unit supports it, but copytruncate will not leave Redis writing to a deleted inode. Weekly plus eight rotations keeps a couple of months. Daily is better if you enabled verbose loglevel. loglevel notice is enough in production. debug will fill High-Speed SSD faster than you expect.

syslog-enabled in older redis.conf files duplicates the same lines into rsyslog. Turn it off if journald already captures stdout.

Restart without surprising the app

systemctl restart redis-server is a full stop and start. Clients see a dropped TCP connection. The app must reconnect. A process manager or a Redis client with retry handles that. A client that caches a socket forever does not.

For config that Redis can apply live, prefer CONFIG SET then write the same value into redis.conf. For bind, port, and supervised, you need a restart. For maxmemory and maxmemory-policy, CONFIG SET is enough for the incident, with a file edit so the next reboot matches.

Do not put ExecStart=/usr/bin/redis-server --port 6379 on 0.0.0.0 in a custom unit because it looked shorter. Keep bind in redis.conf, keep User=redis, and keep the data directory owned by that user. After a crash, systemd Restarts. After a reboot, enable --now is why the cache exists before the first HTTP request.

Netbay VPS nodes in Lucknow run under L3/L4 filtering at the edge. That does not rotate your logs. df -h /var after a week of debug logs is still your check.

Takeaway

Keep the distro unit, add a drop-in for Restart and LimitNOFILE, and rotate redis.log so High-Speed SSD is not the log sink. Enable the service on a Netbay Ubuntu VPS and test a kill -9 plus systemd restart — netbayhosts.in.