Docker DB containers are not started after reboot with docker.socket enabled

[jlupox]

System details

Omarchy 4.0.1-1 (Quattro)
Docker 29.7.2
PostgreSQL installed via Install > Development > Docker DB

This has been reproduced on two separate Omarchy Quattro 4.0.1 systems.

What's wrong?

Docker DB containers are not running after reboot because docker.service is inactive.

After boot, docker.socket is listening but docker.service is inactive. A TCP connection to a published container port does not activate the Docker daemon.

For example, after reboot:

docker.service  disabled / inactive
docker.socket   enabled / listening
postgres18      stopped

Starting a Rails application and accessing it produces:

PG::ConnectionBad:
connection to server at "127.0.0.1", port 5432 failed:
Connection refused

However, running:

sudo docker ps -a

immediately activates Docker through docker.socket. Once Docker is activated, the PostgreSQL container starts because it has the unless-stopped restart policy, and the Rails application works without any other change.

Steps to reproduce

1. Install PostgreSQL using Install > Development > Docker DB > PostgreSQL.
2. Verify that the PostgreSQL container is running.
3. Reboot the machine.
4. Start a local Rails application configured to use PostgreSQL on 127.0.0.1:5432.
5. Access the application.
6. The database connection is refused.
7. Run:

sudo docker ps -a`

8. Access the application again.
9. The application works.

The same behavior occurs with PostgreSQL 18 freshly installed through the official Quattro Docker DB installer.

The issue was also reproduced on a second Omarchy Quattro 4.0.1 system.

Expected behavior

A PostgreSQL container installed through Install > Development > Docker DB with the unless-stopped restart policy should be available after reboot, or Quattro should provide/document the expected mechanism for starting Docker DB containers before applications that depend on them.

Additional information

The current Quattro configuration uses:

docker.service  disabled
docker.socket   enabled

When something accesses /run/docker.sock, docker.socket activates docker.service.

A TCP connection such as:

Rails → 127.0.0.1:5432 → Docker published port

does not access /run/docker.sock, so it cannot activate docker.service.

Running:

sudo docker ps`

does access the Docker API and therefore activates the daemon.

[gitsult4n]

Your read is right, and the missing piece is that Quattro turns docker.service off deliberately:

install/config/enable-services.sh:7    systemctl enable docker.socket
bin/omarchy-upgrade-to-quattro:1350   systemctl disable docker.service
bin/omarchy-upgrade-to-quattro:1356   enable_system_service docker.socket

So only the socket unit comes up at boot. --restart unless-stopped is a daemon-side policy applied when the daemon starts, so with no daemon nothing restarts. And nothing wakes it either: 127.0.0.1:5432 is published by docker-proxy, a child of the daemon, which does not exist while the daemon is down. There is no listener at all, hence connection refused rather than a delay. docker ps hits /run/docker.sock, which is the one thing that does activate it, exactly as you observed.

Enable the service unit as well:

sudo systemctl enable --now docker.service

This does not cost you boot time here, because the repo already ships the drop-in that keeps an enabled docker.service off the boot critical path:

etc/systemd/system/docker.service.d/no-block-boot.conf
[Unit]
DefaultDependencies=no

The socket unit stays enabled and keeps working, the daemon just no longer waits to be poked.

Every entry in the Docker DB installer is published on a loopback port with that restart policy (bin/omarchy-install-docker-dbs:18-23), so anything installed through that menu has the same problem, not just Postgres.

[twiking]

Check this: #8098