I've encountered this error when nesting a Drupal site within multiple sub-directories when organising by forge, user/organisation name, and the repository name:

[ERROR] The socket file path is too long (> 107): /home/opdavies/Code/repository/git.oliverdavies.uk/this/is/a/very/very/long/path/data/this-is-a-test-project-db/mysql.sock

I see there is a DB_SOCKET variable that I've added to my .env file, but it doesn't seem to be making a difference.

This is the .env file:

DB_SOCKET=/tmp/mysql.sock
DOCROOT=web
PROJECT_NAME=this-is-a-test-project

It has been added to Git, which is confirmed by the PROJECT_NAME and DOCROOT being set correctly.

The nix-settings service gets the updated DB_SOCKET value, but the database service still gets the original default value which still causes the error.

Am I doing this correctly? Are my expectations correct or not?

I'm happy to look into this and contribute a fix if it's a bug.

Issue fork drupal_flake-3620751

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

opdavies created an issue. See original summary.

freelock’s picture

freelock
Location Seattle
commented

Hi, Oliver,

I don't recall implementing anything specific about a $DB_SOCKET from the environment, I think it's calculating the socket path from the current directory and rewriting that whenever the server is started (or whenever the nix-settings script is run, which happens from several other scripts).

I don't see it in .env.example, which I've tried to keep current with env vars used (or planned), so I think that's a feature that doesn't exist?

I think it's a good idea as an option -- it should be relatively straightforward to use that env var if it exists in nix-settings and the script that configures the database.

It would place the onus on you to change that if needed for other projects running on the same host. I would also be thinking about the consequences of committing that change, if you run multiple instances of the same site on the same host -- e.g. a dev and stage copy -- I don't use the flake services for this type of environment, or production, so I don't think this is a problem as long as the current behavior doesn't break if it's unset.

I was thinking about a couple other scenarios for improvement, which might or might not be relevant, let me know if this affects your implementation at all:

1 - support for git worktrees -- this seems to be something my AI agents want to do, so thinking about how best to support running multiple copies of the same site on the same host, and whether there's something we could do in Drupal Flake to make this easier

2 - support for running in a CI job -- our CI/CD currently runs entirely in Docker containers, and we are running behat tests in one step against a dev database -- and we've been expanding our test coverage substantially. Our current ci environment is "cheating" by doing this, which doesn't work specifically when we are testing file uploads -- the file uploads end up in the test container, but the site we're talking to for the tests are actually on a remote server - and so the files aren't found. So I've been thinking about how to auto-import a database locally just for tests -- and Drupal Flake seems like an ideal way to support this scenario, if I can sort that out...

Anyway, happy to take an MR to add a $DB_SOCKET env var as an optional feature...

opdavies’s picture

opdavies
He/him
Primary language English
Location Wales
commented

I found this code in template/flake.nix, so assumed it was an available option:

# Use relative path, but php-fpm.nix should handle the absolute path conversion
dbSocket = getEnvWithDefault "DB_SOCKET" "data/${projectName}-db/mysql.sock";

I'm happy to look into this and submit an MR as it's a change that I'd use.

freelock’s picture

freelock
Location Seattle
commented

Hmm probably something leftover from when I was trying to get things working with phpunit - maybe there's something in the #test devshell setting that? (Probably removed, because I ended up tracking down to a core issue - #3546633: PHPUnit functional tests cannot connect to MySQL database with a specified unix_socket

I think the env vars need to get explicitly loaded from the .env file, iirc -- it's probably simple enough to add a stanza to do that...

opdavies opened merge request !6

opdavies’s picture

opdavies
He/him
Primary language English
Location Wales
commented

MR created with some proposed changes to make DB_SOCKET work consistently.

opdavies’s picture

opdavies
He/him
Primary language English
Location Wales
commented
Status: Active » Needs review
freelock’s picture

freelock
Location Seattle
commented
Status: Needs review » Needs work

Review by Sol 6.1 found some issues...

opdavies’s picture

opdavies
He/him
Primary language English
Location Wales
commented
Status: Needs work » Needs review

Summary of changes:

template/flake.nix (34 lines)

- Merge the custom socket into settings.mysqld via lib.mkMerge + lib.optionalAttrs dbSocketIsAbsolute instead of a shallow //, so skip_networking, skip_grant_tables, transaction_isolation and the conditional resource limits survive
- Add settings.client.socket (via lib.mkIf dbSocketIsAbsolute) so all MySQL clients use the exact socket
- Make the db readiness probe override effective (lib.mkForce) — it was silently dropped by two additional shallow-merge bugs: baseConfig's trailing open-browser block and the default target's baseConfig // { … }; both now use lib.recursiveUpdate

tests/test-db-socket.sh (rewritten)

- Asserts the generated my.cnf preserves all MySQL settings and configures [mysqld]/[client] sockets, for all four nix run targets
- Asserts the readiness probe in the generated JSON uses the exact socket (not /mysql.sock)
- New live smoke test: boots MariaDB, waits for health on the exact socket, verifies -db-configure completes and the drupal database is initialized, and that TCP connections are refused (skip_networking)

.gitlab-ci.yml

- New test-db-socket CI job running the test suite

CHANGELOG.md

- Fix entry for the MySQL socket handling

Verified: nix flake check --no-build ✓, all 40 test assertions pass including the MariaDB smoke test, test-service-guard.sh ✓, default relative-path behavior unchanged.