A week or three back, I posted about how I (stubbornly) managed to do a “one-liner” for generating an OpenSSL certificate signing request that included a subject alternative name section using X.509 v3 extensions. The OpenSSL command does not read the extensions from a standard input for piping purposes, so it expects to open an actual file, instead. The correct thing to do in that case is create a custom configuration file containing the extensions you want to use, and pass that as an argument. My “one-liner” to avoid that took advantage of BASH’s “process substitution” feature. This is really just a temporary FIFO structure that gets used “on the fly” by the shell, which means the output of any commands within the “<()” structure is fed to that temporary FIFO, and the path to the FIFO is what is actually returned to the program that needs it. It tells the program how to open a file (really a named pipe) to pull the contents that were dynamically generated.
This was an abuse of the technology to fit my needs. There are, however, appropriate times and places to use FIFO/Named Pipe structures. Here are a few to help make it clear why they are a “good thing” to know how to create and utilize.
Sometimes an administrator may have a desire to reboot a system after a major event, such as after a full system backup has completed successfully. In this scenario, we have two scripts that would get called by cron (or some other scheduler.) The first script to get called would be the “reboot” script that listens for an event that indicates the backup ran successfully. The second script would be the backup script that calls the backup software, monitors for successful completion, and then notifies the “reboot” script to reboot what the status was. If the reboot script receives a “backup failed” message, it would end gracefully, and perhaps send an email stating things went south. If it receives a “backup was successful” message, it would send an email stating things were successful, and then reboot the system.
“Why wouldn’t you use one script to just run the backup, then figure out whether to reboot or not?” I can hear you asking this to yourself, but let’s complicate the scenario a bit. Let’s say one of these scripts is kicked off from the backup server, itself. Let’s say the other script is kicked off by the machine that needs to be rebooted. Let’s say that there is a firewall that only allows the backup server to open a connection to the client, but the client can’t open a connection to the backup server. A touch file can be used, but typically that means polling to see if the file exists, with a specific timeout duration before giving up entirely. With a pipe, the communication is instant, because it’s a block call to read from the pipe. This also allows the backup server to make a call out to the monitoring service API to disable alerts on ping for the client during the reboot, if you wanted to get fancy with it.
In essence, FIFO files are a poor man’s message broker service. You set up a listening call on the pipe that wants to be triggered by the event of receiving data on the pipe, then when you’re ready for the event to happen, you send the data down the pipe to trigger the event.
FIFO structures can also stand in as files for programs that expect a file, as shown by the OpenSSL example, previously. At one point, a teammate looked at using a FIFO for an nmon project he was working on, polling the servers for performance data at regular intervals. I forget why he needed the FIFO, but it was a limitation with nmon itself that required the setup.