Ugoe Machine Ingestion Script — Part 1

This looks like the right ingestion script lineage, yes. It is a TokenSpace/Postgres ingestion script, not the Ollama server itself. It reads text files, chunks them, embeds them with a local SentenceTransformer model, and writes docs/chunks/embeddings into content.documents and content.chunks in Postgres. fileciteturn0file0L1-L16

What it is doing, in plain terms:

• Uses env vars for the database, source folder, embedding model, chunk sizes, batch size, and logging. Defaults are already baked in. fileciteturn0file0L17-L33
• Connects to Postgres at postgresql:///tokenspace?host=/var/run/postgresql&port=5433 unless you override DB_DSN. fileciteturn0file0L42-L49
• Scans ROOT_DIR for .txt, .md, .markdown, and .log files, then ingests them in natural numeric order. fileciteturn0file0L94-L107 fileciteturn0file0L170-L177
• Loads a local embedding model from /mnt/storage/models/nomic-embed-768 by default. fileciteturn0file0L42-L49 fileciteturn0file0L166-L169
• Upserts into content.documents, upserts chunk text/token counts into content.chunks, and optionally updates the embedding vector column. fileciteturn0file0L119-L154
• It is resumable: if chunks already exist for a document, it skips re-embedding unless FORCE_REEMBED=1. fileciteturn0file0L7-L10 fileciteturn0file0L201-L224

So my read is:

1. Yes, this is probably the ingestion file you were using.
2. Step one is not “turn on Ollama.” Step one is more likely:
   – activate the correct Python venv
   – make sure Postgres on port 5433 is running
   – make sure the embedding model path exists
   – run this script with the right ROOT_DIR

The biggest practical checkpoints are these:

• sentence_transformers must exist in that venv or it will immediately die. fileciteturn0file0L58-L63
• psycopg2 and numpy must also be installed. fileciteturn0file0L51-L56
• Your database must already have the content.documents and content.chunks tables, with embedding VECTOR(768). fileciteturn0file0L24-L31
• The script does not talk to Ollama at all. It uses SentenceTransformer(MODEL_DIR, trust_remote_code=True), so embeddings are local Hugging Face style model loading, not Ollama embeddings. fileciteturn0file0L166-L169

A clean way to re-enter this would be:

cd /path/to/where/this/script/is

source ~/ougway_env/venv/bin/activate
# or whatever your actual venv path was

export DB_DSN='postgresql:///tokenspace?host=/var/run/postgresql&port=5433'
export ROOT_DIR='/mnt/storage/pile_uncopyrighted'
export MODEL_DIR='/mnt/storage/models/nomic-embed-768'

python3 ingest_pile_v2.py

If you want to test without doing the whole pile again, point ROOT_DIR at a tiny folder first.

Also, one very important detail: this script only ingests text-like files. If your later plan was “incorporate the database into Ollama functionality,” that is a separate step from this script. This script populates the retrieval database. Then a second script or app would:

• take a user query
• embed the query
• search content.chunks by vector similarity
• pass the retrieved chunks into Ollama as context

That means what you’re probably missing is not just this ingest file, but also the query / retrieval bridge script.

Based on this file alone, I’d say you were in the database population phase, not yet the final Ollama integration phase. fileciteturn0file0L1-L10

Next best move is to locate:
– your venv path
– the script that queried Postgres/pgvector
– any shell script or notes that exported these env vars before running ingestion

Upload the retrieval script too, and I can reconnect the whole chain from ingestion to Ollama.

Good. That gives us the two key pieces.

Use this sequence from a terminal:

cd /home/darren/Documents/tokenspace
source /home/darren/Documents/ougway_venv/bin/activate
python --version

If that activates cleanly, check the script is there:

ls -l /home/darren/Documents/tokenspace/ingest_pile_v2.py

Then do a dry sanity check for the Python packages the script needs:

python -c "import psycopg2, numpy; print('base ok')"
python -c "from sentence_transformers import SentenceTransformer; print('st ok')"

If those pass, the next thing is to confirm your database and model path before you run ingestion:

echo $DB_DSN
echo $ROOT_DIR
echo $MODEL_DIR

If those are empty, set them explicitly for this session:

export DB_DSN='postgresql:///tokenspace?host=/var/run/postgresql&port=5433'
export ROOT_DIR='/path/to/the/text-files-you-were-ingesting'
export MODEL_DIR='/mnt/storage/models/nomic-embed-768'

