Efficiently doing nothing in Linux

Computers exist for doing work, usually useful, often not. In rare instances, it's useful to make a program do nothing at all. My primary use case for this is Docker containers, where it's useful to have the container do nothing, so it can be exec-d into as part of another process (eg VSCode dev containers). For that to work, the container needs a CMD which isn't the application itself, but is at least something to keep the container alive.

One of the most popular ways this is implemented is using tail -f /dev/null. Reading from a file which will never return any content will hang forever, and be pretty efficient doing it. It also has the benefit that because tail is part of coreutils, it's installed by default everywhere - no extra dependencies needed.

However, as with many popular techniques, it's not always the best. To understand why, we need look at what tail is actually doing, using strace. This is far from the place to go into the specifics, But strace lets us see what syscalls a process is making when it talk sot the kernel. Whether that's reading files, reading shared libraries, running subprocesses etc.

If we run tail -f /dev/null through strace, we get this:

This is quite a lot to read, and I don't entirely understand it all - but that's ok, because we don't need to. The important lines are the repeated lines at the bottom:

What we expect is that tail never receives content from /dev/null, and thus never does anything. As it turns out, this is completely false. What appears to actually be happening is tail tries to read the file, gets nothing back, waits for a second, then tries again.

The reason for this is the default behaviour for tail. When you pass -f, tail reads the entire content of the file as-is. Once it's run out of content, it falls back to polling the file every second for changes, and displaying those. You can control the interval with -s. This is what we're seeing in strace. /dev/null isnt' actually a file which never yields data, it's just an empty file when you read from it (the magic comes when you write to it).

Whilst we might think out command is doing nothing, it's actually doing something. Sure, that something is very very little, but what if we want to do better, to achieve as close to nothing as is physically possible?

As much of a surprise as it may be, Windows does this surprisingly well. If you're writing a batch script, you could use the pause command to output the famous "Press any key to continue..." text, and wait for user input before continuing. It's not a perfect replacement for doing absolutely nothing, but it's pretty close. My knowledge of Windows kernel internals is pretty limited, so I'm not sure what exactly it's doing under the hood, but I'd hope it's not much. The bad news is, there's no pause command on Linux, but what there is is a pause syscall.

The pause syscall does exactly what it says on the tin: It pauses. But, it does is in a very efficient way. pause forces the process to do nothing until it receives a signal. Because all of this happens in the process scheduler in the kernel, the process itself does exactly nothing until it receives a signal, making it incredibly efficient.

#How people normally wait

If you're developing a program of some kind, it's quite common that you need to wait a set amount of time for something to happen. Python has time.sleep, Rust has std::thread::sleep, and in the shell there's the sleep command. Pass it a time of some type, and sleep will stop executing the program until that amount of time has passed (or as close as the kernel can get). Because the kernel is aware of sleeping processes, there's no need to context switch back to the application, fractionally reducing system load.

If you want to sleep "forever", you could just pass a very big number to sleep, like 31557600 (1 year in seconds). 1 year is a long way from "forever", but it's also kinda close, so it might be "good enough" for your use case. "good enough" isn't good enough for me though, not this time - I still want the perfect solution.

We can get closer, but to do so, we need to talk about everyone's favourite: Floating Point.

#Floating Point

Floating point is a way for computers to represent both large and precise numbers relatively efficiently. I'm not going to try and explain it further than that, I'll let someone else:

A side effect of floating point is that it's possible to represent a few more interesting values. Most people are well aware of the number 0, but to computers, there's 2: -0 and +0. And, to make matters more interesting, especially for our needs, there's -Infinity and +Infinity.

#To infinity, and beyond

Armed with this knowledge of floating point, can it be applied to sleep? Sleep's man page says it only takes numbers. But if we can represent infinity numerically, can we pass it in somehow? Because there's support in the underlying libraries, we can, but for completely undocumented reasons:

It works, but contradicts the man pages. How?

It seems the coreutils (where the sleep command comes from) developers are one step ahead of us. You might think it'd just pass an incredibly large number to clock_nanosleep, but instead, it does better. sleep infinity is smart enough to know "infinity" will never come, and simply use pause instead - a kind of infinite sleep when you think about it. This is the perfect solution we've been looking for.

#How to sleep for infinity

A little tangent into the depths of coreutils and something I rarely enjoy: reading C.

The sleep command takes a single argument, "The duration, in seconds", according to its man page. Because humans hate large numbers, suffixes are also supported (eg 6h).

Under the hood, sleep calls to xstrtod, an alternative to strtod - both of which convert a string to a double. The exact implementation isn't important, but they have a few cases where they don't quite do this, specifically, when said input string is "Infinity" (case-insensitive). In this case, the returned value is Infinity, represented as a double. This value is then passed to xnanosleep, which has special handling for environments which support pause, to call it if the provided seconds is far too large.

Diving further, to find out how pause actually worked requires passing through into libc, and further into the kernel's process scheduler, 2 places I'd rather not go - It's a scary place down there!

#Pause in other places

pause itself is a syscall, so it can be called from many different languages, so long as they have an interface.

If you need to call pause from other languages, there are likely options, such as in Python and Rust. However, if you're building an application, there are likely alternatives to consider, or some other kinds of processing or error checking your process should be doing instead. Using pause isn't necessarily perfect, and has some disadvantages

In a shell script, as I mentioned, there's no pause binary like there is on windows, so you'd need to run sleep infinity yourself.

#GNU's Not Universal

I've been talking about Linux and GNU's coreutils like it's everything - but it's not. For example, there's BSD.

BSD, namely FreeBSD and OpenBSD, both have their own implementations of libc, so have pause methods to influence the kernel's scheduler. Similarly, both ship with implementations of sleep. However, both are strict and sensible enough to follow their own man pages. Neither supports sleep infinity. If you want to pause from a bash script, you'll need to find another way.

#Application

Now we know it exists, we can stop using tail -f /dev/null, and use sleep infinity, for the smallest possible micro optimisation.

If this change makes any difference to your workflow, you're probably doing something else wrong. If you just want to open a few "technically correct" Pull Requests, then now you have something to link to!