We have a redis database running on our server, but for some reason, I cannot see any keys in our database. I'm just wondering if redis stores an activity log, where I can trace if and when the keys were deleted?
I have the usual log file for redis, at /var/log/redis.log but that doesn't have the information I am looking for.
I think there is no straight forward way to log everything but here is a hack.
$ redis-cli monitor >> ~/my_redis_commands.log 2>&1
Here >> tells OS that the output stream has been changed from monitor to a file and 2>&1 tells to redirect STDERR to STDOUT.
n>&m Merge output from stream n with stream m.
Note that file descriptor 0 is normally standard input (STDIN), 1 is standard output (STDOUT), and 2 is standard error output (STDERR).
Go and see the content of file in some SSH session for debugging.
$ tail -f ~/my_redis_commands.log
or you can use grep to find "DEL" instead. You can see the list of commands supported by Redis and try grep queries like SET, GET, etc.
$ grep '"DEL"' ~/my_redis_commands.log
Cons of this idea are:
You need to run a separate process to do this
It's memory and CPU consuming
single MONITOR client can reduce the throughput by more than 50%. Running more MONITOR clients will reduce throughput even more.
For security concerns, certain special administration commands like CONFIG are not logged into the MONITOR output
See this for more info https://redis.io/commands/monitor
The INFO command can be used to glean some forensic info when used with the all or cmdstats switch - you'll be able to see counts of all commands including offensive ones.
Keep in mind that this could be the result of an unauthorized intrusion and that your server may have been compromised.
Related
As I use Redis to start up with a bunch of other processes via Foreman, I find its output on startup quite verbose.
Redis writes more than twice the number of lines to stdout than any other process in my Procfile, mainly because of the ASCII art that gets printed to the log.
Is there a (startup) option to keep the log more concise, for example by turning off the output of the logo?
TLDR: If you have redis version 4.0 or higher you can do redis-server | cat to trick it into thinking it's not running in a tty.
Original answer:
I've had a quick check in the config docs and you shouldn't be seeing this. Can you maybe check your config file and see if you've set always-show-logo to yes?
The comment that accompanies it is as follows:
# By default Redis shows an ASCII art logo only when started to log to the
# standard output and if the standard output is a TTY. Basically this means
# that normally a logo is displayed only in interactive sessions.
#
# However it is possible to force the pre-4.0 behavior and always show a
# ASCII art logo in startup logs by setting the following option to yes.
I guess if you're on a version < 4.0 then that might explain what you're seeing.
Here is the issue/fix from 2014 https://github.com/antirez/redis/issues/1935
Currently I am having an issue with trying to run a process/script in the background[The master starts it on the minion]
The script is something like this:
#!/bin/bash
nohup ping 8.8.8.8 >/dev/null&
And I call it from the master with:
Process-Name:
service.running:
- name: Script-Name
- enable: True
For some reason it gets stuck on the master,I've read a little bit on this issue[it has happenned before apparently] and tried their solutions on it but apparently nothing involving the service state seems to work.
Is there anyway to work around this?
In short, you should configure your script as system daemon first (SysV init.d script, or systemd unit, or ... depends on OS).
Details
The service.running function requires properly configured system service ~ daemon.
For example, on RHEL-based Linux, if you don't see your script name in the output of one of these commands, you should configure it as proper service first (which is a separate topic):
# systemd
systemctl list-units | grep your_service_name
# SysV init.d
chkconfig --list | grep your_service_name
And because you want to start it in background, cmd.run function is not the right tool either:
It will only report successful start of the script without waiting for its completion results.
It will also start new instance of your script every time.
However, if all you simply want is to "fire and forget", use cmd.run.
I prepared a file according to redis' mass insertion protocol, and everything is working fine. Up to a point...
If the file contains up to 775 commands, all is good:
% redis-cli --pipe < in.redis
All data transferred. Waiting for the last reply...
Last reply received from server.
errors: 0, replies: 775
But starting at 776 commands, this is what I get:
% redis-cli --pipe < in.redis
Error writing to the server: No error
It seems unreasonable that there is such a tiny limit.
Plus, as you can see, the error message is fishy.
Anyone seen such a behavior? Any help would be appreciated.
I'm running the win64 version of redis (version 2.8.9)
In certain shells, there seems to be potential for interpreter errors to the \r and \n bytes that are needed for the Redis protocol. The error message you reported doesn't match exactly, but the behavior sounds somewhat similar to what is being described in this SO question:
Redis multi insert issue
Long shot, but you might try this:
echo "$(cat in.redis)" | redis-cli --pipe
I just encountered and circumvented a problem in Matlab, but I'm still wondering why this happens, and I also want to leave the information here for future reference.
In Matlab's Parallel Computing Toolbox, the command matlabpool local starts a local pool of Matlab workers which are then used transparently to speed up commands like parfor by distributing processing onto the different CPU cores. I tried to do so on a Linux machine which I connected to through ssh from my home Linux computer. I used ssh without X forwarding because the script I wanted to run only computes and saves the result, but does not produce graphical output.
The problem: matlabpool hung forever, without any indication of the cause. I restarted the remote machine, restarted Matlab, checked for license problems, without result.
The problem was resolved however when I closed ssh and logged back in, this time including the -X option for X11 forwarding – even though then I started Matlab with the -nodesktop option.
Does anyone have an idea why matlabpool on Linux appears to depend on access to X11?
Even though matlabpool starts and communicates with background headless workers, you can still create figures and plots and print/export them as images inside the parfor parallel loop. The following is a valid use case:
matlabpool(..)
parfor i=1:4
plot(..)
print(...)
close(..)
end
To me this suggests that background workers will still depend on graphics capabilities to generate the invisible plots in memory (maybe it's using virtual framebuffers and such). Of course this is just speculation on my part :)
EDIT:
Just to be sure here, can you try the following sequence of commands:
[client]$ ssh -v -x user#server # X11 forwarding disabled
[server]$ unset DISPLAY # clear $DISPLAY variable
[server]$ nohup matlab -nodesktop -nodisplay -noFigureWindows -nosplash \
-r "myscript; quit;" 2>&1 < /dev/null &
Where the script contains a simple parallel test like:
myscript.m
parpool('local',2)
smpd
fprintf('hello from lab#%d', labindex);
end
delete(gcp('nocreate'))
If MATLAB still hangs, try adding the -debug start option:
matlab -debug starts MATLAB and displays debugging information that can be useful, especially for X based problems.
I am using Spring Jedis Client to use Redis in my application. I want to rename the commands so that no one else can fire the same just in case they are able to connect to my server.
Can anyone give an example of how to use rename command from Jedis and then how to fire subsequent commands using the the modified one ?
You can't rename a Redis command yet w/o changing the config file issue #640.
Even if you add the rename-command config file directive and restart your Redis, Jedis doesn't seem to allow sending arbitrary commands easily or to provide a trivial (i.e. no code changes) way to rename them.
What you could do, however, if you're really insistent on renaming a command and then calling it from Jedis is EVAL it. This will probably go in my pantheon of ugly hacks (:)) but after adding rename-command get foo to my /etc/redis/redis.conf and doing service redis-server restart look what I can do:
$ redis-cli
redis 127.0.0.1:6379> set bar baz
OK
redis 127.0.0.1:6379> get bar
(error) ERR unknown command 'get'
redis 127.0.0.1:6379> foo bar
"baz"
redis 127.0.0.1:6379> eval "return(redis.call('get', KEYS[1]))" 1 bar
(error) ERR Error running script (call to f_db0e060e4f58231d51f21685b20ff847de8ab9e1): Unknown Redis command called from Lua script
redis 127.0.0.1:6379> eval "return(redis.call('foo', KEYS[1]))" 1 bar
"baz"
redis 127.0.0.1:6379>
Of course, if you take this route your code can get pretty messy in no time at all so be careful where you tread... Good luck!
If a malicious user connects directly to Redis, then one can access all opcodes.
There is no feature in the Redis library to rename commands. Even if you expose access to a custom API that renames commands, you cannot change the inner opcodes of Redis itself.
Edit:
You're right, it is possible to rename commands by changing the config file indeed!
After you set the new command names, you have to recompile Jedis.
First rename the enum on src/main/java/redis/clients/jedis/Protocol.java, line 203.
Now find the corresponding enum usage on src/main/java/redis/clients/jedis/BinaryClient.java and change it also.
It may be sufficient: everywhere you still keep the old command java interfaces (e.g. zadd etc.), and inside Jedis it will talk to Redis calling the renamed command.
Is that your intention ?