Hi there, I didn’t find anybody having this issue, so let’s see if somebody can help me.
I’ve been working with InfluxDB v2 for some time, and I wanted to try InfluxDB v3.
In order to try it in a clean environment. I created a VM, Ubuntu 24.04.2, 50Gb, typical configuration I do to try this kind of stuff.
Problem:
The script fails during the download phase with curl error code (23), indicating a write error. This happens for both the main tarball and the SHA256 checksum file.
Error Output:
Downloading InfluxDB 3 Core to /home/jam/.influxdb
mkdir -p '/home/jam/.influxdb'
curl -sSL 'https://dl.influxdata.com/influxdb/releases/influxdb3-core-3.0.3_linux_amd64.tar.gz' -o '/home/jam/.influxdb/influxdb3-core.tar.gz'
curl: (23) client returned ERROR on write of 8192 bytes
Verifying '/home/jam/.influxdb/influxdb3-core.tar.gz'
curl -sSL 'https://dl.influxdata.com/influxdb/releases/influxdb3-core-3.0.3_linux_amd64.tar.gz.sha256' -o '/home/jam/.influxdb/influxdb3-core.tar.gz.sha256'
curl: (23) client returned ERROR on write of 106 bytes
cut: /home/jam/.influxdb/influxdb3-core.tar.gz.sha256: No such file or directory
Could not find properly formatted SHA256 in '/home/jam/.influxdb/influxdb3-core.tar.gz.sha256'. Aborting.
Troubleshooting Steps Taken:
Confirmed sufficient disk space.
The mkdir -p ‘/home/jam/.influxdb’ command within the script (and when run manually as user jam) succeeds without issues. My user jam owns /home/jam and its subdirectories.
Manually executing the curl command to download the tarball directly to /home/jam/.influxdb/ (as user jam) also fails with the same curl: (23) client returned ERROR on write… error:
Contrasting Success:
Interestingly, I was able to successfully install InfluxDB v3 using the exact same script and process within WSL (Windows Subsystem for Linux) on the same host machine without any errors. This suggests the issue is specific to my Ubuntu 24.04 VM environment.
In this case, I see influxdb3 running in port 8181, but the terminal doesn’t find the command “influxdb3”.
Question:
Does anyone have insights into what might be causing curl to fail with a write error (23) specifically within this Ubuntu 24.04 VM environment, even when mkdir to the same target path works and general permissions/disk space seem fine? Could it be related to a specific curl version, a VM configuration peculiarity, or something else I might be overlooking?
And, in the WSL case, if somebody encountered the same “influxdb command not found” and knows how to solve it, that would be great.
Hello @JAM_90
Welcome! Thanks for your question.
Hmmm the script should work on Ubuntu and similar Linux distributions, and that the process you followed is correct
Can you verify installation with: influxdb3 --version.
Let me ask around. Thanks!
Hey @JAM_90 - can you try to get a more verbose curl error output using the -v or -vv flags when invoking curl? That may help provide some additional info about why that is failing.
Following up on my previous installation issues, I’ve made some progress and encountered a new, specific problem.
Summary of Attempts with InfluxDB v3.1.0:
I attempted to install the latest InfluxDB v3.1.0 (downloaded via the official script: curl -O https://www.influxdata.com/d/install_influxdb3.sh && sh install_influxdb3.sh) on both my Ubuntu 24.04 VM and WSL, just as @hiltontj suggested.
1. WSL (Windows Subsystem for Linux - Ubuntu 24.04):
Installation: The script completed successfully.
Server Process (influxd3): Running and listening on port 8181.
Client CLI (influxdb3 --version):
Initially, this command failed with “command not found.”
Fix: I found that the export PATH="$PATH:/home/jam/.influxdb/" line added by the script to my .bashrc was appended to the previous line without a newline.
After manually correcting the .bashrc (adding a newline before the export statement) and sourcing it (source ~/.bashrc), the command now works:
WSL environment seems to be working correctly now.
2. Ubuntu 24.04 VM (Fresh Install, 50GB Disk):
Installation: The script also completed successfully (the previous curl: (23) write error seems resolved with v3.1.0 or was an intermittent issue).
Server Process (influxd3): Running and listening on port 8181.
Client CLI (influxdb3 --version):
The .bashrc file was formatted correctly by the script this time (the export PATH line was on a new line).
However, when I try to run influxdb3 --version (or any influxdb3 command), I get the following error:
$ influxdb3 --version
influxdb3: error while loading shared libraries: libpython3.13.so.1.0: cannot open shared object file: No such file or directory
My Ubuntu 24.04 VM has Python 3.12 installed by default (python3 --version outputs Python 3.12.x).
Has anyone else encountered this libpython3.13.so.1.0 dependency issue with the influxdb3 CLI (v3.1.0) on a standard Ubuntu 24.04 (or similar Linux distribution that ships with Python 3.12 or older)? It’s strange because I don’t find that problem on the WSL, and both of them have Ubuntu 24.04, and I followed the same process for both.
@JAM_90 - the python VM that influxdb3 runs expects python version 3.13. Upgrading the python version on your Ubuntu VM may solve the issue, but isn’t necessarily the best idea as doing so may cause other problems.
We have a document that discusses several details about how the processing engine is built.
If you are still not able to get things to work after reviewing those links, let us know, and we can open an issue to troubleshoot and figure out a clear solution.
Thanks for the reply. I couldn’t find any info related in the given link. I’ve re-attempted the installation on my Ubuntu 24.04 VM, ensuring everything is fresh, but I’m still encountering the same error with the influxdb3 CLI (v3.1.0):
influxdb3: error while loading shared libraries: libpython3.13.so.1.0: cannot open shared object file: No such file or directory
Could this specific influxdb3 CLI version (3.1.0 from the official script) be compiled in a way that it indeed requires Python 3.13, even for standard Linux distributions like Ubuntu 24.04? It’s really strange as I didn’t have that error in WSL (Ubuntu 24.04.2)
