Repository navigation
v2.30.1: Background supervisor survives terminal hangups
The background supervisor now detaches from the terminal session that started it, so closing a terminal or logging out of SSH no longer takes your daemons down with it. pitchfork clean --prune now also removes namespaces, slugs and config files left behind by deleted projects, and port-conflict errors now say which address is taken.
Fixed
-
Background supervisor detaches from the caller's terminal (#1022) by @jdx. The supervisor that the CLI starts when needed (for example by
pitchfork startor the shell hook) stayed in the caller's session and process group. A terminal hangup, such as an SSH logout or a closed window, could send it SIGHUP. The supervisor treats SIGHUP as a request to stop, so every daemon stopped with it. On Unix, the supervisor now callssetsid()and runs in its own session with no controlling terminal. Foregroundpitchfork supervisor run(used under systemd, launchd or in containers) is unchanged. The shell-hook guide has a new recipe for keeping user-level daemons running on hosts without systemd or launchd: useauto = ["start"]with nostop, plusretry = trueandready_delay = 0. -
pitchfork clean --pruneremoves registrations of deleted directories (#1021) by @jdx. Besides stopped daemon records,--prunenow removes[namespaces]and[slugs]entries and attached config files from the global config when their paths are confirmed missing. Before, these leftovers kept a namespace from being reused and kept old slug mappings active.- Namespaces that still have running daemons are kept.
- If a path can't be checked because of a permission or mount error, the entry is kept and you get a warning.
- Passing namespace arguments limits pruning to those namespaces. A
--daemonfilter skips the registry entirely. pitchfork config addcan now re-register a namespace whose old directory is gone, as long as no daemon is running under it.
Pruning only happens when you run it. The supervisor does not remove registrations on startup, so directories that are only temporarily unmounted are safe.
-
Port-conflict errors name the address and handle unknown holders (#1017) by @Marukome0743. The error now gives the local address where the port was taken. If pitchfork can't find the process holding the port, the error says so instead of showing
process 'unknown' (PID: 0):port 3000 is already in use on 0.0.0.0 by process 'node' (PID: 4242) port 3000 is already in use on 127.0.0.1, but no process holding it could be found; it may belong to another user, or be a connection no process owns any moreProcess lookup is also more precise. It now looks only at TCP sockets on addresses that conflict with the failed bind, and prefers listening sockets. This applies to both
portandready_port. The troubleshooting guide explains how to list every socket on a port, including other users' sockets (sudo lsof -nP -iTCP:<port>).
Full Changelog: v2.30.0...v2.30.1
💚 Sponsor pitchfork
pitchfork is built and maintained by @jdx, an open source developer at entire.io, the title sponsor of his open source work.
If pitchfork has a place in your development workflow, please consider becoming an individual or company sponsor. Your support funds ongoing development and helps keep pitchfork fast, free, and independent.