Then launch the script:

python /home/darren/Documents/tokenspace/ingest_pile_v2.py

A few important notes from where you left off:

• This script is for ingestion into Postgres/pgvector, not Ollama itself.
• So if your thought was “turn Ollama back on,” that is a separate step.
• Right now the immediate goal is to get back into the venv, confirm dependencies, confirm DB/model paths, and rerun ingestion.

To help you re-orient fast, here’s the likely order of operations:

1. activate ougway_venv
2. verify Python packages
3. verify Postgres is running
4. verify model path exists
5. verify ROOT_DIR points to your corpus
6. run ingestion
7. later, reconnect the retrieval/query script to Ollama

Use these checks too:

ls /mnt/storage/models/nomic-embed-768
pg_isready -h /var/run/postgresql -p 5433

And if you want a quick one-shot startup block:

cd /home/darren/Documents/tokenspace
source /home/darren/Documents/ougway_venv/bin/activate
export DB_DSN='postgresql:///tokenspace?host=/var/run/postgresql&port=5433'
export ROOT_DIR='/path/to/the/text-files-you-were-ingesting'
export MODEL_DIR='/mnt/storage/models/nomic-embed-768'
python ingest_pile_v2.py

The one missing piece is your actual corpus path for ROOT_DIR. Once you tell me that, I can reconstruct the exact command you should run.

That failure is clean and useful.

Two things are wrong right now:

1. ROOT_DIR is still the placeholder path, not your real corpus path.
2. MODEL_DIR points to a model folder that does not exist on this machine.

The immediate blocker is the model path. The script died before it even got to ingestion.

Run these checks:

ls -ld /mnt/storage
ls -ld /mnt/storage/models
find /mnt -maxdepth 4 -type d | grep -i nomic
find /home/darren -maxdepth 5 -type d | grep -i nomic

That should tell us one of three things:

• the drive is not mounted
• the model folder is elsewhere
• the model was never copied onto this Ugoe machine

Also check whether the storage drive is mounted at all:

df -h
lsblk
mount | grep /mnt

If /mnt/storage is missing, then the path is failing because the drive is not mounted.

If you want the fastest recovery path, do this in order.

First, find the actual model location:

find /home/darren /mnt /opt -maxdepth 5 -type d 2>/dev/null | grep 'nomic-embed'

If that finds something like:

/home/darren/models/nomic-embed-768

then set:

export MODEL_DIR='/home/darren/models/nomic-embed-768'

If it finds nothing, then this machine does not have that embedding model yet.

Next, fix the corpus path. Right now you literally told it:

export ROOT_DIR='/path/to/the/text-files-you-were-ingesting'

That was just a placeholder. You need the real folder, for example something like:

export ROOT_DIR='/mnt/storage/pile_uncopyrighted'

or whatever folder actually contains the .txt files.

You can hunt for likely corpus folders with:

find /home/darren /mnt -maxdepth 4 -type d 2>/dev/null | grep -Ei 'pile|text|corpus|dataset|data'

Then once you have both real paths:

cd /home/darren/Documents/tokenspace
source /home/darren/Documents/ougway_venv/bin/activate
export DB_DSN='postgresql:///tokenspace?host=/var/run/postgresql&port=5433'
export ROOT_DIR='/REAL/PATH/TO/YOUR/TEXTS'
export MODEL_DIR='/REAL/PATH/TO/nomic-embed-768'
python ingest_pile_v2.py

Before running again, verify both:

ls -ld "$MODEL_DIR"
ls -ld "$ROOT_DIR"
find "$ROOT_DIR" -maxdepth 2 -type f | head

That way you do not waste another launch.

Most likely diagnosis: this box either does not have the model copied over yet, or the storage mount point differs from the old machine. The script itself looks fine; it is just being given paths that do not exist.

Paste me the output of these three commands and I can tell you exactly what to set next:

df -h
find /mnt /home/darren -maxdepth 5 -type d 2>/dev/null | grep -i 'nomic\|pile'
find /mnt /home/darren -maxdepth 3 -type d 2>/dev/null | sed -n '1,200p'

Good. Storage is mounted, so the issue is just the wrong model path, not a missing drive.

You do not have:

/mnt/storage/models/nomic-embed-768

But you do have Hugging Face cache copies of the Nomic model under:

