The quirk table, measured instead of assumed #8

2026-09-11T10:19:41+02:00

mi commented

2026-09-11 10:19:41 +02:00

Three of its four entries were wrong. redis, mariadb and mysql were all
listed as moving their port through an environment variable — REDIS_PORT,
MARIADB_TCP_PORT, MYSQL_TCP_PORT. None of the three images reads one.
Werkdock picked a free port, told nobody, and reported it: a client got a
number nothing was listening on, which is the single failure the whole
quirk mechanism exists to prevent.

It was found the only way it could be — by starting the images and
connecting to the port werkdock named. redis-server takes --port; the two
database entrypoints read the port out of the server's own configuration,
so the flag has to reach the command line there too. A quirk can now move
a port by a flag, and does so only while the container still runs the
image's own program: appending an argument to a command the client chose
would be a guess, and guessing is what this commit is about.

Two more things surfaced on the way. Redis could not start at all — its
entrypoint chowns its data directory as root, which an unprivileged user
namespace cannot do, so it needs the same treatment postgres has. And an
image's /run did not show through: /run is the instance's own directory
so that sockets survive a stop, which left mariadb without /run/mysqld
and dying on "Bind on unix socket: No such file or directory". The
instance's /run is now seeded from the image's.

postgres was right all along and is untouched; it really does read PGPORT.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

Three of its four entries were wrong. redis, mariadb and mysql were all listed as moving their port through an environment variable — REDIS_PORT, MARIADB_TCP_PORT, MYSQL_TCP_PORT. None of the three images reads one. Werkdock picked a free port, told nobody, and reported it: a client got a number nothing was listening on, which is the single failure the whole quirk mechanism exists to prevent. It was found the only way it could be — by starting the images and connecting to the port werkdock named. redis-server takes --port; the two database entrypoints read the port out of the server's own configuration, so the flag has to reach the command line there too. A quirk can now move a port by a flag, and does so only while the container still runs the image's own program: appending an argument to a command the client chose would be a guess, and guessing is what this commit is about. Two more things surfaced on the way. Redis could not start at all — its entrypoint chowns its data directory as root, which an unprivileged user namespace cannot do, so it needs the same treatment postgres has. And an image's /run did not show through: /run is the instance's own directory so that sockets survive a stop, which left mariadb without /run/mysqld and dying on "Bind on unix socket: No such file or directory". The instance's /run is now seeded from the image's. postgres was right all along and is untouched; it really does read PGPORT. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

mi added 1 commit 2026-09-11 10:19:41 +02:00

The quirk table, measured instead of assumed

werkator build succeeded after 00:03

Details

f5218b03ac

Three of its four entries were wrong. redis, mariadb and mysql were all
listed as moving their port through an environment variable — REDIS_PORT,
MARIADB_TCP_PORT, MYSQL_TCP_PORT. None of the three images reads one.
Werkdock picked a free port, told nobody, and reported it: a client got a
number nothing was listening on, which is the single failure the whole
quirk mechanism exists to prevent.

It was found the only way it could be — by starting the images and
connecting to the port werkdock named. redis-server takes --port; the two
database entrypoints read the port out of the server's own configuration,
so the flag has to reach the command line there too. A quirk can now move
a port by a flag, and does so only while the container still runs the
image's own program: appending an argument to a command the client chose
would be a guess, and guessing is what this commit is about.

Two more things surfaced on the way. Redis could not start at all — its
entrypoint chowns its data directory as root, which an unprivileged user
namespace cannot do, so it needs the same treatment postgres has. And an
image's /run did not show through: /run is the instance's own directory
so that sockets survive a stop, which left mariadb without /run/mysqld
and dying on "Bind on unix socket: No such file or directory". The
instance's /run is now seeded from the image's.

postgres was right all along and is untouched; it really does read PGPORT.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

mi manually merged commit ce20df9f76 into main

2026-09-11 10:19:45 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: mi/werkdock#8