six demon bag
Wind, fire, all that kind of thing!
2020-05-23
Shell Patterns (5) - Locking
This is a short series describing some Bash constructs that I frequently use in my scripts.
Sometimes you need to ensure that a script is doing an operation exclusively, to avoid race conditions in case it had been launched several times in parallel. This kind of concurrency control is called mutual exclusion, or mutex for short. In Bash a mutex can be implemented by terminating or suspending execution unless the script is able to create a lock file.
Posted 15:33 [permalink]
2020-04-30
Shell Patterns (4) - Limiting Execution Time
This is a short series describing some Bash constructs that I frequently use in my scripts.
Sometimes you want a script to give up on what it's trying to do after some period of time. The simplest way for limiting the time a given statement may take for execution is the timeout
command.
$ timout 2 ping 127.0.0.1 PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.031 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.012 ms $ echo $? 124
However, timeout
is only useful for limiting the execution time of a single (blocking) command. Consider for instance a situation where you deployed a VM or an LXD container, and need to wait for cloud-init to complete on that system. Or a situation where you sent an asynchronous request to a REST API. timeout
won't help you there. You need to poll the system or API repeatedly until the respective "operation completed" indicator appears.
Posted 22:35 [permalink]
2020-03-23
Shell Patterns (3) - Structured Output
This is a short series describing some Bash constructs that I frequently use in my scripts.
On Linux (and many other operating systems) it's common to have regular and error output written to stdout and stderr respectively. In shell scripts you'd use the echo
or printf
commands for displaying messages, and redirect stdout to stderr for having the message displayed on stderr.
echo 'foo' # output goes to stdout
echo 'bar' 1>&2 # output goes to stderr
There may be different levels of information that you want to separate from each other, though, like having additional debug output that you don't want to pollute stdout or stderr. For that you can use the file descriptors 3 through 9.
Posted 15:22 [permalink]
2020-03-06
Shell Patterns (2) - Error Handling
This is a short series describing some Bash constructs that I frequently use in my scripts.
When writing scripts for automation purposes you normally want the scripts to terminate when something goes wrong. Because terminating in a controlled way is usually better than blindly continuing execution when the assumptions subsequent commands are based on aren't valid anymore.
Bash provides several options for controlling error handling, the most commonly used ones being
-e
(or-o errexit
): Exit immediately when a command terminates with a non-zero exit code.-u
(or-o nounset
): Treat unset variables and parameters (except for$@
and$*
) as errors when expanding them. This prevents problems due to misspelled variables.
There are some issues with using just these two options, though:
Posted 17:25 [permalink]
2020-02-24
Shell Patterns (1) - Logging
This is a short series describing some Bash constructs that I frequently use in my scripts.
What do you do when you run fully automated scripts in the background, but still want to keep track of what they're doing and, more importantly, when something goes wrong? The answer is, of course, you log what the script is doing (or is about to do).
There are two commonly used ways of implementing logging in Bash scripts:
- redirecting output to files
- invoking the
logger
command for logging to syslog
Personally, I prefer the latter, since it allows not only for managing log files independently of the process creating the log output, but also for filtering log data and/or forwarding it to a central loghost.
Posted 20:47 [permalink]