Bash – Redirect stderr from an already running script

bashio-redirectionstdout

I've been running a script for several days now. I redirected stdout to $HOME/mylog, but didn't redirect stderr since I thought there would be nothing on it. Suddenly thousands of lines started coming out on stderr, so I suspended the job. Is there a way I can redirect stderr to $HOME/myerr from now on, without needing to restart the script?

I have sudo access on the box and it's OS X.

Perhaps something using dtools trapping?

I cannot lose the work the script has done so far and restart it from scratch. Is there a way to "dump the in-memory objects" on disk, freeze the program, edit the variables (e.g. the file descriptors) and resume with the new context?

Best Answer

I think it is possible if you attach the process of the related interpreter to gdb. I tried it with this perl one-liner

 perl -e 'do { print "x\n"; sleep(1) } while(1)'

and it works but unfortunately not with a similar bash script.

First of all you have to figure out the PID of that process whose output you want to capture. Then start gdb in another terminal and execute the following gdb-commands

attach PID
call close(2)
call open("/abs/olu/te/path/filename", 65, 384)
detach PID

after that the whole data that is written to stderr is redirected to /abs/olu/te/path/filename, since

attach PID attaches the process to gdb and stops it
call close(2) closes the stderr filedescriptor of the process (for stdout the filedescriptor is 1)
call open(...) opens a new file and takes the lowest unused integer for the newly created filedescriptor and
detach PID continues the process

At least on my machine. The first two lines are POSIX compatible but not the third one.

The second and the third argument of open in the third line are documented in man 2 open. In my case 65 means that open should create the file and open the file write-only i.e. O_WRONLY | O_CREAT (defined in fcntl.h). The third argument tells open to create the file with read and write permission for the user i.e. S_IWUSR | S_IRUSR (defined in sys/stat.h). So maybe you have to find out appropriate values on your machine by yourself.

Related Solutions

Bash – Redirect All Subsequent Commands’ STDERR Using Exec

As for a solution to redirect lots of command at once:

#!/bin/bash
{
    somecommand 
    somecommand2
    somecommand3
} 2>&1 | tee -a $DEBUGLOG

Why your original solution does not work: exec 2>&1 will redirect the standard error output to the standard output of your shell, which, if you run your script from the console, will be your console. the pipe redirection on commands will only redirect the standart output of the command.

On the point of view of somecommand, its standard output goes into a pipe connected to tee and the standard error goes into the same file/pseudofile as the standard error of the shell, which you redirect to the standard output of the shell, which will be the console if you run your program from the console.

The one true way to explain it is to see what really happens:

Your shell's original environment might look like this if you run it from the terminal:

stdin -> /dev/pts/42
stdout -> /dev/pts/42
stderr -> /dev/pts/42

After you redirect standard error into standard output (exec 2>&1), you ... basically change nothing. But if you redirect the script's standart output to a file, you would end up with an environment like this:

stdin -> /dev/pts/42
stdout -> /your/file
stderr -> /dev/pts/42

Then redirecting the shell standard error into standard output would end up like this :

stdin -> /dev/pts/42
stdout -> /your/file
stderr -> /your/file

Running a command will inherit this environment. If you run a command and pipe it to tee, the command's environment would be :

stdin -> /dev/pts/42
stdout -> pipe:[4242]
stderr -> /your/file

So your command's standard error still goes into what the shell uses as its standard error.

You can actually see the environment of a command by looking in /proc/[pid]/fd: use ls -l to also list the symbolic link's content. The 0 file here is standard input, 1 is standard output and 2 is standard error. If the command opens more files (and most programs do), you will also see them. A program can also choose to redirect or close its standard input/output and reuse 0, 1 and 2.

IO Redirection – Restoring Terminal Output After ‘exec &>filename’

After you run exec &>filename, the standard output and standard error of the shell go to filename. Standard input is file descriptor 0 by definition, and standard output is fd 1 and standard error is fd 2.

A file descriptor isn't either redirected or non-redirected: it always go somewhere (assuming that the process has this descriptor open). To redirect a file descriptor means to change where it goes. When you ran exec &>filename, stdout and stderr were formerly connected to the terminal, and became connected to filename.

There is always a way to refer to the current terminal: /dev/tty. When a process opens this file, it always means the process's controlling terminal, whichever it is. So if you want to get back that shell's original stdout and stderr, you can do it because the file they were connected to is still around.

exec &>/dev/tty

Best Answer

Related Solutions

Bash – Redirect All Subsequent Commands’ STDERR Using Exec

IO Redirection – Restoring Terminal Output After ‘exec &>filename’

Related Question