Author: Daryle De Silva

Here’s a trap that’ll bite you exactly once with Ollama: if you run ollama create using the same name as an existing model, it overwrites the original. No warning, no confirmation, just gone.

The Scenario

Say you pulled mistral:7b-instruct and want to customize it with a new system prompt or different parameters. You write a Modelfile:

FROM mistral:7b-instruct
SYSTEM "You are a code reviewer..."
PARAMETER temperature 0.3

Then you run:

ollama create mistral:7b-instruct -f Modelfile

Congratulations, you just replaced your base model. The original mistral:7b-instruct is now your customized version. Want the vanilla one back? Time to re-pull it.

The Fix

Always use a distinct tag name for your customizations:

# Copy the base first (shares blobs, no extra disk)
ollama cp mistral:7b-instruct mistral:7b-instruct-base

# Create your custom version with a NEW name
ollama create mistral:7b-code-reviewer -f Modelfile

The ollama cp command shares the underlying blobs with the original, so it doesn’t double your disk usage. It’s basically free insurance.

Naming Convention That Works

I’ve settled on this pattern: base-model:size-purpose

ollama list
# mistral:7b-instruct          4.4 GB  (original)
# mistral:7b-code-reviewer     4.4 GB  (custom)
# mistral:7b-instruct-base     4.4 GB  (safety copy)
# qwen2.5-coder:7b             4.7 GB  (original)

The sizes look alarming but remember: copies share blobs. Actual disk usage is much lower than the sum suggests.

Why This Matters

When you’re iterating on Modelfile configs (tweaking temperature, system prompts, context length), you’ll run ollama create dozens of times. One slip with the wrong name and you’re re-downloading 4+ GB. Use distinct tags from the start and you’ll never have that problem.

Docker containers expect one process. PID 1 runs, and when it exits, the container stops. But what if you need two processes running simultaneously — say a dev server and a background watcher, or a web server and a cron daemon?

The Naive Approach

You might try chaining commands:

command: '/bin/bash -c "process-a && process-b"'

This runs process-a, waits for it to finish, then runs process-b. Not parallel — sequential. And if process-a runs forever (like a dev server), process-b never starts.

The & wait Pattern

Background the processes with &, then wait for all of them:

command: '/bin/bash -c "process-a & process-b & wait"'

Here’s what happens:

1. process-a & — starts in the background
2. process-b & — starts in the background
3. wait — blocks until ALL background processes exit

The wait is critical. Without it, bash reaches the end of the command string, exits, and Docker kills the container because PID 1 died.

Real-World Example

Running two webpack dev servers on different ports for separate frontend bundles:

services:
  node:
    build: .docker/builds/node
    command: '/bin/bash -c "npm install && PORT=8080 npm run dev & PORT=8081 npm run dev:widgets & wait"'
    ports:
      - "8080:8080"
      - "8081:8081"
    restart: always

Both dev servers run simultaneously in one container. If either crashes, wait still blocks on the surviving process, keeping the container alive.

When to Use This vs Separate Containers

Use & wait when:

• Processes share the same filesystem and need the same volumes
• They’re tightly coupled (same codebase, same dependencies)
• You want simpler compose files for dev environments

Use separate containers when:

• Processes have different resource needs or scaling requirements
• You need independent health checks or restart policies
• You’re running in production (one process per container is the Docker way)

Gotcha: Signal Handling

When Docker sends SIGTERM to stop the container, it goes to PID 1 (bash). By default, bash doesn’t forward signals to background processes. Add a trap if you need graceful shutdown:

command: '/bin/bash -c "trap \"kill 0\" SIGTERM; process-a & process-b & wait"'

kill 0 sends the signal to the entire process group, cleanly shutting down all backgrounded processes.

You set up a cron job inside your Docker container. The logs show it firing. But nothing happens. No errors, no output, no evidence it actually ran. Welcome to the world of silent cron failures.

The Setup

You add a cron job to your container — maybe a periodic cleanup task, a file scan, or a scheduled PHP script:

*/15 * * * * php /var/www/html/artisan schedule:run >> /proc/1/fd/1 2>&1

Docker logs show the cron daemon triggering the job on schedule. You see lines like:

crond: USER www-data pid 7590 cmd php /var/www/html/artisan schedule:run >> /proc/1/fd/1 2>&1

But the actual command never executes. No output. No errors in your app logs. Nothing.

Two Silent Killers

1. The /proc/1/fd/1 Permission Trap

Redirecting output to /proc/1/fd/1 (PID 1’s stdout) is a common Docker pattern — it routes cron output to docker logs. But if your cron job runs as a non-root user (like www-data), that user can’t write to root’s file descriptors:

/bin/bash: line 1: /proc/1/fd/1: Permission denied

The cron daemon fires the job, the redirect fails, and the actual command never runs. The fix? Write to a file the user owns, or use /dev/stdout if your container setup allows it:

*/15 * * * * php /var/www/html/artisan schedule:run >> /tmp/cron.log 2>&1

2. Busybox crond and File Ownership

If you’re on Alpine Linux (common in Docker), you’re running busybox’s crond, not the full cron daemon. Busybox crond is extremely picky about crontab file ownership and permissions.

If you modify the crontab file directly (instead of using the crontab command), you can easily end up with wrong ownership:

$ ls -la /var/spool/cron/crontabs/www-data
-rw-r--r-- 1 root root 117 Jan 25 00:17 www-data

Busybox crond expects the crontab file to be owned by the user it belongs to. If www-data‘s crontab is owned by root, crond silently ignores it — no error, no warning, just… nothing.

The fix:

chown www-data:www-data /var/spool/cron/crontabs/www-data
chmod 600 /var/spool/cron/crontabs/www-data

The Debugging Checklist

Next time your Docker cron job “runs” but doesn’t actually do anything:

1. Check output redirects — can the cron user actually write to the target?
2. Check crontab ownership — does the file belong to the user, not root?
3. Check permissions — crontab files should be 600
4. Check which crond — busybox crond vs crond have different behaviors
5. Test the command manually as the cron user: su -s /bin/sh www-data -c "your-command"

Silent failures are the worst kind of failures. At least now you know where to look.

Need to integrate with an API that has no documentation? Use Playwright to capture exactly what the browser sends, then replicate it.

The Approach

Open the web application in Playwright, perform the action you want to automate, and capture every network request:

const { chromium } = require('playwright');

const browser = await chromium.launch({ headless: false });
const page = await browser.newPage();

// Capture all requests
page.on('request', request => {
    console.log(JSON.stringify({
        url: request.url(),
        method: request.method(),
        headers: request.headers(),
        postData: request.postData(),
    }, null, 2));
});

await page.goto('https://app.example.com/login');
// Perform login, navigate, trigger the action you need

What You Get

Every header, every cookie, every POST body — exactly as the browser sends them. Copy these into your HTTP client (Guzzle, cURL, whatever) and you have a working integration.

Pro Tips

• Copy ALL headers — APIs sometimes check Sec-Ch-Ua, Priority, and other browser-specific headers
• Watch the auth flow — OAuth redirects, token exchanges, cookie chains are all visible
• Record, don’t guess — Even “documented” APIs sometimes behave differently than their docs say

Takeaway

When docs don’t exist (or lie), let the browser show you the truth. Playwright captures the exact HTTP conversation — just replicate it in your code.