Version: Redis 4.0-rc3 / Platform: Linux Ubuntu

In redis.conf you add in the line:

rename-command KEYS 21591e49a59cfd7c

Then in redis-cli issue the command 21591e49a59cfd7c * the result is

(error) ERR unknown command '*'

[... hundreds of lines ...]

(error) ERR unknown command '*'
(error) ERR unknown command '*'
(error) ERR unknown command '*'
(error) ERR unknown command '*'
(1.12s)

However, if, in redis.conf you put in the line:

rename-command KEYS r21591e49a59cfd7c (note the 'r' at the start of the second argument, the only difference)

Restart redis and issue the command r21591e49a59cfd7c * in redis-cli it works as expected:

(empty list or set)

Comment From: itamarhaber

Verified, and there are actually two issues here:

  1. Redis allows renaming to anything, whereas the cli treats a number in the first (0) position in the argv array as the repeat modifier. That means that if you rename a command to a number, you won't be able to run it via redis-cli.

  2. Some hash functions yieldings begin with digits, and these may be used to generate "random" command names that you would use as renaming target (perhaps to increase security). Assuming that the above is an example of that, it makes sense IMO to fix the cli's behavior so it will support digit-prefixed commands (arguably, modules may also introduce commands beginning with names beginning with digits, although that may not necessarily be best practice).

There are at least two ways I can think of to fix this, and would appreciate @antirez's guidance to on hax0ring around line 1337:

  1. Use something with errno checking
  2. Scan argv[0] for isalpha && || isdigit

Comment From: stockholmux

The other aspect that troubles me about this is that it produced 1.2 seconds worth of (error) ERR unknown command '*' which makes me think it's coming from redis-server not redis-cli. I may be out of my depth here, but it makes me nervous that any error would be returned after spinning the server for so long (theoretical DOS attack in trigger an error over and over).

Comment From: itamarhaber

Worry not - definitely just the cli. What happened here was that 21591e49a59cfd7c got parsed as the number 21591 silently ignoring the suffix, and then the cli sent that number of times the command '*' (to which the server politely declined as an error).

Comment From: stockholmux

@itamarhaber Makes perfect sense. Thanks for the clarification.

Comment From: madolson

Status: This is a straight forward bug to fix and not require a lot of effort. Itamar outlined two solutions which I think would both work just fine. Seems like we just need someone to go fix it.

Comment From: dipAch

Is this still an open bug? It seems to be working as expected from redis-cli against commit-id -> c3f9e017

Comment From: oranagra

i can confirm this indeed works in unstable (tested both the interactive and and argv input modes of redis-cli). i suppose someone fixed it accidentally.

Comment From: SkyperTHC

I stumbled across this issue and my problem was similar: Huge traffic between redis-client and redis-server (1,000 times higher than the web traffic).

The problem was that redis-cli issues a COMMAND DOCS for every new connection. The client pulls all commands from the redis-server (and the list is huge).

I disabled this in the redis.conf with:

rename-command COMMAND ""

Comment From: oranagra

@SkyperTHC AFAIK redis-cli will only issue COMMAND in an interactive session, do you mean you had some script that used redis-cli in a loop or many of them in parallel, and that caused something to explode? which version did you use?

Comment From: SkyperTHC

@SkyperTHC AFAIK redis-cli will only issue COMMAND in an interactive session, do you mean you had some script that used redis-cli in a loop or many of them in parallel, and that caused something to explode?

which version did you use?

Had a script that called redis-cli --raw every 10 seconds. Version: the latest from docker hub (official).

Comment From: oranagra

@SkyperTHC i've just tested both redis 6.0 and 7.0. when redis-cli is executed in the non-interactive mode, it doesn't issue the COMMAND command on startup. i've verified that with INFO commandstats. please check closely, and verify which version of redis-cli are you using.

Comment From: SkyperTHC

Please explain when you say 'non-interactive' mode. I'm running redis-cli without TTY attached (e.g. non-interactive, attached to a pipe (not TTY)).

that's how to reproduce it:

docker run --name foobar redis

nsenter -t $(pidof redis-server)  -n tcpdump -n -i lo

echo PING | docker exec -i foobar redis-cli --raw

Observer tcpdump output where COMMAND DOCS is issued:

09:49:55.344291 IP 127.0.0.1.47178 > 127.0.0.1.6379: Flags [P.], seq 1:28, ack 1, win 512, options [nop,nop,TS val 949621369 ecr 949621366], length 27: RESP "COMMAND" "DOCS"

... followed by megabytes of output...

Comment From: oranagra

ohh now i see. non-interactive mode is when redis-cli takes the commands to execute from the command line arguments.

$ src/redis-cli ping
PONG

interactive mode is when it takes it from the user input in the console:

$ src/redis-cli 
127.0.0.1:6379> ping
PONG
127.0.0.1:6379>

but since you're using |, you're hitting the the interactive mode path. i guess we should use isatty to check if we should call cliInitHelp wanna make a PR to fix that?

Comment From: SkyperTHC

done. https://github.com/redis/redis/pull/11850#issue-1601549377