You’ve been there. You SSH into a server, kick off a data import that’ll take three hours, and walk away. Then your Wi-Fi hiccups. The SSH session dies. The job dies with it. And nobody—not your shell, not your terminal, not the universe—gives a damn.
We’ve all accepted this as just how things work. We sprinkle nohup like holy water, maybe wrap things in tmux if we’re feeling fancy, and pray. But here’s what nobody tells you: the gap between ‘just run it in the background’ and ‘set up a full job scheduler’ is where 90% of operational pain lives.
That gap is exactly what Jobman fills. It’s not another Kubernetes. It’s not systemd. It’s what nohup should have been all along.
Think about the last time you wrote a shell script to handle retries. You probably wrote something ugly: a while loop, a sleep, a counter variable named retry_count because you ran out of creativity at 2 AM. Maybe you added a timeout. Maybe you didn’t, and the job hung for six hours on a dead API call while you slept peacefully, blissfully unaware.
Every ad-hoc retry script is a confession that nohup failed you and you compensated with duct tape.
Jobman doesn’t ask you to install a daemon. There’s no shared service running in the background, consuming memory, requiring configuration files, and breaking at the worst possible moment. Each job gets its own tiny supervisor process. That’s it. You run jobman run --retries 3 --run-timeout 30m python3 import_data.py and you’re done. The job survives terminal disconnects. It retries on failure. It times out instead of hanging forever. It logs stdout and stderr separately, with a combined view that preserves the actual order things happened.
Here’s where it gets interesting. Jobman supports dependencies between jobs. That means you can declare ‘run job B only after job A succeeds’ without writing orchestration glue code. The real shift isn’t replacing nohup—it’s moving from ephemeral, forgettable commands to a declarative, stateful model where your background tasks become auditable, recoverable entities.
That sounds heavy, but it’s not. Jobman stores metadata in SQLite and logs in plain files. You can inspect everything. You can replay. You can answer ‘did that job actually finish?’ without SSH-ing in and checking if a process is still alive like some digital pulse-taker.
The beauty is in what Jobman refuses to be. It’s not a distributed scheduler. It’s not trying to be Airflow or Celery or Nomad. It’s a per-user, local tool that sits on your machine or your server and does one thing well. Sophistication isn’t about how many features you add—it’s about choosing the right five features and refusing to add the sixth.
If you’ve ever lost a long-running job to a flaky connection, spent an hour debugging a shell script that should have taken five minutes, or wished you could just see what happened when a background process failed at 3 AM—Jobman isn’t just a nice-to-have. It’s the tool you didn’t know you needed because you’d gotten so used to the pain that you stopped noticing it.
And that’s the real lesson here. The best tools don’t add complexity. They remove suffering so quietly that you forget it was ever there.
FAQ
Q: Why not just use tmux or screen to keep sessions alive?
A: Because keeping a terminal session alive isn't the same as managing a job. tmux doesn't give you retries, timeouts, dependencies, or durable logs. It keeps your shell breathing; Jobman keeps your job breathing—and thinking.
Q: What does this mean for my daily workflow?
A: Stop writing one-off retry loops and timeout wrappers. Replace them with a single Jobman command that declares what you want—retries, timeout, dependencies—and lets the tool handle the rest. Your background tasks become inspectable objects instead of forgotten processes.
Q: Isn't this just reinventing systemd-run or cron with extra steps?
A: No. systemd-run requires systemd and system-level access. cron is time-based, not event-driven. Jobman is per-user, daemonless, and designed for the messy middle: jobs that are too important for nohup but too simple to justify a full scheduler.