I'm blogging about Emacs, Drupal, php and exciting subjects

My PHP projects don't run PHP on the host. This site runs in DDEV, CaRMen runs in a docker compose stack, and whatever PHP the host has is irrelevant to both.

This site runs Drupal's cron every 15 minutes from a crontab on the server, with the output appended to a log file in my home directory. For about twelve days in September, almost every one of those runs tried to send me an email, failed, and wrote two lines about it to that log. Nobody read the log. The emails were security update notifications.

A reindex that was scheduled purely as insurance, against a problem that almost certainly wasn't going to happen this time, finished with a real, measurable bonus nobody had gone looking for: nearly a third of the database's total index storage disappeared, cleanly, as a side effect of doing something that was never actually about storage in the first place.

I went looking for this laptop's crontab to write a comparison with systemd timers, and there wasn't one. No crontab binary, no /etc/cron.d, no cron daemon running at all — crontab -l just says command not found.

CaRMen, the CRM I built for myself, now runs as two public sites: the real instance and a demo. Public means bots find the login endpoint within hours, so in October I added rate limiting to logins and to password-reset emails. The limits themselves took a few lines of Symfony configuration.

A freshly upgraded database reported itself perfectly healthy, right up until every other service that needed to talk to it got a flat connection refusal. The database wasn't lying about being healthy. It genuinely was — to itself, and to nothing else.

The version of a database upgrade that fits on a disk with limited free space and the version of a database upgrade that keeps a true instant rollback available turned out to be two different operations. Choosing the one that actually fit meant giving up the other, deliberately, with the tradeoff written down plainly rather than discovered the hard way if it were ever needed.

A search engine's core ranking signal sat at zero for every single page in the corpus, fleet-wide, for 29 days. Nothing crashed. No error fired. The number that determines how results get ordered was simply wrong, silently, for a month, until someone went looking for a different reason entirely and found it by accident.

For about a day in August, the Postgres server behind my search engine kept dying. Not slowing down, not timing out: the Linux OOM killer was terminating it, roughly every 20 to 90 minutes at the worst point, and each kill meant a crash-recovery cycle of about 90 seconds while Postgres replayed its write-ahead log.

A database upgrade tool refused to run, complaining about two disks that don't exist. The two volumes it was pointed at were sitting on the exact same physical disk. The error was correct anyway — from the tool's own point of view, they might as well have been on different planets.