I outgrew nohup, so I built a daemonless job manager

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. Top comments (0)