/mnt/storage/hf-cache/hub/models--nomic-ai--nomic-embed-text-v1.5

The actual usable model directory is usually the snapshot folder inside that cache. Find it with:

find /mnt/storage/hf-cache/hub/models--nomic-ai--nomic-embed-text-v1.5/snapshots -maxdepth 1 -mindepth 1 -type d

That should return something like:

/mnt/storage/hf-cache/hub/models--nomic-ai--nomic-embed-text-v1.5/snapshots/xxxxxxxxxxxxxxxx

Use that full returned path as MODEL_DIR.

So the fix is:

export MODEL_DIR='/mnt/storage/hf-cache/hub/models--nomic-ai--nomic-embed-text-v1.5/snapshots/PUT_THE_HASH_HERE'

Then verify:

ls "$MODEL_DIR"

You should see model files like config/tokenizer/model files.

You also still need to fix ROOT_DIR, because right now it is still fake. Find likely corpus folders with:

find /mnt/storage /home/darren -maxdepth 4 -type d 2>/dev/null | grep -Ei 'pile|dataset|corpus|text|docs|chunks'

Then inspect the likely one:

find /that/path -maxdepth 2 -type f | head

You want a directory that actually contains .txt, .md, .log, or .markdown files.

So your next sequence should be:

cd /home/darren/Documents/tokenspace
source /home/darren/Documents/ougway_venv/bin/activate

export DB_DSN='postgresql:///tokenspace?host=/var/run/postgresql&port=5433'
export MODEL_DIR='/mnt/storage/hf-cache/hub/models--nomic-ai--nomic-embed-text-v1.5/snapshots/YOUR_HASH_HERE'
export ROOT_DIR='/REAL/CORPUS/PATH'

ls "$MODEL_DIR"
find "$ROOT_DIR" -maxdepth 2 -type f | head

python ingest_pile_v2.py

One more useful shortcut: if you want to avoid typing that giant snapshot path every time, make a symlink once:

mkdir -p /mnt/storage/models
ln -s /mnt/storage/hf-cache/hub/models--nomic-ai--nomic-embed-text-v1.5/snapshots/YOUR_HASH_HERE /mnt/storage/models/nomic-embed-768

Then you can go back to:

export MODEL_DIR='/mnt/storage/models/nomic-embed-768'

That is probably the cleanest fix.

Run these two commands next and paste the output:

find /mnt/storage/hf-cache/hub/models--nomic-ai--nomic-embed-text-v1.5/snapshots -maxdepth 1 -mindepth 1 -type d
find /mnt/storage /home/darren -maxdepth 4 -type d 2>/dev/null | grep -Ei 'pile|dataset|corpus|text|docs|chunks'

Then I can give you the exact export lines.

Perfect. Use this for the model path:

export MODEL_DIR='/mnt/storage/hf-cache/hub/models--nomic-ai--nomic-embed-text-v1.5/snapshots/e5cf08aadaa33385f5990def41f7a23405aec398'

Then verify it:

ls "$MODEL_DIR"

If that looks good, the only thing still missing is the real ROOT_DIR.

So the next block to run is:

cd /home/darren/Documents/tokenspace
source /home/darren/Documents/ougway_venv/bin/activate

export DB_DSN='postgresql:///tokenspace?host=/var/run/postgresql&port=5433'
export MODEL_DIR='/mnt/storage/hf-cache/hub/models--nomic-ai--nomic-embed-text-v1.5/snapshots/e5cf08aadaa33385f5990def41f7a23405aec398'

Now find the corpus folder:

find /mnt/storage /home/darren -maxdepth 4 -type d 2>/dev/null | grep -Ei 'pile|dataset|corpus|text|docs|chunks'

When you find the likely folder, test it:

find /that/folder -maxdepth 2 -type f | head

Once you confirm the folder with actual .txt or .md files, set:

export ROOT_DIR='/that/folder'

Then run:

python ingest_pile_v2.py

Optional cleanup so the old expected path works again:

mkdir -p /mnt/storage/models
ln -s /mnt/storage/hf-cache/hub/models--nomic-ai--nomic-embed-text-v1.5/snapshots/e5cf08aadaa33385f5990def41f7a23405aec398 /mnt/storage/models/nomic-embed-768

Then later you can use:

export MODEL_DIR='/mnt/storage/models/nomic-embed-768'

