Docker

Table of contents

1. Error response from daemon: driver failed programming external connectivity on endpoint mariadb_container (XXX): Error starting userland proxy: listen tcp4 0.0.0.0:3306: bind: address already in use
   1. Identify the process using port 3306
   2. Kill process
   3. Disable MariaDB
2. docker.errors.DockerException: Error while fetching server API version: (‘Connection aborted.’, FileNotFoundError(2, ‘No such file or directory’))
   1. How features are selected
   2. Solution 1: deploy with the webhook compose file
   3. Solution 2: drop the feature from your deployment

Error response from daemon: driver failed programming external connectivity on endpoint mariadb_container (XXX): Error starting userland proxy: listen tcp4 0.0.0.0:3306: bind: address already in use

This occurs because there is already a process on port 3306 (typically because MariaDB has been installed manually).

It only affects the development stack, which publishes 3306 on the host so you can point a database client at it. The production compose files do not publish that port at all, so they cannot collide with a local MariaDB.

Identify the process using port 3306

sudo lsof -i :3306

With this we find out the PID identifier of the process running on 3306

Kill process

sudo kill -9 <PID>

Disable MariaDB

If you have installed uvlhub manually and you are not going to use this deployment anymore, it is convenient to disable the MariaDB process:

sudo systemctl stop mariadb
sudo systemctl disable mariadb

docker.errors.DockerException: Error while fetching server API version: (‘Connection aborted.’, FileNotFoundError(2, ‘No such file or directory’))

This is the webhook feature reaching for a Docker daemon that is not there. The client is resolved on first use, not at import, so the application boots fine and the exception surfaces later — when something actually calls /webhook/deploy.

If it fails at boot, your image is old

app/features/webhook/services.py used to call docker.from_env() at module level, and then the exception aborted start-up instead. If you see this while the container is still booting, you are running an image built before that fix; rebuild it.

The call needs two things the plain production container does not have: the Docker CLI, which is installed only in docker/images/Dockerfile.dev and docker/images/Dockerfile.webhook, and the Docker socket bind-mounted at /var/run/docker.sock.

How features are selected

Which features get loaded is declared in the root pyproject.toml (see Feature selection):

[tool.splent]
features = [
    "auth",
    "dataset",
    "explore",
    "featuremodel",
    "flamapy",
    "hubfile",
    "profile",
    "public",
    "team",
    "zenodo",
]
features_dev = [
    "webhook",
]
features_prod = [
    "webhook",
]

app/feature_loader.py walks app/features/, and loads a feature only if it appears in features or in the list for the current environment (features_dev or features_prod). webhook is declared in both environment lists: its test suite needs it in development, and the CD pipeline posts to it in production.

The filter needs pyproject.toml to be present

app/feature_loader.py reads pyproject.toml from the directory above app/. If the file is not there, it falls back to loading every package it finds under app/features/. The production images (Dockerfile.prod, Dockerfile.render) copy it for exactly this reason; if you maintain a custom image, copy it too or the declarative filter is silently inactive.

Solution 1: deploy with the webhook compose file

If you want the webhook-driven deployment, use the compose file that was built for it:

docker compose -f docker/docker-compose.prod.webhook.yml up -d --build

It builds docker/images/Dockerfile.webhook, which installs the Docker CLI, bind-mounts the repository at /workspace and mounts /var/run/docker.sock into the container. With those in place docker.from_env() succeeds. This is the only production compose file with a build: section, which is why --build appears here.

Solution 2: drop the feature from your deployment

If you do not need continuous deployment through the webhook, remove "webhook" from both features_dev and features_prod in pyproject.toml. Images that carry pyproject.toml honour the lists; if yours does not, copy it in or delete app/features/webhook/ from your fork.

After that, bring the containers back up. These compose files pull the image instead of building it, so there is no --build:

docker compose -f docker/docker-compose.prod.yml up -d

If you are deploying using the SSL option:

docker compose -f docker/docker-compose.prod.ssl.yml up -d

Both files ship with the placeholder image: <your_dockerhub_name>/uvlhub:latest. If you have not replaced it yet, see Deployment in server.