Whenever someone asks for a quick way to ensure that only one instance of a script can run at a time, I see a lot of people giving advice involving temporary lock/PID files (see here, here, and here). This is probably fine for most purposes, but I wonder why more people don’t just check the process table:
SCRIPT_NAME=`basename $0`
if [ `pgrep -c ${SCRIPT_NAME}` -gt 1 ]
then
echo "Error: An instance of this script is already running!"
exit 1
fiThis fragment uses pgrep to count the number of running processes with the same name as the currently running script. If the number of these processes is greater than one (the current script will always be counted), then we know that another instance is already running.
As far as I know (and I hope someone will correct me if I’m wrong), this technique avoids the race conditions associated with lock/PID files. It also avoids the possibility of orphaned lock/PID files in the event that your script doesn’t complete and is unable to clean up after itself.
Well, I should have listened to everyone who warned me about UltraDNS’s obscene prices. But I figured it’s only DNS, so how much more could they be compared to their competition? $50 per month? Maybe $100? Boy was I surprised to find out that UltraDNS’s prices are literally 10-25 times more than everyone else’s! Hilarious…
I’ve actually been a DynDNS customer since the late nineties or so (I have free custom DNS service for life for making a donation to them back when they were a much smaller company), so I had looked at Dyn.com‘s products before. I just must have gotten confused with all their different websites and DNS products, because I somehow got the impression that the DynDNS API wasn’t powerful enough to do what I wanted to do. I was absolutely wrong. After having written command line clients for both APIs (see ultradns4r, and now dynectr4), I think I speak from authority when I say the Dynect API is every bit as powerful as UltraDNS’s. And at 1/10th – 1/25th the cost of UltraDNS, going with Dynect is a no-brainer. But I’ve digressed long enough.
I wrote dynect4r for the same reason I wrote ultradns4r; I wanted to be able to manage all my DNS records via the command line. And now that I’ve learned how to package Ruby projects as gems, you can simply…
and then do things like…
dynect4r-client -n test.example.org 1.1.1.1
Since the key feature of this project is the command line client, the actual library behind it is a pretty simple wrapper around rest-client. If you’re looking for something a bit more powerful to use in your own Ruby projects, you may be interested in dynect_rest by Adam Jacob from Opscode. We actually discovered each other’s projects last night in #chef, and realized that it would probably be a good idea to pool our efforts eventually.
I just spent the last week or so learning more about SOAP than I ever wanted to know. ;-) Fortunately, the result of that hard work resulted in something that might benefit the EC2 community.
I am pleased to announce ultradns4r; a Ruby library and command line client for the Neustar UltraDNS SOAP API. I created this tool to alleviate the pain in dealing with EC2′s dynamic hostnames and IP addresses. Since it allows editing of arbitrary DNS records via the command line, it can be used to make EC2 instances update their own DNS records.
Lessons Learned
- If you need to do SOAP in Ruby, just use Savon. Trust me on this.
- WSSE authentication is a complete pain in the ass. I was unable to find any SOAP library (Ruby, Python, or Perl) that could authenticate with the UltraDNS API servers out of the box (Savon included). I ended up having to build the entire WSSE header manually in order to generate the exact XML needed.
- Apparently, element order sometimes matters with SOAP! This is something I never expected, considering that (last I knew) the XML spec does not even allow you to enforce element or attribute order. This was also the cause of a lot of my WSSE problems. I found that for example, if the Password element came after the Nonce and Created elements (which is the case if you use Savon’s built-in WSSE authentication), then authentication would fail. Could this have been the result of having a buggy XML parser on the server side? In any case, this is one of those annoying issues to be aware of.
The default disk monitoring module for Ganglia (moddisk.so) is pretty stupid, since it simply sums up the free disk space on all of your disks and presents it in a single graph. Frankly, this just doesn’t tell you much, so I wrote a more useful replacement:
This module reads a list of mounted file systems from a file (probably /proc/mounts) and creates a metric for each one, allowing you to graph disk usage for each file system separately. Enjoy!
Update: It appears that multidisk.py does the same thing, and is probably already included with your distribution. Oops! ;-)
I’ve recently written a Python module to graph some interesting Tokyo Tyrant metrics with Ganglia. It basically just parses the output of tcrmgr inform -st localhost, so you’ll probably need to update the pyconf file with the correct location of the tcrmgr command. But this module also gives you some neat things that tcrmgr doesn’t, like the current number of Get/Put/Out operations per second rather than just the total number of operations since the server was started.
Enjoy!