You spin up a fresh RHEL 8 or CentOS Stream node, install Cassandra 4, type cqlsh, and the thing just… crashes. No connection, no prompt — just a Python import error that makes it look like the entire installation is broken.
It’s not broken. Here’s exactly what’s happening and how to get your shell back.
Step 1 — Read the actual error
When you run cqlsh, you’ll see something like this:
[root@localhost conf]# cqlsh
Traceback (most recent call last):
File "/usr/bin/cqlsh.py", line 159, in <module>
from cqlshlib import cql3handling, cqlhandling, pylexotron...
ImportError: No module named cqlshlib
The phrase “No module named cqlshlib” sounds like a missing dependency, but that’s a red herring. The real culprit is one line above it — cqlsh.py couldn’t even start properly because it was invoked with the wrong Python binary (or none at all).
Why this is misleading
When Python can’t initialize correctly, the import system breaks entirely — so you get a module error even though cqlshlib is sitting right there on disk.
Step 2 — Confirm python doesn’t exist
Try calling Python directly and you’ll see the real problem immediately:
[root@localhost conf]# python /usr/bin/cqlsh.py
-bash: python: command not found
There it is. RHEL 8 and newer CentOS versions deliberately removed the unversioned python command. The reasoning was practical — for years, scripts assumed python meant Python 2, and that assumption caused endless breakage as the ecosystem moved to Python 3. Red Hat’s solution was to just not ship an unversioned binary and force everything to be explicit.
Cassandra 4’s cqlsh launcher script was written before this change became standard practice, so it still calls the bare python command at the top of the file.
Step 3 — Verify you actually have Python 3
Before doing anything, confirm that Python 3 is installed and which version you’re working with:
[root@localhost conf]# python3 --version
Python 3.6.8
Good. Python 3 is there — it’s just not aliased to the name cqlsh expects. Now let’s fix it.
Step 4 — Pick your fix
There are two ways to handle this, depending on how permanent you want the solution to be.
Option A
Call cqlsh.py with python3 directly
[root@localhost conf]# python3 /usr/bin/cqlsh.py
Connected to Test Cluster at 127.0.0.1:9042
[cqlsh 6.0.0 | Cassandra 4.0.5 | CQL spec 3.4.5 | Native protocol v5]
Use HELP for help.
cqlsh> _
Option B
Create a symlink so python points to python3
This makes cqlsh work as you’d normally expect, without any extra typing.
[root@localhost conf]# ln -s /usr/bin/python3 /usr/local/bin/python
[root@localhost conf]# which python
/usr/local/bin/python
[root@localhost conf]# cqlsh
Connected to Test Cluster at 127.0.0.1:9042
cqlsh> _
Using /usr/local/bin/ instead of /usr/bin/ keeps your system Python packages clean and won’t interfere with RPM-managed files.