Detect and restart hanging programs with Go
Programming Snapshot – Automated Restarts with Go
Detecting programs where the standard output has frozen can require a deep dive into terminal emulation basics. Go plumber Mike Schilli builds a plunger to free up the pipe works.
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).
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.
Listing 1
capture.go
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.
Listing 2
test.sh
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.
Listing 3
yoyo.go
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
New Slimbook EVO with Raw AMD Ryzen Power
If you're looking for serious power in a 14" ultrabook that is powered by Linux, Slimbook has just the thing for you.
-
The Gnome Foundation Struggling to Stay Afloat
The foundation behind the Gnome desktop environment is having to go through some serious belt-tightening due to continued financial problems.
-
Thousands of Linux Servers Infected with Stealth Malware Since 2021
Perfctl is capable of remaining undetected, which makes it dangerous and hard to mitigate.
-
Halcyon Creates Anti-Ransomware Protection for Linux
As more Linux systems are targeted by ransomware, Halcyon is stepping up its protection.
-
Valve and Arch Linux Announce Collaboration
Valve and Arch have come together for two projects that will have a serious impact on the Linux distribution.
-
Hacker Successfully Runs Linux on a CPU from the Early ‘70s
From the office of "Look what I can do," Dmitry Grinberg was able to get Linux running on a processor that was created in 1971.
-
OSI and LPI Form Strategic Alliance
With a goal of strengthening Linux and open source communities, this new alliance aims to nurture the growth of more highly skilled professionals.
-
Fedora 41 Beta Available with Some Interesting Additions
If you're a Fedora fan, you'll be excited to hear the beta version of the latest release is now available for testing and includes plenty of updates.
-
AlmaLinux Unveils New Hardware Certification Process
The AlmaLinux Hardware Certification Program run by the Certification Special Interest Group (SIG) aims to ensure seamless compatibility between AlmaLinux and a wide range of hardware configurations.
-
Wind River Introduces eLxr Pro Linux Solution
eLxr Pro offers an end-to-end Linux solution backed by expert commercial support.