You are not logged in.
Pages: 1
Hello,
redis' default config includes settings exclusively targeted towards logrotate:
It includes a redis.logrotate for managing logs
It explicitely defines a log file (/var/log/redis.log)
It daemonizes the server, making sure that nothing is outputted on stdout
While I have no grip with logrotate, this setting makes it incompatible with systemd's own logging, journalctl: no logs are registered by it. Plus, since it's impossible to specify a custom file as a log for a given unit, it is impossible to use journalctl with redis. Seeing as the trend goes towards using systemd more and more, I'd like to ask: is it really the best thing to have a unit's log outside systemd ?
Please note that I don't want to discuss the pluses/minuses of systemd, rather the default configuration one gets when installing redis that is inconsistent with the rest of the system.
Offline
Redis is written in ANSI C and works in most POSIX systems like Linux, *BSD, OS X without external dependencies.
Linux and OSX are the two operating systems where Redis is developed and more tested, and we recommend using Linux for deploying. Redis may work in Solaris-derived systems like SmartOS, but the support is best effort. There is no official support for Windows builds, but Microsoft develops and maintains a Win32-64 experimental version of Redis.
Is this a technical problem like Redis log doesn't hold correct info if journalctl is running ?
Or is redis loginfo accurate, but you feel those logs SHOULD be accessible through journalctl ?
Give your OP content , I'll assume it's the 2nd case.
I feel that logging mechanism is an upstream decision.
OS X and *BSD don't have systemd, and on linux there are still plenty of distros that don't use systemd (like the *buntus) .
For redis this would mean that supporting journalctl would force them to support 2 different logging systems instead of 1.
They will probably be reluctant to do that.
An alternative to Redis supporting journalctl would to be for journalctl to support Redis.
Maybe systemd journalctl could gain the option to accept a log file as input ?
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
> Give your OP content , I'll assume it's the 2nd case.
Correct, it's the second case: I'm asking why we specifically chose to change the way redis logs information.
> I feel that logging mechanism is an upstream decision.
Yes, and upstream decision is to not daemonize and use stdout for logging, which makes it a perfect fit for systemd, and it has been Arch's decision to do otherwise (log to a special file). I believe the change was made a while ago when systemd wasn't too big, and it hasn't changed since, even though systemd is now the default service manager in Arch. I was just thinking that it would be better if we changed the default config back to what it is upstream (at least regarding logging) and thus make it consistent with the rest of the system.
Offline
File a bug report.
Offline
rakoo,
i apologize for misinterpreting your post and wrongly assuming you wanted redis to make changes to work better with systemd.
I've looked at the changes in redis package, and it does seem that the decision to use a logfile / run redis daemonized was made a long time ago and has nothing to do with systemd.
redis was brought into community on may 8 of 2010, check https://projects.archlinux.org/svntogit … dd86f0dd12 .
That version already set redis to run daemonized and use a logfile.
I agree with jasonwryan you should file a bug report.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Pages: 1