Paste the output of the corpus-folder search and I’ll point to the exact ROOT_DIR.

There it is.

Your likely corpus path is:

/mnt/storage/pile_uncopyrighted

So set:

export ROOT_DIR='/mnt/storage/pile_uncopyrighted'

Before running ingestion, do one quick sanity check:

find "$ROOT_DIR" -maxdepth 2 -type f | head
ls "$MODEL_DIR" | head
pg_isready -h /var/run/postgresql -p 5433

If those look good, run:

python ingest_pile_v2.py

So the full working block is now:

cd /home/darren/Documents/tokenspace
source /home/darren/Documents/ougway_venv/bin/activate

export DB_DSN='postgresql:///tokenspace?host=/var/run/postgresql&port=5433'
export MODEL_DIR='/mnt/storage/hf-cache/hub/models--nomic-ai--nomic-embed-text-v1.5/snapshots/e5cf08aadaa33385f5990def41f7a23405aec398'
export ROOT_DIR='/mnt/storage/pile_uncopyrighted'

find "$ROOT_DIR" -maxdepth 2 -type f | head
ls "$MODEL_DIR" | head
pg_isready -h /var/run/postgresql -p 5433

python ingest_pile_v2.py

If you want the old path convention back, make the symlink now:

mkdir -p /mnt/storage/models
ln -s /mnt/storage/hf-cache/hub/models--nomic-ai--nomic-embed-text-v1.5/snapshots/e5cf08aadaa33385f5990def41f7a23405aec398 /mnt/storage/models/nomic-embed-768

Then later you can shorten it to:

export MODEL_DIR='/mnt/storage/models/nomic-embed-768'

One caution: I also see old possible corpus locations like:

/mnt/storage/ougway_documents old/ougway_env/data/full_dataset

So if /mnt/storage/pile_uncopyrighted does not show the expected text files, that older full_dataset path may be the other candidate.

Run the sanity block and paste the output if anything barks.

You’re past the file-path mess. The script, model, and corpus are all good.

The only thing failing now is Postgres is not running on port 5433.

This line told us that before the script crashed:

/var/run/postgresql:5433 - no response

And then psycopg2 confirmed it.

So the next step is to find and start the PostgreSQL instance you were using.

Run these checks:

systemctl status postgresql --no-pager
pg_lsclusters
ps aux | grep postgres

Most likely outcomes:

Case 1: PostgreSQL is installed, but your cluster is down
You’ll probably see a cluster listed as down. Then start it with:

sudo pg_ctlcluster <version> main start

Example:

sudo pg_ctlcluster 16 main start

Then recheck:

pg_isready
pg_isready -h /var/run/postgresql
pg_isready -h /var/run/postgresql -p 5433

Case 2: PostgreSQL is running, but on the default port 5432
That is very likely. If so, either:
– change your DB_DSN to 5432, or
– reconfigure the cluster back to 5433

Fastest path is usually just use the live port.

If pg_lsclusters shows something like port 5432, then do:

export DB_DSN='postgresql:///tokenspace?host=/var/run/postgresql&port=5432'
python ingest_pile_v2.py

Case 3: PostgreSQL is not started at all
Then do:

sudo systemctl start postgresql

and check again:

pg_lsclusters
pg_isready

Also, confirm the database itself exists:

psql -h /var/run/postgresql -p 5432 -lqt

or if it really uses 5433:

psql -h /var/run/postgresql -p 5433 -lqt

You want to see tokenspace in the list.

So right now, the shortest likely recovery path is:

pg_lsclusters

If it shows 5432, then:

export DB_DSN='postgresql:///tokenspace?host=/var/run/postgresql&port=5432'
python ingest_pile_v2.py

If it shows down, start it first.

Paste the output of:

pg_lsclusters
systemctl status postgresql --no-pager

and I’ll tell you the exact next command.

Two separate issues are showing up there.

First, this:

source ~/Documents/ougway_venv/bin/activate

failed with:

source: command not found

because your text file almost certainly has a hidden BOM / junk character at the front. That weird invisible character before source turns it into a different command name. You can see it in your pasted line as the odd leading mark before source.

Second, this line:

python3 ~/Documents/tokenspace/ingest_pile.py

is pointing at the old filename, and that file is not there. The script you actually have is:

/home/darren/Documents/tokenspace/ingest_pile_v2.py

So the note is from an older state of the setup.

