Poor Man's Cron

Solution

Schema:

CREATE TABLE scheduler_state (
    job_name VARCHAR(64) PRIMARY KEY,
    last_run_at INT UNSIGNED NOT NULL
);

INSERT INTO scheduler_state (job_name, last_run_at) VALUES ('session_cleanup', 0);

One row per named job is enough; job_name as the primary key lets the same table serve multiple scheduled jobs later without a schema change.

Claiming logic:

<?php

declare(strict_types=1);

// no-execute: requires a live MySQL connection via PDO.
function claimScheduledRun(PDO $pdo, string $jobName, int $intervalSeconds): bool
{
    $now = time();
    $stmt = $pdo->prepare(
        'UPDATE scheduler_state
         SET last_run_at = :now
         WHERE job_name = :job_name
           AND last_run_at <= :threshold'
    );
    $stmt->execute([
        'now' => $now,
        'job_name' => $jobName,
        'threshold' => $now - $intervalSeconds,
    ]);

    return $stmt->rowCount() === 1;
}

The UPDATE ... WHERE last_run_at <= :threshold is the entire locking mechanism — there's no separate lock acquired and released, because the database's own row-level locking during the UPDATE already serializes concurrent attempts to modify the same row. Two requests arriving at the same instant both issue this UPDATE; the database processes them one at a time internally, and only the first one finds a row that still satisfies last_run_at <= :threshold (the second one's UPDATE runs after the first has already advanced last_run_at, so its WHERE clause matches zero rows).

Why the affected-row count matters: rowCount() === 1 is the signal that this specific request was the one that successfully updated the timestamp — the equivalent of "acquired the lock" in the file-based version. A request whose UPDATE matches zero rows (because another request already updated last_run_at past the threshold microseconds earlier) gets rowCount() === 0 and correctly knows it lost the race and should not run the job. Without checking this, every request would believe it successfully claimed the run, since the UPDATE statement itself doesn't error just because it matched no rows.

Why this fits better than working around NFS: an atomic conditional UPDATE pushes the concurrency-safety requirement onto the database, which is specifically designed to serialize concurrent writes to the same row correctly — regardless of the filesystem underneath the web servers. This sidesteps the NFS flock() reliability question entirely rather than trying to verify or work around it, which is the safer choice when the underlying locking primitive's reliability is already in doubt.

Diagnosis

The sequence that produces multiple sends: shouldSendDigest() does a read (file_get_contents), a check, and a write (file_put_contents) as three separate, unsynchronized steps. When a burst of simultaneous requests arrives (say 5 of them, all within the same second, right after the weekly interval has elapsed): all 5 call file_get_contents($stateFile) before any of them has called file_put_contents() — because nothing forces them to wait for each other. All 5 read the same old $lastRun value, all 5 compute ($now - $lastRun) >= $intervalSeconds as true, and all 5 return true and separately trigger a digest send. Each one also calls file_put_contents() afterward, but by then the damage is done — the digest has already gone out multiple times. This is the check-then-act race the article names directly: nothing serializes the read-check-write sequence across concurrent requests.

Why it's tied to simultaneous traffic specifically: the bug requires multiple requests to be between the read and the write at the same time — with low, spread-out traffic, requests arrive far enough apart that the first one's write always completes before the second one's read, and the code behaves correctly by accident. A social-media traffic spike is exactly the condition that reliably produces several requests within the same instant, which is why the bug shows up specifically then and not during ordinary browsing traffic or during a developer's manual single-request testing — manual testing essentially never has two requests hit the check-then-act window concurrently.

Reproducing deliberately: rather than waiting for next week's traffic, simulate concurrent requests directly — a small script that forks several child processes (or uses curl with parallel requests, e.g. for i in {1..5}; do curl -s https://example.com/digest-trigger & done; wait) all hitting the triggering endpoint at effectively the same instant, with the state file pre-set so the interval has already elapsed. This should reproduce multiple true returns from a single logical "should run" decision, confirming the diagnosis without needing production-scale coordinated traffic.

The fix: wrap the read-check-write sequence in a flock()-protected critical section, exactly as in the article's claimScheduledRun() example — open the state file, acquire an exclusive lock, then do the read/check/write while holding it, then release. This closes the gap because it forces the five concurrent requests to take turns rather than all observing the same pre-update state: the first to acquire the lock sees the elapsed interval and claims it (updating the timestamp before releasing the lock); every subsequent request, once it gets the lock, reads the already-updated timestamp and correctly sees the interval hasn't elapsed since the successful claim, returning false.

Review

Storing the timestamp in the session: this is a fundamental design error, not just a missing safeguard. A session is per-visitor — each visitor gets their own session and therefore their own independent last_cleanup value. This means the job doesn't run "once per hour across the whole site," it runs "once per hour, separately, for every single visitor who happens to have an old-enough session timestamp" — so on a site with regular traffic, cleanup could fire dozens of times an hour, once per visitor whose personal session clock happens to have elapsed, all of them redundantly scanning and deleting from the same shared uploads directory. The state needs to live somewhere shared across all requests from all visitors — a file or database row, as in the article and the other exercises in this lesson — not somewhere scoped to one visitor's session.

The unlucky visitor: whichever visitor's request happens to trigger the inline cleanup pays the cost directly — their page load blocks on a full directory scan and a batch of file deletions before they see anything, turning what should be an unrelated background maintenance task into unpredictable latency on a random visitor's experience. This is a problem even if it's rare precisely because it's unpredictable: most visitors get a fast response, and occasionally, with no visible cause from their side, someone's request takes several seconds longer for a reason that has nothing to do with what they asked for — a hard bug to even notice, let alone diagnose, from user reports alone.

The concurrency race: because the state is per-session rather than shared, the check-then-act race from the diagnose exercise doesn't apply in the same way — two different visitors' concurrent requests read and write two different session values, so they don't race over the same stored timestamp. But this isn't a point in the design's favor: it's a symptom of the same root problem (per-session state), and it doesn't make the design safe — it just replaces "sometimes runs multiple times concurrently" with "runs far too often, independently, once per visitor," which is arguably worse for a filesystem-scanning job.

Revised design: move the timestamp to a shared file (or database row, if available) exactly as shown elsewhere in this lesson, protected with flock() (or an atomic UPDATE ... WHERE if using a database) so only one request across the entire site claims each cleanup window. For the blocking problem, don't run the scan-and-delete inline before rendering the visitor's page — trigger a detached background process (proc_open) or enqueue the work if a queue exists, so the triggering request returns normally and the actual cleanup runs independently of any specific visitor's page load.