TaskingAI fails to start with ConnectionRefusedError on port 8002

Not specified by the original author.

TL;DR

If youre running from code instead of the full Docker setup, that service isnt up and you get the connection refused error. The fix: docker pull taskingai/taskingai-inference:latest and run it alongside the backend.

Steps

1. Port 8002 is the taskingai-inference service, which is separate from the main app. If youre running from code instead of the full Docker setup, that service isnt up and you get the connection refused error. The fix: docker pull taskingai/taskingai-inference:latest and run it alongside the backend. The maintainer gave this answer and the reporter confirmed it. (The inference service was open-sourced later, but the missing-service cause is the same.)

When to use

You are seeing this: When I started the TaskingAI app, I got a ConnectionRefusedError with Errno 10061 Connect call failed (the loopback address, 8002). Use this skill when you run into "TaskingAI fails to start with ConnectionRefusedError on port 8002".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Asked in the thread (https://vectle.com/threads/thrmzSXDk9RXkjjzk5gB96MOw): When I started the TaskingAI app, I got a ConnectionRefusedError with Errno 10061 Connect call failed (the loopback address, 8002). I was running the code directly, not via Docker. The maintainer asked for a docker ps screenshot and then gave the answer on the thread in January 2024. The verified answer: Port 8002 is the taskingai-inference service, which is separate from the main app. If youre running from code instead of the full Docker setup, that service isnt up and you get the connection refused error. The fix: docker pull taskingai/taskingai-inference:latest and run it alongside the backend. The maintainer gave this answer and the reporter confirmed it. (The inference service was open-sourced later, but the missing-service cause is the same.) Source: https://github.com/TaskingAI/TaskingAI/issues/19 Thread: https://vectle.com/threads/thrmzSXDk9RXkjjzk5gB96MOw

Not specified by the original author.

Short answer: start the server. Run ollama serve in a second terminal window and leave it open, then retry your command in the first one. `` Error: could not connect to ollama server, run 'ollama serve' to start it 1. Run ollama serve in its own terminal and leave it running. Expected: startup log lines, no error. 2. In another terminal run ollama list. Expected: your downloaded models, not the connect error. 3. Make it permanent so reboots stop breaking it. Linux: sudo systemctl enable --now ollama. macOS with Homebrew: brew services start ollama. Windows or macOS installer: launch the Ollama app, the tray or menu-bar icon means the server is up. 4. If the server is up but clients still fail, check the OLLAMA_HOST variable is identical on both sides, and remember the default binds the loopback interface only, so remote machines cannot reach it without rebinding. 5. If you see address already in use on port 11434 instead, Ollama is already running. Use it, do not start a second server. Root cause: the CLI is stateless. It needs the server process listening before any command (run, ps, pull, API calls) can work, and nothing starts that server automatically on most installs. When to use: this exact message from the CLI or from API clients. When NOT to use: connection refused from inside a Docker container pointing at the loopback interface is a different problem, the client needs the host's address or the Ollama service name, not the loopback address. Variant phrasings: "could not connect to ollama", "ollama server not running", "ollama connection refused 11434". Edge cases: on macOS and Windows ollama ps` tries to launch the app for you. If the error persists there, the app itself is failing to start, check its logs rather than retrying the command.

Context: Ollama is two processes: a background server and the CLI client you type into. Every CLI command dials the server on port 11434, and this error means nothing is listening there. Ollama is installed, but the server part is not running. This is the normal state after a reboot or a fresh Homebrew install, which does not auto-start the service.

Source: Ollama is two processes: a background server and the CLI client you type into. Every CLI command dials the server on port 11434, and this error means nothing is listening there. Ollama is installed, but the server part is not running. This is the normal state after a reboot or a fresh Homebrew install, which does not auto-start the service.

Verified resolution: Short answer: start the server. Run ollama serve in a second terminal window and leave it open, then retry your command in the first one. `` Error: could not connect to ollama server, run 'ollama serve' to start it 1. Run ollama serve in its own terminal and leave it running. Expected: startup log lines, no error. 2. In another terminal run ollama list. Expected: your downloaded models, not the connect error. 3. Make it permanent so reboots stop breaking it. Linux: sudo systemctl enable --now ollama. macOS with Homebrew: brew services start ollama. Windows or macOS installer: launch the Ollama app, the tray or menu-bar icon means the server is up. 4. If the server is up but clients still fail, check the OLLAMA_HOST variable is identical on both sides, and remember the default binds the loopback interface only, so remote machines cannot reach it without rebinding. 5. If you see address already in use on port 11434 instead, Ollama is already running. Use it, do not start a second server. Root cause: the CLI is stateless. It needs the server process listening before any command (run, ps, pull, API calls) can work, and nothing starts that server automatically on most installs. When to use: this exact message from the CLI or from API clients. When NOT to use: connection refused from inside a Docker container pointing at the loopback interface is a different problem, the client needs the host's address or the Ollama service name, not the loopback address. Variant phrasings: "could not connect to ollama", "ollama server not running", "ollama connection refused 11434". Edge cases: on macOS and Windows ollama ps` tries to launch the app for you. If the error persists there, the app itself is failing to start, check its logs rather than retrying the command.

Source URL: https://github.com/ollama/ollama/blob/main/README.md

Not specified by the original author.

Short answer: Docker Desktop is not running (or not finished starting) on your Windows machine. Start it, wait for the engine to report running, then retry your command. `` failed to connect to the docker api at npipe:////./pipe/dockerdesktoplinuxengine; check if the path is correct and if the daemon is running: open //./pipe/dockerdesktoplinuxengine: the system cannot find the file specified. 1. Open Docker Desktop from the Start menu. Wait until the whale icon in the system tray is steady and the dashboard shows the engine as running. Then run docker info. Expected: server details print with no API error. 2. If Desktop is open but the pipe is still missing, check the WSL2 backend: run wsl -l -v in PowerShell. docker-desktop and docker-desktop-data should show Running. If not, run wsl --start docker-desktop, then restart Docker Desktop. 3. If Desktop and WSL are both fine, your Windows user may not be in the local docker-users group, which the pipe requires. From an admin PowerShell add yourself to that group, restart Docker Desktop, and retry. 4. Still failing: in Docker Desktop go to Settings, Troubleshoot, and Reset to factory defaults. This recreates the pipe. Root cause: on Windows the client reaches the daemon through a named pipe created at Desktop startup. No running Desktop means no pipe, so the client reports it cannot connect. When to use: this exact error on Windows with Docker Desktop. When NOT to use: on Linux or macOS (the daemon listens on a unix socket there, not a named pipe), or when docker context ls shows you are pointed at a stale remote context. Variant phrasings: "docker desktop npipe error", "open //./pipe/dockerdesktoplinuxengine the system cannot find the file specified", "docker daemon not running windows". Edge cases: CI runners often hit this because Desktop is still starting when the job runs. Poll docker info` in a wait loop before the first real command. Also confirm Desktop is in Linux containers mode if your images are Linux.

Context: The Docker CLI talks to the Docker daemon over a Windows named pipe that only exists while Docker Desktop is running. When Desktop is closed, still starting, or its WSL2 backend is down, the pipe is missing and every docker command fails with this connection error. It is not a problem with your images, compose file, or code.

Source: The Docker CLI talks to the Docker daemon over a Windows named pipe that only exists while Docker Desktop is running. When Desktop is closed, still starting, or its WSL2 backend is down, the pipe is missing and every docker command fails with this connection error. It is not a problem with your images, compose file, or code.

Verified resolution: Short answer: Docker Desktop is not running (or not finished starting) on your Windows machine. Start it, wait for the engine to report running, then retry your command. `` failed to connect to the docker api at npipe:////./pipe/dockerdesktoplinuxengine; check if the path is correct and if the daemon is running: open //./pipe/dockerdesktoplinuxengine: the system cannot find the file specified. 1. Open Docker Desktop from the Start menu. Wait until the whale icon in the system tray is steady and the dashboard shows the engine as running. Then run docker info. Expected: server details print with no API error. 2. If Desktop is open but the pipe is still missing, check the WSL2 backend: run wsl -l -v in PowerShell. docker-desktop and docker-desktop-data should show Running. If not, run wsl --start docker-desktop, then restart Docker Desktop. 3. If Desktop and WSL are both fine, your Windows user may not be in the local docker-users group, which the pipe requires. From an admin PowerShell add yourself to that group, restart Docker Desktop, and retry. 4. Still failing: in Docker Desktop go to Settings, Troubleshoot, and Reset to factory defaults. This recreates the pipe. Root cause: on Windows the client reaches the daemon through a named pipe created at Desktop startup. No running Desktop means no pipe, so the client reports it cannot connect. When to use: this exact error on Windows with Docker Desktop. When NOT to use: on Linux or macOS (the daemon listens on a unix socket there, not a named pipe), or when docker context ls shows you are pointed at a stale remote context. Variant phrasings: "docker desktop npipe error", "open //./pipe/dockerdesktoplinuxengine the system cannot find the file specified", "docker daemon not running windows". Edge cases: CI runners often hit this because Desktop is still starting when the job runs. Poll docker info` in a wait loop before the first real command. Also confirm Desktop is in Linux containers mode if your images are Linux.

Source URL: https://docs.docker.com/desktop/troubleshoot/