If the browser stops halfway while loading a website and then freezes, experienced users know that usually all it takes is clicking the reload button to make it work like clockwork on the next attempt. Or, if an rsync transfer suddenly stalls because the server has fallen asleep, admins will intuitively press Ctrl+C to abort, only to immediately restart the command and see it finish without a hitch in most cases. Scenarios where humans have to manually take control over running processes just because the computer fails to understand that an automatic restart would solve the problem are one of the last hurdles to a fully automated world.

The yoyo Go program presented in this issue supervises programs entrusted to it and will rejigger them like a yo-yo (as you know, yo-yos also need to be pulled up by a human hand to keep them moving). To do this, the utility monitors a supervised program's standard output (along with its standard error), which typically features frequently changing patterns – such as a progress bar that indicates that something is still happening. If the display freezes, for example, because of a network outage or because the server has lost interest, yoyo detects this and restarts the program after a configurable timeout, in hopes of somehow fixing the problem this way.

Feels Like a Terminal

Easy, right? But programs behave differently, depending on whether or not they think they are running in a terminal. Typing git push in a terminal, for example, continuously outputs the transfer progress as a percentage. And this gives the calling user, especially when they need to commit large files, some idea of how long the whole process is going to take (Figure 1, top).

Figure 1: git outputs data transfer statistics, but only if it thinks it's running in a terminal.

But if git push fails to find a terminal, for example, because its stdout and stderr channels have both been redirected to an out file (Figure 1, bottom), it will not output any progress messages at all while the files are being transferred to the git server. Instead, it just outputs a message at the end after everything is done. As you can easily determine from the git source code on GitHub, git uses the standard C isatty(2) function to check if the error output (file descriptor  2) is connected to a terminal and stops the output if isatty(2) returns 0.

Taciturn Without a Terminal

So without some kind of trickery, it would be impossible for a simple yo-yo controller program like the one in Listing 1 to track the progress of git push. As soon as it taps into the stdout and stderr of the program it is monitoring, the associated terminal vanishes; git notices this and switches to silent mode. This is why Listing 1 only prints a brief status message after the git command exits. This just won't work at all for monitoring the process to restart it in case of stalled progress.

Fake Terminals

As a workaround, the supervisor has to provide the monitored program with an environment that makes it think it is running in a terminal. Luckily, Unix offers programmers pseudo-terminals for this purpose. These kernel structures trick executed programs into thinking they are running in a real terminal, while allowing the monitor to control the input (stdin) and intercept the output (stdout, stderr) of the program under their control. Standard Linux utilities such as ssh, screen, tmux, and script (for recording shell sessions) make heavy use of pseudo-terminals.

The test script in Listing 2 simulates a monitored program with a terminal sensor. It first checks via the shell's -t command in line 2 whether standard output (file descriptor number 1) is connected to a terminal. If this test fails, the script outputs an error message and stops running in line 5. Otherwise, the for loop starting in line 7 counts to five in one-second steps, after which line 12 (optionally) sleeps for 31 seconds to allow the monitor to schedule a restart after 30 seconds of inactivity.

The supervising yoyo Go program presented in Listing 3 manages to provide this fake environment to its monitored entities just fine, as Figure 2 and Figure 3 illustrate. In the first case, yoyo receives individual messages every second and outputs them until it detects that the script to be monitored has exited. This is normal and fine – no need to restart anything. But when Listing 2 enables the sleep 31 command, you get the situation shown in Figure 3: The yoyo monitor patiently waits for 30 seconds on updates on the stalled output channel before pulling the ripcord and restarting the script.

Figure 2: The test script terminates after five seconds, and yoyo correctly detects that.

Figure 3: If the test script sleeps for 31 seconds, yoyo keeps restarting it.