Use this cleaned version instead:

source ~/Documents/ougway_venv/bin/activate
export HF_HOME=/mnt/storage/hf-cache
export TRANSFORMERS_OFFLINE=1
export HF_HUB_OFFLINE=1
export HF_HUB_DISABLE_TELEMETRY=1
export DB_DSN='postgresql:///tokenspace?host=/var/run/postgresql&port=5433'
export MODEL_DIR='/mnt/storage/hf-cache/hub/models--nomic-ai--nomic-embed-text-v1.5/snapshots/e5cf08aadaa33385f5990def41f7a23405aec398'
export ROOT_DIR='/mnt/storage/pile_uncopyrighted'
CUDA_VISIBLE_DEVICES=0 python3 ~/Documents/tokenspace/ingest_pile_v2.py

But before you run that again, the real blocker is still Postgres. Your earlier run already proved that the model and corpus are fine, and then died here:

connection to server on socket "/var/run/postgresql/.s.PGSQL.5433" failed

So do this next:

pg_lsclusters
systemctl status postgresql --no-pager

If pg_lsclusters shows your cluster on 5432 instead of 5433, change this line:

export DB_DSN='postgresql:///tokenspace?host=/var/run/postgresql&port=5433'

to:

export DB_DSN='postgresql:///tokenspace?host=/var/run/postgresql&port=5432'

If it shows the cluster is down, start it with the version shown there, for example:

sudo pg_ctlcluster 16 main start

or just:

sudo systemctl start postgresql

Then test:

pg_isready
pg_isready -h /var/run/postgresql -p 5432
pg_isready -h /var/run/postgresql -p 5433

One more cleanup item: fix that startup note so it stops biting you later. The easiest way is to rewrite it from scratch:

cat > ~/Documents/uboi_startup_command.txt <<'EOF'
source ~/Documents/ougway_venv/bin/activate
export HF_HOME=/mnt/storage/hf-cache
export TRANSFORMERS_OFFLINE=1
export HF_HUB_OFFLINE=1
export HF_HUB_DISABLE_TELEMETRY=1
export DB_DSN='postgresql:///tokenspace?host=/var/run/postgresql&port=5433'
export MODEL_DIR='/mnt/storage/hf-cache/hub/models--nomic-ai--nomic-embed-text-v1.5/snapshots/e5cf08aadaa33385f5990def41f7a23405aec398'
export ROOT_DIR='/mnt/storage/pile_uncopyrighted'
CUDA_VISIBLE_DEVICES=0 python3 ~/Documents/tokenspace/ingest_pile_v2.py
EOF

Then run it safely with:

bash ~/Documents/uboi_startup_command.txt

Paste the output of pg_lsclusters and I’ll tell you whether to switch to 5432 or start the cluster.

You're actually seeing two different things there, Darren. Neither is serious.

1️⃣ Why source failed earlier

The earlier line that failed:

source ~/Documents/ougway_venv/bin/activate

contained a hidden Unicode BOM character at the beginning. It is invisible in many editors, but the shell reads it as part of the command name. So instead of running source, Bash tries to run something like:

<U+FEFF>source

which obviously does not exist, hence:

source: command not found

Your pasted text here does not show it anymore, because the BOM often disappears when copying between programs.

The easiest fix is simply rewrite the file cleanly, which removes the BOM.

---

2️⃣ The random UUID-looking number

This line:

158c3431-c479-41fc-8ba9-42b5d88e68ac

is almost certainly just garbage that got appended to the text file by whatever editor or clipboard operation was used earlier. It has no meaning for your system or script. It can be deleted.

---

3️⃣ The real issue still blocking ingestion

The ingestion failed earlier because PostgreSQL isn't running on port 5433:

connection to server on socket "/var/run/postgresql/.s.PGSQL.5433" failed

So before running the script again, run this:

pg_lsclusters

That command will show something like:

Ver Cluster Port Status Owner Data directory
16  main    5432 online postgres /var/lib/postgresql/16/main

Two possible cases:

If you see 5432

Change your DSN:

export DB_DSN='postgresql:///tokenspace?host=/var/run/postgresql&port=5432'

If you see down

Start it:

sudo pg_ctlcluster 16 main start

(or whatever version it shows)

---

4️⃣ Clean startup script (recommended)

Make a clean run script so you never have to remember this again:

nano ~/Documents/start_ougway_ingest.sh

