redis-cli not working on linux

Question

I have installed redis onn linux. redis sever started correctly however when I try to start redis-cli I get this error

bash: redis-cli: command not found

file redis-cli output is

ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, BuildID[sha1]=0x5fe1c6d3da13df88f2ea826ac762f088c29b81d5, not stripped

Answer 1

This maybe happening because the executable isn't in path. In order to solve this, you can try copying redis-cli on the /usr/local/bin/ folder with this command:

sudo cp /src/redis-cli /usr/local/bin/

Answer 2

I don't know what's the reason but when I run the using this command

/usr/local/bin/redis-cli it works

but when I run redis-cli from the /usr/local/bin/ folder I get the error

bash: redis-cli: command not found

Looks like some path issue

Answer 3

If you built from source and you're in the default redis-stable directory that contains the source, you should be able to start the cli by running:

./src/redis-cli

Answer 4

It seems like redis-cli is present, reading your answer. Check this with which redis-cli.

I've installed redis on several linux machines, normally it goes very smooth. I guess you've run into a special case.

Here's my thoughts:

It might be a dynamic linking issue.

So check the headers with dump -H -X64 redis-cli. In the headers, you can see which shared objects it is trying to find. There might be a shared object from another package in the way, for example a 32-bit only one. Ugly, and wrong, but it happens.

Use the ldd runtime dependency checker to see what those headers actually result in on your system. Install it when not present. Then simply run ldd redis-cli.

Now you've figured out what's wrong, you can do several things.

1) Remove the conflicting package, if possible.

2) Use the LIBENV environment variable, to set the search path for shared objects, prior to starting the process

3) Use the -blibpath linker option at compile/link time to alter the header, giving it a different search path. The -bnolibpath could also help you.

4) Patch the header afterwards. There are tools for this. This is generally not the preferred way to go.

Hope this helps, TW

Edit:

Although make, make test, and make install were always fine, the server install script install_server.sh was always a bit buggy. This has just been fixed in 2.8.8. I recommend using the latest version.

Edit 2:

The OP's problem turned out to have nothing to do with dynamic linking, it was a simple PATH issue. I leave the answer as is, for historical purposes.