reredirect: attach to a process you did not launch and take over its output

Attaching to a process you did not launch

The problem is narrow and real. You started a service, a build or a long script earlier, and now you want its output. Restarting it to add a redirect is disruptive, and a screen scrollback buffer is not a log file. reredirect takes an existing running program and attaches its standard output and error output to files or to another process, so you can log the output of an already launched process, send the debug output of a background process to `/dev/null`, or pipe it into a pager as if you had launched it with `>` or `|` in the first place. The audience is the kind of person who works on a live machine over SSH and needs the output of something they cannot restart.

The tool has been around a while: the copyright line in its licence file is dated 2016, the project is MIT licensed, and the last push was on 2026-07-06.

ptrace and dup2 are the entire mechanism

There is no magic here, and the documentation is honest about it. reredirect acts as a debugger to take control of a running process, using the ptrace syscall, and once it has control it uses the classical `dup` and `dup2` calls to change the targets of file descriptors 1 and 2. Redirecting to a file is the sequence you would expect from any Unix programmer:

    orig_fd = 1;
    save_fd = dup(1);
    new_fd = open(file, O_WRONLY | O_CREAT, 0666);
    dup2(new_fd, orig_fd);
    close(new_fd);

c Restoring the previous state is the mirror image:

    ret = dup2(save_fd, orig_fd);
    close(save_fd);

c The saved descriptor is what makes the restore possible, and holding onto it is also the source of the one real wart in the tool, described further down. The ptrace layer of reredirect is based on the reptyr program by Nelson Elhage.

Redirecting to files with -m, -o and -e

Compiling is the usual two steps for a C project, and the Makefile installs the binary, the `relink` helper and the man page under a prefix that defaults to `/usr/local` and can be overridden on the command line:

    make

bash

    sudo make install

bash The simple usage redirects both streams of a process to one file, where the PID is the number of the running program:

    reredirect -m FILE PID

bash The `-m` flag is only a shortcut for `-o FILE -e FILE`, and using the two flags separately is what you want when stdout and stderr should land in different places:

    reredirect -o FILE1 -e FILE2 PID

bash The `install` target of the Makefile also creates the man page directory and copies `reredirect.1` into it, so a system install gives you documentation through `man reredirect`.

relink turns a process into a pipe source

The package also ships `relink`, a helper that redirects the output of a running process to your current terminal. When `relink` exits, for example with Ctrl+C, the original state is restored and the command is detached. The usage reads like a normal pipeline:

    relink 5453
    relink 5453 | grep useful_line

bash Because `relink` keeps stderr of the original command on stderr, you can silence one stream and keep the other:

    relink 5453 > /dev/null

bash Internally `relink` is a small shell script that creates the needed context and calls reredirect as required, and it uses named pipes. If you want to build that pipe yourself, the three steps are to create the fifo, point reredirect at it, and then read from it:

    mkfifo /tmp/myfifo

bash

    reredirect -m /tmp/myfifo PID

bash

    less < /tmp/myfifo
    tee my_log < /tmp/myfifo
    cat -n < /tmp/myfifo

bash That last set is the useful part: you can log the output to a file with `tee` while watching it in `less` at the same time, from a process that was started long before.

Restoring state, and the descriptor leak that comes with it

After it has run, reredirect can put the original descriptors back, and it prints the command that does it, something along these lines:

    reredirect -N -O 5 -E 3 5453

bash The `-O` and `-E` flags act like `-o` and `-e` but work with file descriptors that are already open in the target process, and they exist only to restore a previous state. The `-N` flag has a different job. Without it, reredirect keeps the previous output open so that it can be restored, and that produces a file descriptor leak if you call reredirect several times. The documented advice is to use `-N` to close and forget the previous output, which is the right flag whenever you only want the output captured and do not plan to restore. Getting this wrong on a long lived system is the kind of thing that shows up much later as descriptor exhaustion in an unrelated process.

Linux only, and ptrace_scope decides whether it works

Two constraints narrow where reredirect can run. The first is the platform. It is Linux only, because it attaches with ptrace and controls the target at the syscall level, which ties it to Linux's syscall API and to terminal ioctl calls. A port to Solaris or BSD might be technically feasible but would need significant re-architecting to abstract the platform specific parts. Architecturally it is less limited: it works on i386, x86_64 and ARM, and the documentation expects other ports to be mostly a matter of adding an arch/ARCH.h file and a clause in the ifdef ladder in ptrace.c. The second constraint is a kernel setting. Attaching is disabled by default on Ubuntu Maverick and higher, so you will need to run this as root:

    # echo 0 > /proc/sys/kernel/yama/ptrace_scope

bash or make it permanent by editing `/etc/sysctl.d/10-ptrace.conf`, which also explains what the setting does.

The comparison with reptyr is instructive, because the two tools answer different questions. reptyr takes over the terminal of a running process, so the process receives the interrupt and job control keys you type. reredirect only redirects output: the target keeps its original terminal, so Ctrl+Z and Ctrl+C never reach it. If you need the signal behaviour, the documentation points you at reptyr.

A Makefile recipe that logs part of a build

The project documentation ends with a trick for people who work on complex builds and want the output of a sub makefile split into its own file. The recipe creates a temporary fifo, points a reredirect call at it, and saves the restore command for later:

    target:
    	@FIFO=$$(mktemp -u); mkfifo $$FIFO; tee my_file.log < $$FIFO & ./redirect -m $$FIFO $$PPID > ./restore_$$PPID.cmd
    	@echo Call sub makefile here
    	@sh ./restore_$$PPID.cmd
    	@echo No more in log file

make The logic is the same as the manual fifo procedure, wrapped in a target so that it runs under `make`. The repository layout explains where the rest of it lives: `reredirect.c` and `attach.c` hold the tool itself, `ptrace.c` and `ptrace.h` hold the platform layer with an `arch/` directory of per-architecture headers, `relink` is the shell helper, and `reredirect.1` is the man page. There is a `ChangeLog` and a `Makefile` that derives the version string from `git describe` with a `.tag_name` fallback, which is why the repository has no GitHub releases: the version is stamped at build time instead of cut into tags.

Editorial conclusion

reredirect fits a sysadmin or developer who needs the output of a process that is already running, whether that means logging a service to a file or piping it through grep, and the installation is two make targets with no dependencies beyond a C toolchain. It is the wrong tool when you need the target process to receive the terminal's interrupt and job control signals, because relink only redirects output and leaves the original terminal with the process, and it will not run at all where ptrace_scope is restricted. Before using it, check the ptrace_scope value on the machine, because on Ubuntu Maverick and higher attaching is disabled by default, and prefer the -N flag when you only want the output captured, since keeping the previous descriptors open leaks them each time you run the tool.

Frequently asked questions

Official sources

1. Issues
2. jerome-pouiller/reredirect on GitHub
3. License: MIT
4. README