Thoughts on technology, movies, and everything else
Linux is my primary operating system. I used it on the servers, desktops, laptops, netbooks, and even mobile phones since approximately 1997. I’ve tried a number of distributions over the years, and even created a couple myself. I still look around sometimes to see what others are up to. But most of my machines are running some sort of Red Hat – either a quick and easy Fedora Linux, or a stable and secure Red Hat Enterprise Server, or a cheaper CentOS alternative.
And while by now I am very comfortable in the Linux environment (both graphical and command line), I still discover a lot of new and interesting things about it. When I come across something worthy, I usually share it with the rest of the Open Software world, using this category.
More and more often I come across a scenario where I need to repeat the shell command until it succeeds. Here are a couple of examples:
Reboot a server. Try to remotely login to it via ssh. This fails until the server actually boots up. Keep trying until connected.
Start an application that writes to the log file. Run “tail -f some.log” to watch the log messages. This fails if the log file does not exist yet. Keep trying until the application creates the log file and writes something into it.
Sure, I can always press the up arrow key and Enter, to repeat the last command from the history. But it is a tiny bit annoying.
Today I came across this little trick, that solves the problem. Add the following function to your .bashrc:
CMD=$(fc -ln | tail -n 2 | head -n 1)
echo "repeating until success: $CMD"
Now you can run “rpt” to repeat the latest command until it succeeds.
These three facts all seem eminently sensible and reasonable, right? 1. Unix time is the number of seconds since 1 January 1970 00:00:00 UTC 2. If I wait exactly one second, Unix time advances by exactly one second 3. Unix time can never go backwards False, false, false.
All three of these are false and for the same reason – leap seconds. The article provides a nice and easy explanation of how and why that happens.
Swarm is Docker, Inc.’s orchestrator. It started development five years ago. It’s built into the Docker Engine, which makes it the same to run it on development machines as in production servers. In my opinion, it is much less powerful than Kubernetes, and I would vote against using it in a business environment. That said, I’m a happy admin of a single-node Swarm running all of my personal services at home. But that’s it. I wouldn’t use it for anything with more than 1-2 nodes, but for those applications, I feel is the right tool for the job.
Personally, I’m not a frequent user of debuggers. Most of the projects and code that I am involved with is easily debugged with good old “die(‘here’)”. But if you are looking for some help on how to use Vim with a debugger, have a look at the “Debugging in Vim” blog post.