I outgrew nohup, so I built a daemonless job manager

Ryan Wallace — Sat, 08 Aug 2026 11:48:51 +0000

I've long used nohup for background processes that I want to run independently of the terminal. These types of jobs are usually long-running, sometimes launched over an SSH connection, and often have dependencies on other jobs.

I built Jobman to combine the simplicity of nohup with features I previously wrote one-off shell scripts for, including:

retries
timeouts
dependencies between jobs
email or webhook notifications on completion or failure
separate stdout and stderr logging with a combined observed-order view

Jobman does this with a small per-job supervisor process; there's no shared daemon to run. It uses SQLite for job and run metadata and plain files for log storage. It's intended to be a local, per-user tool, not a system-wide or distributed scheduler.

Jobman is an MIT-licensed command-line job manager written in Go. It runs on Linux, macOS, and Windows, and it doesn’t need a shared daemon.

Basic Examples

Here's an example session using Jobman to launch a Python script, examine its logs, and check its status:

$ jobman run --name import-data --retries 3 --run-timeout 30m \
  --retry-timeouts -- python3 ./import_data.py
019fddfe-23bb-732d-a869-2aaee43c03d7

$ jobman logs --follow import-data
Starting import...
Imported batch 1/3.
Imported batch 2/3.
^C

$ jobman status import-data
019fddfe-23bb-732d-a869-2aaee43c03d7    import-data     running

Above, the Ctrl-C stopped logs --follow, while the Python process continued under Jobman.

Here's a similar example live:

Fit and Alternatives

Jobman is mainly for noninteractive local work:

data imports and exports
research scripts and model runs
long builds or downloads
maintenance commands
jobs started over SSH
small local pipelines with dependencies.

Jobman isn’t meant to replace tmux when you need to reattach to an interactive terminal. It also isn’t a boot-time service manager or a distributed scheduler like Slurm.

Comparing Jobman to possible alternatives:

nohup: when you just need redirection and a PID
tmux: when you want the terminal session back
systemd-run: when systemd should own the process
jobman: when you want a durable local job with retries, timeouts, logs, dependencies, and later lifecycle controls

Jobs can survive a closed terminal or lost SSH connection, but they may still be stopped when the operating-system user session ends, depending on session configuration.

Try Jobman

On macOS:

brew install ryancswallace/tap/jobman

Linux packages and Windows builds are also available. The installation guide has the full set of options.

Once installed, this is enough to create and inspect a first job:

jobman run --wait --name first-job -- jobman --version
jobman status first-job
jobman logs --stream stdout first-job

The source is on GitHub, and the documentation is at jobman.tech.

I’ve also written an Inside Jobman series about the implementation, including detached supervision, scheduling, process trees, timeouts, and durable logs.

Do you see Jobman replacing any combinations of tools you currently use (nohup, tmux, screen, systemd-run)? If Jobman looks useful to you, let me know what types of jobs you would use it for.

DEV Community: Ryan Wallace

I outgrew nohup, so I built a daemonless job manager

Basic Examples

Fit and Alternatives

Try Jobman