Paste this:

#!/bin/bash

source ~/Documents/ougway_venv/bin/activate

export HF_HOME=/mnt/storage/hf-cache
export TRANSFORMERS_OFFLINE=1
export HF_HUB_OFFLINE=1
export HF_HUB_DISABLE_TELEMETRY=1

export DB_DSN='postgresql:///tokenspace?host=/var/run/postgresql&port=5432'
export MODEL_DIR='/mnt/storage/hf-cache/hub/models--nomic-ai--nomic-embed-text-v1.5/snapshots/e5cf08aadaa33385f5990def41f7a23405aec398'
export ROOT_DIR='/mnt/storage/pile_uncopyrighted'

CUDA_VISIBLE_DEVICES=0 python3 ~/Documents/tokenspace/ingest_pile_v2.py

Make it executable:

chmod +x ~/Documents/start_ougway_ingest.sh

Then you can start ingestion with one command:

~/Documents/start_ougway_ingest.sh

---

5️⃣ One thing I want to confirm before you run again

Run this and paste the output:

pg_lsclusters

That will tell me exactly what port your database is using, and then we can fire the ingestion back up properly.

You’re exactly right — the database simply isn’t running. The installation and cluster likely already exist; it just needs to be started.

The simplest method on Ubuntu is:

sudo systemctl start postgresql

Then confirm it came up:

pg_lsclusters

You should see something like:

Ver Cluster Port Status Owner    Data directory
16  main    5432 online postgres /var/lib/postgresql/16/main

The key word is online.

---

If it still shows down

Start the specific cluster directly:

sudo pg_ctlcluster 16 main start

(Replace 16 with whatever version pg_lsclusters shows.)

---

Quick health check

After starting it, run:

pg_isready

You should see:

/var/run/postgresql:5432 - accepting connections

---

One thing to adjust

Your script currently expects port 5433:

postgresql:///tokenspace?host=/var/run/postgresql&port=5433

But most Ubuntu installs run on 5432 unless you changed it earlier.

If pg_lsclusters shows 5432, change your env line to:

export DB_DSN='postgresql:///tokenspace?host=/var/run/postgresql&port=5432'

Then run your ingestion again.

---

Optional but recommended (so you never have to start it manually)

Enable PostgreSQL to start automatically at boot:

sudo systemctl enable postgresql

---

So your quick recovery sequence right now is:

sudo systemctl start postgresql
pg_lsclusters
pg_isready

Then rerun your ingest command.

---

If you want, I can also show you a one-line status check that verifies all 4 pieces of Ougway’s stack at once (GPU, model, DB, dataset) so you never have to hunt through this again.

Yep — this run shows the same thing, but with one extra clue:

You did not export DB_DSN in that launch, so the script fell back to its built-in default of 5433.

That means there are two steps:

1. Start PostgreSQL

Run:

sudo systemctl start postgresql

Then check what port it is actually using:

pg_lsclusters
pg_isready

Most likely, it will be 5432, not 5433.

---

2. Export the database DSN before launching ingestion

If pg_lsclusters shows port 5432, run:

export DB_DSN='postgresql:///tokenspace?host=/var/run/postgresql&port=5432'

Then launch again:

source ~/Documents/ougway_venv/bin/activate
export HF_HOME=/mnt/storage/hf-cache
export TRANSFORMERS_OFFLINE=1
export HF_HUB_OFFLINE=1
export HF_HUB_DISABLE_TELEMETRY=1
export DB_DSN='postgresql:///tokenspace?host=/var/run/postgresql&port=5432'
CUDA_VISIBLE_DEVICES=0 python3 ~/Documents/tokenspace/ingest_pile_v2.py

Why this happened

Your current launch command only set:

• HF_HOME
• offline Hugging Face flags
• CUDA_VISIBLE_DEVICES

It did not set DB_DSN, so the script used its internal default and tried /var/run/postgresql on port 5433.

Fastest path now

Run these exact commands:

sudo systemctl start postgresql
pg_lsclusters
pg_isready

If pg_lsclusters shows 5432, then immediately do:

export DB_DSN='postgresql:///tokenspace?host=/var/run/postgresql&port=5432'
CUDA_VISIBLE_DEVICES=0 python3 ~/Documents/tokenspace/ingest_pile_v2.py

Paste the output of pg_lsclusters if you want the exact final startup block.