If it has not yet been discussed already, according to the default config file, /var/run/redis.pid is used as default PID file location while /tmp/redis.sock is shown as example UNIX socket file location.
While most distributions used /var/run in the past for these runtime files, nowadays most used /run and allow using /var/run only for backwards compatibility via symlink.
How Debian handles it: - https://wiki.debian.org/ReleaseGoals/RunDirectory#Packages_using_.2Fvar.2Frun_and_.2Fvar.2Flock - https://wiki.debian.org/ReleaseGoals/RunDirectory#How_to_transition_from_.2Fvar.2Frun_to_.2Frun_and_.2Fvar.2Flock_to_.2Frun.2Flock.3F
Discussion around that topic on Fedora: - https://lists.fedoraproject.org/pipermail/devel/2011-March/150031.html
systemd prints a warning when /var/run is found in a systemd unit and overrides it with /run automatically. Dealing with this lead to some inconsistent systemd unit/config in Redis server packages, e.g. this example from Debian and Ubuntu:
redis.conf
# unixsocket /var/run/redis/redis-server.sock
pidfile /var/run/redis/redis-server.pid
redis-server.service
PIDFile=/run/redis/redis-server.pid
ReadWritePaths=-/var/run/redis
I know using --supervised systemd --daemonize no + Type=notify makes anyway more sense here 😉
Due to the symlink of course all of this works, however it might break in the future and at best is a bid confusing and inconsistent when the process creates a PID file at one location but the systemd unit expects it at a different one that even does not match the allowed ReadWritePaths in the same file 😄.
This is of course to be addressed to the Debian package maintainer but other cases show that downstream packages in general provide better consistency if upstream code gives a consistent example. Hence I suggest to:
- Use /run/redis/redis.pid as default PID file location.
- Use /run/redis/redis.sock as example UNIX socket location.
Comment From: yossigo
@MichaIng thanks for reaching out! You raise a valid point of course. I'm quite hesitant to change the default as we need to consider the bigger picture that involves also non-Linux or less commonly used Linux distros. I believe that due to backwards compatibility efforts, /var/run is still a safer bet than /run.
Updating redis.conf makes a lot of sense (and in particular, using /tmp is never a good idea anyway).
Comment From: MichaIng
While there are probably environments which still use /var/run (I remember https://github.com/just-containers/s6-overlay), /run at least exists so can always be used, doesn't it? Since everyone with an existing instance will hopefully not override its config file with the new default on every update, without at least reviewing/comparing it, it hence should be even safe to change the default pidfile path in config file?
However, for the default location when daemonizing when the pidfile is not actively set in the config file, I totally agree to not change that outside of probably a major version update that includes other breaking changes.
Comment From: yossigo
@MichaIng Does /run exist on all platforms Redis supports, including macOS, *BSD, etc? I'm not sure, but I am pretty confident /var/run will not pose a problem in the foreseeable future.
Comment From: MichaIng
That is actually an interesting question, did not think about /var/run not only being used for backwards-compatibility but for cross-compatibility as well. Just searched a bid:
- GhostBSD explicitly states that /var/run is deprecated: https://wiki.ghostbsd.org/index.php//var/
- FreeBSD docs don't mention any of both: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/dirstructure.html
- OpenBSD sources at least contain daemons that use /var/run for PID and socket files while I couldn't find one that uses /run on a short sight.
- In case of macOS 10.15 indeed /run does not exist while /var/run does.
Okay so your point is pretty valid and I guess as long as not all larger UNIX-like operating systems adopt the change, also /var/run will most likely stay on those that did. It's then up to the distribution maintainers to set the Redis config according to their particular standards.
Comment From: stokito
I checked the FreeBSD 14 and the /run doesn't exists