Starting and stopping services¶

This page describes routine operation of an installed system: starting it, stopping it, and confirming it is healthy.

Startup order¶

Components must be started in order, because each depends on those before it. Starting the Metadata component before the database is available causes it to fail at startup.

1. Database
2. ETL
3. Metadata
4. P2P, where installed

Allow the database to complete its startup before continuing. On a first start, where a dump is being restored, this takes several minutes.

Shutdown is carried out in the reverse order.

Starting all services¶

Where the installation includes the supplied start script, it carries out the sequence and the waiting between stages:

./start-all.sh

On Windows:

.\start-all.bat

The script checks that Docker is available and that the required ports are free before starting anything, and reports the service addresses once complete.

To start the components individually, run the following from each installation directory in the order above:

docker compose up -d

After starting the database, confirm it is accepting connections before starting the next component:

docker exec pg5444 pg_isready -p 5444

Stopping all services¶

./stop-all.sh

On Windows:

.\stop-all.bat

To stop components individually, run the following from each installation directory in reverse order:

docker compose down

This stops and removes the containers while leaving data intact. Database contents persist in the host data directory and are not affected.

Confirming the system is healthy¶

The following checks confirm that each component is running and able to reach its dependencies. Substitute the application host address from Hosts and ports.

All containers¶

docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"

Every expected container must show a status beginning Up. A container showing Restarting is failing repeatedly; inspect its logs.

Each service¶

docker exec pg5444 pg_isready -p 5444
curl -sf http://localhost:8002/cvdlinkbk/health && echo "ETL responding"
curl -sI http://localhost:48000/ | head -1
curl -sf http://localhost:8060/health && echo "P2P responding"

Federation state¶

Where the P2P component is installed:

curl http://localhost:8060/peers

The federation status page of the Metadata application presents the same information for operational use.

Viewing logs¶

docker compose logs -f

For a single container:

docker logs -f <container name>

Where the installation includes the supplied script, logs from all components are collected together:

./logs-all.sh

To examine a specific period, limit the output by time:

docker logs --since 30m <container name>

Restarting after a configuration change¶

A restart does not reload environment files. Where configuration has changed, recreate the containers:

docker compose up -d

Where only the running state needs resetting, a restart is sufficient:

docker compose restart

The P2P component reads its settings file at startup, so a restart is sufficient for that component.

Restarting after a host reboot¶

Components are configured to restart automatically unless they were stopped deliberately, so no action is normally required after a reboot. Confirm that the expected containers are running and that the startup order was respected:

docker ps

Where a component failed because a dependency was not yet available, restart it:

docker compose restart

Applying an update¶

1. Stop the component being updated.
2. Obtain the new image, by pulling it or loading a supplied archive.
3. Start the component.
4. Apply any database migrations, as described on the component's installation page.
5. Carry out the verification steps for that component.

Update one component at a time and verify each before continuing, so that a failure can be attributed to a specific change.